This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: breakpoint.c and infrun.c changes
- To: kevinb at cygnus dot com
- Subject: Re: RFA: breakpoint.c and infrun.c changes
- From: Stan Shebs <shebs at cygnus dot com>
- Date: Thu, 23 Sep 1999 19:41:07 -0700
- CC: jimb at cygnus dot com, msnyder at cygnus dot com, gdb-patches at sourceware dot cygnus dot com
Date: Fri, 17 Sep 1999 12:44:45 -0700
From: Kevin Buettner <kevinb@cygnus.com>
My patch for fixing this bug is below. The changes to breakpoint.c
alone fix the bug (on the i386 anyway); the changes to infrun.c are
cleanup.
A very nice piece of analysis! I had to read through it about four
times to understand it all, but the reasoning seems sound. As we
discussed on the phone, testing on a small assortment of relevant
platforms is still worthwhile, just in case practice is trickier than
theory. :-)
This will certainly help to shorten and straighten out the execution
control code. As people have accreted hacks over the years, it becomes
harder and harder to know why something is there, and one descends into
voodoo-fixing (as old ChangeLog entries attest).
I'd also like us to look into JimB's suggestion that the PC could be
pre-adjusted according to DECR_PC_AFTER_BREAK before anything in
execution control looks at it. The analysis for that would involve
looking at all the places where the PC is saved away, there are quite
a few of them.
In any case, assuming testing doesn't report any regression, I'd like
to get this patch in soon so I can do my next phase of infrun
simplification - there are just three more gotos left in
handle_inferior_event, but so far I can't see how to evaporate them
validly without breaking the function into a number of smaller pieces.
Also, it would be really great to add a testsuite case for temporary
breakpoints and stepping that will always fail without your changes,
and will pass otherwise, since it seems that there is currently no
test to detect the failure you're fixing.
Stan