This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Centralize DECR_PC_AFTER_BREAK handling from infrun
On Sun, Jan 18, 2004 at 10:19:10AM -0500, Daniel Jacobowitz wrote:
> > > + /* If we've hit a breakpoint, we'll be stopped with SIGTRAP. */
> > > + if (ecs->ws.kind != TARGET_WAITKIND_STOPPED)
> > > + return;
> > > +
> > > + if (ecs->ws.value.sig != TARGET_SIGNAL_TRAP)
> > > + return;
> >
> > The original code didn't check these conditions, right? So why add
> > them here? (Also, the comment doesn't seem to describe the two
> > tests, only the second one.)
>
> The comment does describe both tests; if != TARGET_WAITKIND_STOPPED,
> then we aren't stopped by a signal. The other waitkinds correspond to
> things like exiting and catchpoints, and with the exception of some
> complications in the FORKED/EXECD cases, stop_signal will not get set
> to SIGTRAP. Also, the original code did check these conditions, though
> somewhat indirectly:
>
> if (stop_signal == TARGET_SIGNAL_TRAP)
> {
> /* 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. */
>
> Oh, hum, that's for the first set (thread hit thread-specific BP for a
> different thread). The second thread does this:
>
> if (stop_signal == TARGET_SIGNAL_TRAP
> || (breakpoints_inserted &&
> (stop_signal == TARGET_SIGNAL_ILL
> || stop_signal == TARGET_SIGNAL_EMT))
> || stop_soon == STOP_QUIETLY
> || stop_soon == STOP_QUIETLY_NO_SIGSTOP)
>
> The stop_soon's aren't relevant here, since they're handled before
> DECR_PC_AFTER_BREAK, but the ILL/EMT are relevant. They should be
> added to adjust_pc_after_break - thanks!
Actually, I'm not sure they should. The question is, on an operating
system such that hitting a breakpoint causes SIGILL, should
DECR_PC_AFTER_BREAK be applied? I don't have a machine such that
breakpoints cause SIGILL, but I tested x86 and alpha (both
DECR_PC_AFTER_BREAK targets). On x86 a SIGILL leaves the PC pointing
at the beginning of the illegal instruction, and on Alpha a SIGILL
leaves the PC pointing to the second instruction after the illegal one.
In neither case does that match the behavior of DECR_PC_AFTER_BREAK.
So this will become a comment also.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer