Re: [PATCH/RFC] Signals & single-stepping

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 01 October 2009 15:51:18, Pedro Alves wrote:
> On Wednesday 30 September 2009 17:25:13, Daniel Jacobowitz wrote:
> > Your patch doesn't reintroduce the problem from the PR, and the new
> > tests in interrupt.exp pass on x86_64-linux.  I would really love
> > someone else to volunteer to review it though - trap_expected confuses
> > me horribly.  I'd guess this change could lead to hitting (and
> > displaying) the breakpoint at the current PC a second time, which is
> > undesirable.
> 
> Yes, this messes with hit counts, reruns user breakpoint
> commands, etc.  Even some internal breakpoints don't like to
> be re-hit for no reason.  E.g., see linux-thread-db.c:check_event
> "Cannot get thread event message".
> 
> I think the issue is that when stepping over a breakpoint,
> for simplicity, GDB always removes all breakpoints.  What if
> we made it remove only breakpoints at stop_pc?

Bah, this would miss the same breakpoint we're stepping over,
if the signal handler calls it:

void
sighandler (int signo)
{
  foo ();
}

void
foo ()
{
}

(gdb) b foo
(gdb) c
<stopped at foo>
(gdb) signal SIGUSR1
<the foo call in signal handler is missed on targets
that can't step into signal handlers>

If we go the breakpoint re-hit path, it would be
nicer if we detected rehits and ignore them.  I'm not sure
how to distinguish the situation above from a rehit
due to single-stepping the breakpoint insn -- check
if the current frame id changed?  If we go that
path, we should perhaps also declare that code that
checks for breakpoint hits behind infrun.c's back
(like that check_event) should be more permissive of
re-hits, or otherwise be moved to the core stop
bpstat mechanism.

There may be other issues with rehits I haven't
thought of.  I'm just thinking out loud.

-- 
Pedro Alves