Re: [patch] Fix linux-ia64 on SIGILL for deleted breakpoint

[Pedro Alves <pedro@codesourcery.com>]

On Monday 19 July 2010 09:58:17, Jan Kratochvil wrote:
> Hi,
> 
> in some cases ia64 can generate SIGILL instead of SIGTRAP.  Guessing it is
> a CPU bug instead of Linux kernel bug (but I may be wrong).
> 	https://bugzilla.redhat.com/show_bug.cgi?id=615538
> 	http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/ia64-sigill.c?cvsroot=systemtap
> 
> Anyway FSF GDB already contains code for handling such cases (and not only
> SIGILL).  Just the time it gets executed the breakpoint which generated the
> signal may be already deleted and GDB stops with:
> 	Program received signal SIGILL, Illegal instruction.
> 
> I do not think it can be solved fully target-independent.  linux-nat.c already
> does some postponing of signals using
> 	kill_lwp (GET_LWP (lp->ptid), WSTOPSIG (lp->status));
> and the moment linux-nat.c will read back such postponed signal its breakpoint
> may be already deleted (and thus it will never get to target-independent parts
> of GDB such as infrun.c).

That's a general problem with "real" SIGTRAP breakpoints as well.  linux-nat.c
handles this by "cancelling" the breakpoint, so that it is hit again later
on resume.  "cancelling" just means something like:

 Since we're not reporting the event to the user right now, just ignore
 it.  If the breakpoint is still inserted later,
 the next time we ask the target for an event (on resume), the inferior
 will trap on the same breakpoint again; we'll report it then, if so.

I don't see why this can't be extended to handle SIGILL breakpoints too
(with the difference that there's no PC adjustment required, you just
discard the signal).

Simply swapping SIGILL for SIGTRAP without accounting for the PC
adjustment that GDB will try to do on the SIGTRAP (thinking it was a real
SIGTRAP) makes me a bit nervous.

-- 
Pedro Alves