[commit] Check undebuggable after sigtramp; Was: [patch/rfc] Useinsert_step_resume_breakpoint everywhere

[Andrew Cagney <cagney@gnu.org>]

If you stepi into the trampoline, does gdb know that its got a signal trampoline?  When stepping, this code:

  if (step_range_end != 1
      && (step_over_calls == STEP_OVER_UNDEBUGGABLE
          || step_over_calls == STEP_OVER_ALL)
      && get_frame_type (get_current_frame ()) == SIGTRAMP_FRAME)
    {
      /* The inferior, while doing a "step" or "next", has ended up in
         a signal trampoline (either by a signal being delivered or by
         the signal handler returning).  Just single-step until the
         inferior leaves the trampoline (either by calling the handler
         or returning).  */
      keep_going (ecs);
      return;
    }
should be triggering causing the inferior to single step which makes it setting a breakpoint in main most puzzling.

Try moving the above to before:

  if (step_over_calls == STEP_OVER_UNDEBUGGABLE
      && ecs->stop_func_name == NULL)
    {
      /* There is no symbol, not even a minimal symbol, corresponding
         to the address where we just stopped.  So we just stepped
         inside undebuggable code.  Since we want to step over this
         kind of code, we keep going until the inferior returns from
         the current function.  */
      handle_step_into_function (ecs);
      return;
    }
Per the attached I've done this, I'm no longer seeing the panic.

committed,
Andrew
2004-05-13  Andrew Cagney  <cagney@redhat.com>

	* infrun.c (handle_inferior_event): Check for
	STEP_OVER_UNDEBUGGABLE after signal trampolines and function
	calls.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.160
diff -p -u -r1.160 infrun.c
--- infrun.c	13 May 2004 18:42:29 -0000	1.160
+++ infrun.c	13 May 2004 19:25:13 -0000
@@ -2411,18 +2411,6 @@ process_event_stop_test:
       return;
     }
 
-  if (step_over_calls == STEP_OVER_UNDEBUGGABLE
-      && ecs->stop_func_name == NULL)
-    {
-      /* There is no symbol, not even a minimal symbol, corresponding
-         to the address where we just stopped.  So we just stepped
-         inside undebuggable code.  Since we want to step over this
-         kind of code, we keep going until the inferior returns from
-         the current function.  */
-      handle_step_into_function (ecs);
-      return;
-    }
-
   if (step_range_end != 1
       && (step_over_calls == STEP_OVER_UNDEBUGGABLE
 	  || step_over_calls == STEP_OVER_ALL)
@@ -2434,6 +2422,22 @@ process_event_stop_test:
 	 inferior leaves the trampoline (either by calling the handler
 	 or returning).  */
       keep_going (ecs);
+      return;
+    }
+
+  if (step_over_calls == STEP_OVER_UNDEBUGGABLE
+      && ecs->stop_func_name == NULL)
+    {
+      /* The inferior just stepped into, or returned to, an
+         undebuggable function (where there is no symbol, not even a
+         minimal symbol, corresponding to the address where the
+         inferior stopped).  Since we want to skip this kind of code,
+         we keep going until the inferior returns from this
+         function.  */
+      /* NOTE: cagney/2004-05-12: This test is performed after the
+	 sigtramp test as often sigtramps, while recognized by GDB,
+	 have no symbol information.  */
+      handle_step_into_function (ecs);
       return;
     }
 
From kettenis@chello.nl Thu May 13 19:52:00 2004
From: Mark Kettenis <kettenis@chello.nl>
To: cagney@gnu.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [commit] Check undebuggable after sigtramp; Was: [patch/rfc] Useinsert_step_resume_breakpoint everywhere
Date: Thu, 13 May 2004 19:52:00 -0000
Message-id: <200405131952.i4DJqhxV019690@elgar.kettenis.dyndns.org>
References: <40A01953.7060906@gnu.org> <40A161F4.6050801@gnu.org> <200405122029.i4CKT0r4006056@elgar.kettenis.dyndns.org> <40A28D7B.90007@gnu.org> <40A3CF09.70807@gnu.org>
X-SW-Source: 2004-05/msg00414.html
Content-length: 250

   Date: Thu, 13 May 2004 15:39:53 -0400
   From: Andrew Cagney <cagney@gnu.org>

   Per the attached I've done this, I'm no longer seeing the panic.

Works for me too.  By the way, it was FreeBSD 4.7-RELEASE-p20 that was
showing the problem.

Mark