Some questions about gdb's remote protocol and reverse debugging

Some questions about gdb's remote protocol and reverse debugging

[Julian Smith]

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.

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.

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.]

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 ?

Many thanks,

- Julian

-- 
http://undo-software.com/

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

[Michael Snyder]

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

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

[Daniel Jacobowitz]

On Tue, Aug 11, 2009 at 04:22:30PM -0700, Michael Snyder wrote:
> >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.

Or, just make your stub treat Z0 as a hardware breakpoint?

-- 
Daniel Jacobowitz
CodeSourcery

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

[Julian Smith]

On Tue, 11 Aug 2009 16:22:30 -0700
Michael Snyder <msnyder@vmware.com> wrote:

> 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

Ah, i hadn't noticed this command, though i have been using `hbreak'.
Thanks. I'm also trying out disabling the software-breakpoint packet,
and things seem to be working better now.

> 
> > 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.

Ok.

But... isn't there always going to be a difference when going
backwards, e.g. if an instruction jumps to an address in a register,
one cannot know about this jump when stepping backwards (and so, for
example, one cannot first go back to the destination of the jump, do a
`bs' to step back over the jump, then carry on with `bc')? Perhaps this
sort of indirect jump never occurs within a function though, so is not a
problem for things like reverse-step.

Anyway, many thanks for you help, 'tis much appreciated. I'm still
tinkering with things, but i think i should be able to make progress
now.

Cheers,

- Julian

-- 
http://undo-software.com/

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

[Jakob Engblom]

> Ok.
> 
> But... isn't there always going to be a difference when going
> backwards, e.g. if an instruction jumps to an address in a register,
> one cannot know about this jump when stepping backwards (and so, for
> example, one cannot first go back to the destination of the jump, do a
> `bs' to step back over the jump, then carry on with `bc')? Perhaps this
> sort of indirect jump never occurs within a function though, so is not a
> problem for things like reverse-step.
> 
> Anyway, many thanks for you help, 'tis much appreciated. I'm still
> tinkering with things, but i think i should be able to make progress
> now.

Note that you are not executing backwards: you are inspecting what happened. You
do not reverse individual instructions, you are looking at a history. In this
case, of course you can go back forth across jumps, interrupts, returns, and any
other change of location.  How to implement it varies, but either you reexecute
deterministically but one step shorter, or you look into some recorded execution
trace and just move one step back in that. 

/jakob