Re: [PATCH] Honour SIGILL and SIGSEGV in cancel breakpoint

[Yao Qi <yao@codesourcery.com>]

Pedro Alves <palves@redhat.com> writes:

> Instead of duplicating the code and comments, please factor out
> the SIGTRAP+SIGILL+SIGSEGVs checks to a helper function.  On the GDB side,
> we have linux_nat_lp_status_is_event, and we see that it's also used
> on count_count_events_callback (which gdbserver also has), which makes
> sense, as it's counting threads that had breakpoint SIGTRAP-ish
> events (though I'm not sure why we only consider breakpoints when
> selecting the event lwp).

I take a look at linux_nat_lp_status_is_event and email discussions on
adding this function <https://sourceware.org/ml/gdb-patches/2010-07/msg00275.html>,
a new function lp_status_is_sigtrap_like_event is added.  I don't use
the same name because I feel linux_nat_lp_status_is_event isn't clear
enough.  Secondly, I don't use "waitstatus.kind == TARGET_WAITKIND_IGNORE"
condition check inside lp_status_is_sigtrap_like_event, because IMO it
was used in linux_nat_lp_status_is_event due to lack of lp->status_p
flag, as the comments described.  However, in GDBserver, we have
status_pending_p flag, so "waitstatus.kind == TARGET_WAITKIND_IGNORE" is
not needed.

count_events_callback and select_event_lwp_callback in GDBServer need to
honour SIGILL and SIGSEGV too.  I write a patch to call
lp_status_is_sigtrap_like_event in them, but regression test result
isn't changed, which is a surprise to me.  I thought some fails should
be fixed.  I'll look into it deeply.

I post the updated patch to fix the issue we've seen on canceling breakpoint.

-- 
Yao (齐尧)

From: Yao Qi <yao@codesourcery.com>
Subject: [PATCH] Honour SIGILL and SIGSEGV in cancel breakpoint

I see the following fail on arm-none-linux-gnueabi testing,

(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
[Switching to Thread 1003]^M
handler (signo=10) at
/scratch/yqi/arm-none-linux-gnueabi/src/gdb-trunk/gdb/testsuite/gdb.threads/sigstep-threads.c:33^M
33        tgkill (getpid (), gettid (), SIGUSR1);       /* step-2 */^M
(gdb) FAIL: gdb.threads/sigstep-threads.exp: continue

the cause is that GDBserver doesn't cancel the breakpoint if the stop
signal is SIGILL.  The kernel used here is a little old, 2.6.x, and
doesn't translate SIGILL to SIGTRAP when program hits breakpoint
instruction (which is an illegal instruction actually).  GDB and
GDBserver can translate SIGILL to SIGTRAP under certain circumstance,
so it is not a problem here.  See gdbserver/linux-low.c:linux_wait_1

  /* If this event was not handled before, and is not a SIGTRAP, we
     report it.  SIGILL and SIGSEGV are also treated as traps in case
     a breakpoint is inserted at the current PC.  If this target does
     not support internal breakpoints at all, we also report the
     SIGTRAP without further processing; it's of no concern to us.  */
  maybe_internal_trap
    = (supports_breakpoints ()
       && (WSTOPSIG (w) == SIGTRAP
	   || ((WSTOPSIG (w) == SIGILL
		|| WSTOPSIG (w) == SIGSEGV)
	       && (*the_low_target.breakpoint_at) (event_child->stop_pc))));

However, SIGILL and SIGSEGV is not considered when cancelling
breakpoint, which causes the fail above.  That is, when GDB is doing
software single step on address ADDR, both thread A and thread B hits the
software single step breakpoint, and get SIGILL.  GDB selects the event
from thread A, removes the software single step breakpoint, and resume
the program.  The event (SIGILL) from thread B is reported to GDB, but
GDB doesn't regard this SIGILL as SIGTRAP, because the breakpoint on
address ADDR was removed, so GDB reports "Program received signal
SIGILL".

The patch is to allow calling cancel_breakpoint if the signal is
SIGILL and SIGSEGV.  This patch fixes the fail above.

gdb/gdbserver:

2014-09-18  Yao Qi  <yao@codesourcery.com>

	* linux-low.c (lp_status_is_sigtrap_like_event): New function.
	(cancel_breakpoints_callback): Call
	lp_status_is_sigtrap_like_event.
	(linux_low_filter_event): Likewise.

diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
index ec3260e..9c9a303 100644
--- a/gdb/gdbserver/linux-low.c
+++ b/gdb/gdbserver/linux-low.c
@@ -1739,6 +1739,20 @@ cancel_breakpoint (struct lwp_info *lwp)
   return 0;
 }
 
+/* Check for SIGTRAP-like events in LP.  */
+
+static int
+lp_status_is_sigtrap_like_event (struct lwp_info *lp)
+{
+  return (lp->status_pending_p
+	  && WIFSTOPPED (lp->status_pending)
+	  && (WSTOPSIG (lp->status_pending) == SIGTRAP
+	      /* SIGILL and SIGSEGV are also treated as traps in case a
+		 breakpoint is inserted at the current PC.  */
+	      || WSTOPSIG (lp->status_pending) == SIGILL
+	      || WSTOPSIG (lp->status_pending) == SIGSEGV));
+}
+
 /* Do low-level handling of the event, and check if we should go on
    and pass it to caller code.  Return the affected lwp if we are, or
    NULL otherwise.  */
@@ -1936,7 +1950,7 @@ linux_low_filter_event (ptid_t filter_ptid, int lwpid, int wstat)
 		 the core before this one is handled.  All-stop always
 		 cancels breakpoint hits in all threads.  */
 	      if (non_stop
-		  && WSTOPSIG (wstat) == SIGTRAP
+		  && lp_status_is_sigtrap_like_event (child)
 		  && cancel_breakpoint (child))
 		{
 		  /* Throw away the SIGTRAP.  */
@@ -2271,9 +2285,7 @@ cancel_breakpoints_callback (struct inferior_list_entry *entry, void *data)
 
   if (thread->last_resume_kind != resume_stop
       && thread->last_status.kind == TARGET_WAITKIND_IGNORE
-      && lp->status_pending_p
-      && WIFSTOPPED (lp->status_pending)
-      && WSTOPSIG (lp->status_pending) == SIGTRAP
+      && lp_status_is_sigtrap_like_event (lp)
       && !lp->stepping
       && !lp->stopped_by_watchpoint
       && cancel_breakpoint (lp))