This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Using reverse execution
- From: Stan Shebs <shebs at apple dot com>
- To: Michael Snyder <michsnyd at cisco dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 23 Sep 2005 17:06:54 -0700
- Subject: Re: Using reverse execution
- References: <43309700.6010507@cisco.com>
Michael Snyder wrote:
Think about forward execution. Does gdb know anything
about system calls? In general, not. Does it know anything
about I/O? Definitely not, except in some special cases.
GDB knows about step, continue, and why-did-we-stop?
Those are its primatives.
I think we know these primitives work for forward execution
because we have 40+ years of experience that says they are
useful. Students learn those in school as part of their formative
experience with debugging, so there is also a bit of tautology -
"these are useful for debugging because these are what we use
for debugging". It's so ingrained that researchers in
algorithmic and specification-based debugging continually
have a hard time getting anybody interested in their approach.
The target, on the other hand, may have lots of
capabilities, and it may not. Maybe it can only
"back up" until the first system call, and then
it gives up.
This comes back to the "first impression" issue. App writers
on Mac OS X have a huge numbers of libraries (frameworks) that
they're suppposed to use, and at the bottom of those there are lots
and lots of system calls going on. If the reverse step button is
perpetually grayed out for every line more complicated than
"a = b + c", users are going to see reversing as a useless feature
and never get in the habit of using it to solve their problems.
Fortunately I don't think we have to give up that easily; an adroitly
designed mechanism could treat system call behavior as a black box
requiring a bit of footwork to reverse past, just as GDB does some
footwork with breakpoints to cover up how we're scribbling trap
instructions all over supposedly read-only memory. :-)
Stan