This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] enable software single step on alpha-osf
- From: Joel Brobecker <brobecker at gnat dot com>
- To: Andrew Cagney <ac131313 at ges dot redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 5 Aug 2002 11:49:21 -0700
- Subject: Re: [RFA] enable software single step on alpha-osf
- References: <20020718203205.GB26990@gnat.com> <3D4DBBC8.5000906@ges.redhat.com>
> Can you confirm that the code is encountering a situtation where both
> breakpoints_inserted and singlestep_breakpoints_inserted_p are true. I
> think this occures when doing a single step after stepping off of a
> breakpoint. When single stepping off a breakpoint, only
> singlestep_breakpoints_inserted_p would be true.
>
> If this is the case then the comments should make mention of it. It
> also makes the re-ordered if statement part of the patch correct.
Yes, I can confirm this, and this should happen fairly often: suppose
you have inserted a regular breakpoint in your program, anywhere, and
then do a single step. Before resuming the inferior, GDB will re-insert
the breakpoints, and set breakpoints_inserted. At the same time, because
we are doing a s/w single step, singlestep_breakpoints_inserted_p will
be set too. Did I miss something?
As for the re-ordering, I made it because I saw some regressions in the
testsuite after switching to s/w single step. Unfortunately, I don't
remember which ones, I would have to rerun the testsuite without this
change to find them again. But the following comment explains in which
cases the re-ordering was necessary:
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
> The second part of the change is more tricky:
> + stop_pc -= DECR_PC_AFTER_BREAK;
> Is it fixing any failures? Software singlestep can be handled in two
> different ways:
> - as a breakpoint
> - as a hardware single step
> and which is prefered decides if/when there should be a decrement.
Yes, this one is actually fixing most of the failures.
I made several attempts at fixing the regressions before coming with
this solution. This part of the code is quite tricky, and it seems to me
that treating single-step breakpoints as hardware single step is the
simplest way to handle them. I like this because the differences in
processing between software and hardware single-step become smaller.
See for instance the change in breakpoint.c which made the use of this
macro disappear from this file.
> Anyway, the thing I'm having trouble convincing myself that there can't
> be a double decrement -- eg for a hardware watchpoint or similar.
I've tried as much as I can to make sure this can not happen, but I am
not familiar enough to have a good level of confidence in my analysis.
All I can say is: this patch fixes all the regressions observed in the
testsuite after switching to software single step. I know this is no
absolute proof, but that gives me a certain level of confidence.
--
Joel