This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb remote protocol breakpoints (Z0 command)
- From: David Taylor <dtaylor at emc dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Mon, 23 Jun 2014 09:28:53 -0400
- Subject: Re: gdb remote protocol breakpoints (Z0 command)
- Authentication-results: sourceware.org; auth=none
- References: <20417 dot 1403189074 at usendtaylorx2l> <y0my4wr8610 dot fsf at fche dot csb>
Frank Ch. Eigler <fche@redhat.com> wrote:
>
> David Taylor <dtaylor@emc.com> writes:
>
> > [...]
> > . there is no bytecode operator for setting memory
> > . there is no bytecode operator for setting registers
> > [...]
>
> Can you elaborate why you wish to modify state in breakpoint
> conditionals?
One of the options with Z0 breakpoints is 'persist' -- you can create a
breakpoint that sticks around when GDB disconnects. I don't know why I
would want a persistent breakpint if it could neither alter state and
nor call functions.
Things that I envision using them for include
. quick and dirty patching before rebuilding
. collecting debugging information
If you can alter memory you can turn logging / event recording on and
off to just collect information in the areas of interest and generate
fewer messages / fewer records.
I think that pushing the 'conditional' part of the breakpoint to the
stub -- with existing limitations -- is very useful. I think that
without extensions the 'persistence' and 'command list' parts aren't
very useful.
I'm curious, how do you envision using the 'persistence' and 'command
list' parts given the current limitations?