Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org, brobecker@adacore.com
Subject: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3
Date: Fri, 30 Dec 2011 02:45:00 -0000	[thread overview]
Message-ID: <20111229231251.GA27794@host2.jankratochvil.net> (raw)
In-Reply-To: <201112282009.pBSK9LHn029918@glazunov.sibelius.xs4all.nl>

On Wed, 28 Dec 2011 21:09:21 +0100, Mark Kettenis wrote:
> Hmm, did you actually try using ON_STACK?

No.

> We specifically treat
> SIGSEGV as a potential breakpoint to deal with non-executable stacks.

I can confirm at least on RHEL-6.2 x86_64 a breakpoint on non-executable stack
gets properly recognized by GDB.

I have dropped those comments change.  I understand it was incorrect from me
to include it into that mostly unrelated patch.

As ON_STACK is a valid option sure one may prefer to convert all the archs to
ON_STACK instead of fixing AT_ENTRY_POINT; not preferred by me TBH.


Thanks,
Jan


2011-12-30  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix regression for gdb.cp/gdb2495.exp with gcc-4.7.
	* arch-utils.c (displaced_step_at_entry_point): Incrase BP_LEN skip to
	3 times.
	* infcall.c (call_function_by_hand) <AT_SYMBOL>: Move it upwards and
	fall through into AT_ENTRY_POINT.
	(call_function_by_hand) <AT_ENTRY_POINT>: New variable bp_len.  Adjust
	DUMMY_ADDR with it.
	* ppc-linux-tdep.c (ppc_linux_displaced_step_location): Increase
	PPC_INSN_SIZE skip to 3 times.

--- a/gdb/arch-utils.c
+++ b/gdb/arch-utils.c
@@ -86,7 +86,7 @@ displaced_step_at_entry_point (struct gdbarch *gdbarch)
      We don't want displaced stepping to interfere with those
      breakpoints, so leave space.  */
   gdbarch_breakpoint_from_pc (gdbarch, &addr, &bp_len);
-  addr += bp_len * 2;
+  addr += bp_len * 3;
 
   return addr;
 }
--- a/gdb/infcall.c
+++ b/gdb/infcall.c
@@ -627,17 +628,6 @@ call_function_by_hand (struct value *function, int nargs, struct value **args)
 				args, nargs, target_values_type,
 				&real_pc, &bp_addr, get_current_regcache ());
       break;
-    case AT_ENTRY_POINT:
-      {
-	CORE_ADDR dummy_addr;
-
-	real_pc = funaddr;
-	dummy_addr = entry_point_address ();
-	/* A call dummy always consists of just a single breakpoint, so
-	   its address is the same as the address of the dummy.  */
-	bp_addr = dummy_addr;
-	break;
-      }
     case AT_SYMBOL:
       /* Some executables define a symbol __CALL_DUMMY_ADDRESS whose
 	 address is the location where the breakpoint should be
@@ -661,11 +652,41 @@ call_function_by_hand (struct value *function, int nargs, struct value **args)
 	    dummy_addr = gdbarch_convert_from_func_ptr_addr (gdbarch,
 							     dummy_addr,
 							     &current_target);
+	    /* A call dummy always consists of just a single breakpoint,
+	       so it's address is the same as the address of the dummy.  */
+	    bp_addr = dummy_addr;
+	    break;
 	  }
-	else
-	  dummy_addr = entry_point_address ();
-	/* A call dummy always consists of just a single breakpoint,
-	   so it's address is the same as the address of the dummy.  */
+	break;
+      }
+      /* FALLTHROUGH */
+    case AT_ENTRY_POINT:
+      {
+	CORE_ADDR dummy_addr;
+	int bp_len;
+
+	real_pc = funaddr;
+	dummy_addr = entry_point_address ();
+
+	/* If the inferior call throws an uncaught C++ exception,
+	   the inferior unwinder tries to unwind all frames, including
+	   our dummy frame.  The unwinder determines the address of
+	   the calling instruction by subtracting 1 to the return
+	   address.  So, using the entry point's address as the return
+	   address would lead the unwinder to use the unwinding
+	   information of the code immediately preceding the entry
+	   point.  This information, if found, is invalid for the dummy
+	   frame, and can potentially crash the inferior's unwinder.
+	   Therefore, we use the second byte (approximately,
+	   alignments depending on GDBARCH).  It does not matter if it
+	   is placed inside the very first instruction, nothing tries
+	   to execute it.  */
+
+	gdbarch_breakpoint_from_pc (gdbarch, &dummy_addr, &bp_len);
+	dummy_addr += bp_len;
+
+	/* A call dummy always consists of just a single breakpoint, so
+	   its address is the same as the address of the dummy.  */
 	bp_addr = dummy_addr;
 	break;
       }
--- a/gdb/ppc-linux-tdep.c
+++ b/gdb/ppc-linux-tdep.c
@@ -1075,7 +1075,7 @@ ppc_linux_displaced_step_location (struct gdbarch *gdbarch)
       /* Inferior calls also use the entry point as a breakpoint location.
 	 We don't want displaced stepping to interfere with those
 	 breakpoints, so leave space.  */
-      ppc_linux_entry_point_addr = addr + 2 * PPC_INSN_SIZE;
+      ppc_linux_entry_point_addr = addr + 3 * PPC_INSN_SIZE;
     }
 
   return ppc_linux_entry_point_addr;


  reply	other threads:[~2011-12-29 23:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-22 20:49 [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 Jan Kratochvil
2011-12-27  6:23 ` Joel Brobecker
2011-12-28 16:30   ` Jan Kratochvil
2011-12-28 18:47     ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #2 Jan Kratochvil
2011-12-28 20:40       ` Mark Kettenis
2011-12-30  2:45         ` Jan Kratochvil [this message]
2011-12-30  8:46           ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3 Joel Brobecker
2011-12-30 11:11             ` Mark Kettenis
2011-12-30 14:16               ` Jan Kratochvil
2011-12-31  2:56               ` Peter Schauer
2011-12-30 11:25             ` Jan Kratochvil
2012-01-01 22:22               ` Jan Kratochvil
2012-01-02  2:45                 ` Joel Brobecker
2012-01-02  2:58                   ` Jan Kratochvil
2012-01-03 14:45                     ` Regression on PowerPC (Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3) Ulrich Weigand
2012-01-03 15:52                       ` Joel Brobecker
2012-01-04 14:01                       ` [revert] " Jan Kratochvil
2012-01-04 14:09                         ` Joel Brobecker
2012-03-08 23:24                         ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #4 [Re: [revert] Regression on PowerPC] Jan Kratochvil
2012-03-09  7:22                           ` cancel: " Jan Kratochvil
2012-01-02 14:10 ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 Pedro Alves
2012-01-02 14:20   ` Jan Kratochvil
2012-01-02 14:44     ` Pedro Alves
2012-01-02 14:53       ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111229231251.GA27794@host2.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox