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,
¤t_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;
next prev parent 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