Re: Some questions about gdb's remote protocol and reverse debugging

[Michael Snyder <msnyder at vmware dot com>]

Julian Smith wrote:
> Hello
>
> I've been trying out gdb-cvs's remote protocol, specifically the
> commands for reverse debugging, and i have a couple of questions that i
> was hoping someone might be able to help me with. I'm using Linux on
> x86-32 and x86-64.

Cool, welcome!  Join the fun.

> First, if i'm understanding things correctly, gdb appears to default to
> software breakpoints, using the 'Z0' and 'z0' commands and, if these
> aren't supported by the remote target, it then tries to use 'M' and 'm'
> to write breakpoints directly into the inferior's memory.

That's right...

> Is there any way to tell gdb to try to use hardware breakpoints (with
> the 'Z1' and 'z1' commands) before resorting to 'M' and 'm' ? [In the
> environment i'm working in, UndoDB, hardware breakpoints are more
> convenient because they don't require any patching up of %pc, and
> poking breakpoints directly into memory is not supported.]

Not as such, no.  You use a different syntax to set a hardware
breakpoint.  The command is "hbreak" instead of "break".  You
should at least be able to try stuff out with that.

You may need to enable the Z1 packet, like this (I'm not sure
if it's enabled by default):

  set remote haredware-breakpoint-packet 1

> Second, am i right in thinking that gdb does things like reverse-step
> and reverse-next by effectively doing many reverse-stepi's (with 'bs'),
> interleaved with 'g' commands to get the registers? If so, are there
> any plans to try to avoid the overhead of this somehow ?

There are only the two actual reverse-execution packets -- 'bs' and 
'bc'.  Gdb uses them in exactly the same contexts that it would use
's' and 'c' if going forward.  As such, "step" is always going to be
implemented as one or more 's' requests, whereas "next" may involve
a mixture of 's' and 'c' requests.  The same is true going backward.

Good luck,
Michael