Re: questions / suggestions about gdb

Re: questions / suggestions about gdb

[Charles James Leonardo Quarra Cappiello]

Ok, thank you for the explanation! ; )

Charles Quarra


>From: Michael Elizabeth Chastain <mec@shout.net>
>To: charsquarra@hotmail.com, gdb@sources.redhat.com
>Subject: Re: questions / suggestions about gdb
>Date: Wed, 8 May 2002 07:48:17 -0500
>
> > I'm an often user of gdb, and i was wondering, since debuggers cant go 
>to
> > past states (no inversibility of the run), it would be nice if two 
>instances
> > of the debugger could run synchronized with a given step offset, so when 
>the
> > advanced instance break, the retarded instance stops, keeping an 
>analogous
> > state which can be studied.
>
>This is not feasible.
>
>Suppose that the advanced instance makes a system call, such as reading
>from a network connection.  Later on, the retarded instance will make
>the system call.  How are you going to arrange for the retarded instance
>to receive the same data that the advanced instance received?
>
>Basically, you have to write a wrapping layer that understands every
>system call on the target system.
>
>Besides system calls, you have to handle many other forms of 
>nondeterministic
>instructions:
>
>   signal delivery
>
>     the hard part is not trapping the signal in the advanced process.
>     once the signal is trapped, the hard part is figuring out how many
>     instructions have elapsed in the advanced process so that the signal
>     can be delivered at exactly the right point in the retarded process
>
>   memory-mapped input
>
>     suppose the advanced process reads from a memory-mapped input device.
>     how can you make the device provide the same data a second time,
>     when the retarded process hits it?  At the gdb level, you can't.
>     You need big hooks in the OS memory management code here.
>
>   multi-threading
>
>     If the process is multi-threaded, it is hard to record the thread
>     switches from the advanced process, and it's even harder to make
>     them happen at the same time in the retarded process
>
>I've done work along these lines and I might resume it in the future.
>However, the idea of keeping the "retarded" process running in parallel
>in real time is difficult and unworkable.
>
>Michael C



_________________________________________________________________
Join the worldÂ’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: questions / suggestions about gdb

[Michael Elizabeth Chastain]

> I'm an often user of gdb, and i was wondering, since debuggers cant go to 
> past states (no inversibility of the run), it would be nice if two instances 
> of the debugger could run synchronized with a given step offset, so when the 
> advanced instance break, the retarded instance stops, keeping an analogous 
> state which can be studied.

This is not feasible.

Suppose that the advanced instance makes a system call, such as reading
from a network connection.  Later on, the retarded instance will make
the system call.  How are you going to arrange for the retarded instance
to receive the same data that the advanced instance received?

Basically, you have to write a wrapping layer that understands every
system call on the target system.

Besides system calls, you have to handle many other forms of nondeterministic
instructions:

  signal delivery

    the hard part is not trapping the signal in the advanced process.
    once the signal is trapped, the hard part is figuring out how many
    instructions have elapsed in the advanced process so that the signal
    can be delivered at exactly the right point in the retarded process

  memory-mapped input

    suppose the advanced process reads from a memory-mapped input device.
    how can you make the device provide the same data a second time,
    when the retarded process hits it?  At the gdb level, you can't.
    You need big hooks in the OS memory management code here.

  multi-threading

    If the process is multi-threaded, it is hard to record the thread
    switches from the advanced process, and it's even harder to make
    them happen at the same time in the retarded process

I've done work along these lines and I might resume it in the future.
However, the idea of keeping the "retarded" process running in parallel
in real time is difficult and unworkable.

Michael C

Re: questions / suggestions about gdb

[Eli Zaretskii]

On Wed, 8 May 2002, Michael Elizabeth Chastain wrote:

> I've done work along these lines and I might resume it in the future.
> However, the idea of keeping the "retarded" process running in parallel
> in real time is difficult and unworkable.

Agreed.  However, it would be a great feature to be able to run the 
program in reverse.  Some debuggers actually allow that (don't ask me 
how).

Re: questions / suggestions about gdb

[Petr Sorfa]

Hi Eli,

> > I've done work along these lines and I might resume it in the future.
> > However, the idea of keeping the "retarded" process running in parallel
> > in real time is difficult and unworkable.
> 
> Agreed.  However, it would be a great feature to be able to run the
> program in reverse.  Some debuggers actually allow that (don't ask me
> how).

There are several methods, but one them is undoing the machine code
instructions. Also it is possible to generate additional debug
information from the compiler to assist in certain tasks. I agree that
running a second process is dangerous as basically all IO is going to be
replicated, which will cause all sorts of horrors.

Petr

Re: questions / suggestions about gdb

[Petr Sorfa]

Hi,

Yes, there are definitely instances where going to a past state simply
does not work. But keeping those certain limitations in mind, it is
quite possible to go to a past state. As far as I know both the Solaris
SDK debugger and the HP debugger (coupled with GDB as far as I
understand it), support some level of "retracing/retracting" your steps.

I could be wrong, but I think the Solaris debugger allows you to
actually change and recompile the code without having to kill or restart
the process (boggles the mind, but it can be useful in correcting code
in complex applications.)

Rosenberg's "How Debuggers Work" (Wiley, ISBN 0-471-14966-7, 1996)
covers briefly some of these concepts. But the book is in need of an
update with more technical details.

Petr 
> > I'm an often user of gdb, and i was wondering, since debuggers cant go to
> > past states (no inversibility of the run), it would be nice if two instances
> > of the debugger could run synchronized with a given step offset, so when the
> > advanced instance break, the retarded instance stops, keeping an analogous
> > state which can be studied.
> 
> This is not feasible.
> 
> Suppose that the advanced instance makes a system call, such as reading
> from a network connection.  Later on, the retarded instance will make
> the system call.  How are you going to arrange for the retarded instance
> to receive the same data that the advanced instance received?
> 
> Basically, you have to write a wrapping layer that understands every
> system call on the target system.
> 
> Besides system calls, you have to handle many other forms of nondeterministic
> instructions:
> 
>   signal delivery
> 
>     the hard part is not trapping the signal in the advanced process.
>     once the signal is trapped, the hard part is figuring out how many
>     instructions have elapsed in the advanced process so that the signal
>     can be delivered at exactly the right point in the retarded process
> 
>   memory-mapped input
> 
>     suppose the advanced process reads from a memory-mapped input device.
>     how can you make the device provide the same data a second time,
>     when the retarded process hits it?  At the gdb level, you can't.
>     You need big hooks in the OS memory management code here.
> 
>   multi-threading
> 
>     If the process is multi-threaded, it is hard to record the thread
>     switches from the advanced process, and it's even harder to make
>     them happen at the same time in the retarded process
> 
> I've done work along these lines and I might resume it in the future.
> However, the idea of keeping the "retarded" process running in parallel
> in real time is difficult and unworkable.
> 
> Michael C

Re: questions / suggestions about gdb

[Charles James Leonardo Quarra Cappiello]

Andrew Cagney wrote:

>
>>Daniel Jacobowitz wrote:
>>
>>
>>>can i activate the 'generate-core-file' a few steps before the program
>>>breaks?
>>
>>Whenever you want to; you just issue the command, and then you can come
>>back to look at the core file later.
>>
>>
>>my question is; how the debugger would automatically know that three steps 
>>further the program will break and generate a core file; i guess to 
>>generate core files on every (say, 100 steps) could help a lot too.
>
>In theory .... In addition to saving the internal state of the program,
>you'll need to record all the external state and any additional I/O that
>the running program performs.  That way you can exactly replay that
>program's behavour (this gets tricky when you're trying to to timers
>just right).  I suspect you'd end up having to use a simulator for this.
>  Alternativly, you can ignore the external state problem and get
>something working most of the time (via something like fork()?).
>
>Another possability is to have GDB use its builtin-simulator to look
>ahead a few instructions at what the inferior would do given its current
>state.  Provided the simulator doesn't modify the inferior (debugged
>process) nor do I/O it shouldn't affect the program that is running.
>
>enjoy,
>Andrew
>
>

But i still think that having two instances of the debugger with a step 
offset, in which when the one advanced in time breaks, makes the other 
behind pause, would help a lot, DDD couldn't handle this without much 
burden?


-Charles Quarra








_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Re: questions / suggestions about gdb

[Charles James Leonardo Quarra Cappiello]

Daniel Jacobowitz wrote:


> > can i activate the 'generate-core-file' a few steps before the program
> > breaks?
>
>Whenever you want to; you just issue the command, and then you can come
>back to look at the core file later.
>

my question is; how the debugger would automatically know that three steps 
further the program will break and generate a core file; i guess to generate 
core files on every (say, 100 steps) could help a lot too.


-Charles Quarra


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: questions / suggestions about gdb

[Andrew Cagney]

> Daniel Jacobowitz wrote:
> 
> 
>> can i activate the 'generate-core-file' a few steps before the program
>> breaks?
> 
> Whenever you want to; you just issue the command, and then you can come
> back to look at the core file later.
> 
> 
> my question is; how the debugger would automatically know that three steps further the program will break and generate a core file; i guess to generate core files on every (say, 100 steps) could help a lot too.

In theory .... In addition to saving the internal state of the program, 
you'll need to record all the external state and any additional I/O that 
the running program performs.  That way you can exactly replay that 
program's behavour (this gets tricky when you're trying to to timers 
just right).  I suspect you'd end up having to use a simulator for this. 
  Alternativly, you can ignore the external state problem and get 
something working most of the time (via something like fork()?).

Another possability is to have GDB use its builtin-simulator to look 
ahead a few instructions at what the inferior would do given its current 
state.  Provided the simulator doesn't modify the inferior (debugged 
process) nor do I/O it shouldn't affect the program that is running.

enjoy,
Andrew

Re: questions / suggestions about gdb

[Charles James Leonardo Quarra Cappiello]

On  Tue, 7 May 2002 15:00:37 -0400 Daniel Jacobowitz wrote:

>On Tue, May 07, 2002 at 02:58:03PM -0400, Charles James Leonardo Quarra 
>Cappiello wrote:
> > Hi,
> >
> >
> > I'm an often user of gdb, and i was wondering, since debuggers cant go 
>to
> > past states (no inversibility of the run), it would be nice if two
> > instances of the debugger could run synchronized with a given step 
>offset,
> > so when the advanced instance break, the retarded instance stops, 
>keeping
> > an analogous state which can be studied.
> >
> > This actually can be done or is not feasible? If can't be done just now 
>but
> > is from the debugger's developers point of view feasible, consider this 
>a
> > feature request.
>
>GDB just gained a feature that'll do almost what you want: the
>`generate-core-file' command.  You can then debug the new corefile to
>examine the frozen state.
>
can i activate the 'generate-core-file' a few steps before the program 
breaks?


-Charles Quarra



_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: questions / suggestions about gdb

[Daniel Jacobowitz]

On Tue, May 07, 2002 at 03:06:57PM -0400, Charles James Leonardo Quarra Cappiello wrote:
> 
> 
> On  Tue, 7 May 2002 15:00:37 -0400 Daniel Jacobowitz wrote:
> 
> >On Tue, May 07, 2002 at 02:58:03PM -0400, Charles James Leonardo Quarra 
> >Cappiello wrote:
> >> Hi,
> >>
> >>
> >> I'm an often user of gdb, and i was wondering, since debuggers cant go 
> >to
> >> past states (no inversibility of the run), it would be nice if two
> >> instances of the debugger could run synchronized with a given step 
> >offset,
> >> so when the advanced instance break, the retarded instance stops, 
> >keeping
> >> an analogous state which can be studied.
> >>
> >> This actually can be done or is not feasible? If can't be done just now 
> >but
> >> is from the debugger's developers point of view feasible, consider this 
> >a
> >> feature request.
> >
> >GDB just gained a feature that'll do almost what you want: the
> >`generate-core-file' command.  You can then debug the new corefile to
> >examine the frozen state.
> >
> can i activate the 'generate-core-file' a few steps before the program 
> breaks?

Whenever you want to; you just issue the command, and then you can come
back to look at the core file later.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

questions / suggestions about gdb

[Charles James Leonardo Quarra Cappiello]

Hi,


I'm an often user of gdb, and i was wondering, since debuggers cant go to 
past states (no inversibility of the run), it would be nice if two instances 
of the debugger could run synchronized with a given step offset, so when the 
advanced instance break, the retarded instance stops, keeping an analogous 
state which can be studied.

This actually can be done or is not feasible? If can't be done just now but 
is from the debugger's developers point of view feasible, consider this a 
feature request.


-Charles Quarra








_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: questions / suggestions about gdb

[Daniel Jacobowitz]

On Tue, May 07, 2002 at 02:58:03PM -0400, Charles James Leonardo Quarra Cappiello wrote:
> Hi,
> 
> 
> I'm an often user of gdb, and i was wondering, since debuggers cant go to 
> past states (no inversibility of the run), it would be nice if two 
> instances of the debugger could run synchronized with a given step offset, 
> so when the advanced instance break, the retarded instance stops, keeping 
> an analogous state which can be studied.
> 
> This actually can be done or is not feasible? If can't be done just now but 
> is from the debugger's developers point of view feasible, consider this a 
> feature request.

GDB just gained a feature that'll do almost what you want: the
`generate-core-file' command.  You can then debug the new corefile to
examine the frozen state.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: questions / suggestions about gdb

[William A. Gatliff]

Charles:


For remote targets, I think that gdb's tracepoints feature could do
this--- assuming the debugging agent implemented them.  Mine doesn't,
at least not yet.

More about tracepoints is available here:


http://www.gnu.org/manual/gdb-5.1.1/html_chapter/gdb_10.html
http://sources.redhat.com/gdb/talks/esc-west-1999/slides/

b.g.


On Tue, May 07, 2002 at 02:58:03PM -0400, Charles James Leonardo Quarra Cappiello wrote:
> Hi,
> 
> 
> I'm an often user of gdb, and i was wondering, since debuggers cant go to 
> past states (no inversibility of the run), it would be nice if two instances 
> of the debugger could run synchronized with a given step offset, so when the 
> advanced instance break, the retarded instance stops, keeping an analogous 
> state which can be studied.
> 
> This actually can be done or is not feasible? If can't be done just now but 
> is from the debugger's developers point of view feasible, consider this a 
> feature request.
> 
> 
> -Charles Quarra
> 
> 
> 
> 
> 
> 
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 

-- 
Bill Gatliff
bgat@billgatliff.com