From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>
Subject: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #2
Date: Wed, 28 Dec 2011 18:47:00 -0000 [thread overview]
Message-ID: <20111228180148.GA18057@host2.jankratochvil.net> (raw)
In-Reply-To: <20111228161208.GB10556@host2.jankratochvil.net>
On Wed, 28 Dec 2011 17:12:08 +0100, Jan Kratochvil wrote:
> I will yet try to adjust it somehow.
This one may work.
displaced_step_at_entry_point has been already assuming after
gdbarch_breakpoint_from_pc (gdbarch, &addr, &bp_len);
addr += bp_len * 2;
ADDR can be used as an executable instruction address. Therefore the
gdb_buffered_insn_length adjustment was possibly needlessly strong
(and needlessly expensive).
Expecting _start is at least as long as 2 * BP_LEN looks definitely valid and
on archs supporting displaced stepping the assumption of _start length 3 *
BP_LEN + gdbarch_max_insn_length looks also safe (also these archs have
properly set gdbarch_max_insn_length which is therefore small enough).
I am not convinced it works on each arch but it works at least on something so
special like ia64 so it really may work everywhere. Displaced stepping is not
implemented on each arch so the displaced_step_at_entry_point does not prove it
works on every arch. While this proposed code applies to (almost -
AT_ENTRY_POINT) any arch, so there is still a regression risk.
No regressions on {x86_64,x86_64-m32,i686}-fedorarawhide-linux-gnu.
Thanks,
Jan
2011-12-28 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) <ON_STACK>: New comment on stack
executability.
(call_function_by_hand) <AT_SYMBOL>: Drop comment on ON_STACK
preference. 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,26 +628,16 @@ call_function_by_hand (struct value *function, int nargs, struct value **args)
switch (gdbarch_call_dummy_location (gdbarch))
{
case ON_STACK:
+ /* ON_STACK has problems on some targets featuring security policies
+ disabling target stack executability. */
sp = push_dummy_code (gdbarch, sp, funaddr,
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
- placed. Once all targets are using the overhauled frame code
- this can be deleted - ON_STACK is a better option. */
+ placed. */
{
struct minimal_symbol *sym;
CORE_ADDR dummy_addr;
@@ -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-28 18:02 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 ` Jan Kratochvil [this message]
2011-12-28 20:40 ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #2 Mark Kettenis
2011-12-30 2:45 ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3 Jan Kratochvil
2011-12-30 8:46 ` 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=20111228180148.GA18057@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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