This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH/RFC] Signals & single-stepping
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Daniel Jacobowitz <drow at false dot org>, Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Date: Thu, 1 Oct 2009 17:15:00 +0100
- Subject: Re: [PATCH/RFC] Signals & single-stepping
- References: <200909301440.n8UEevPb017814@brahms.sibelius.xs4all.nl> <20090930162513.GA10304@caradoc.them.org> <200910011551.19751.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