From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/tdep] Don't use i386 unwinder for amd64
Date: Fri, 10 Feb 2023 13:56:02 +0100 [thread overview]
Message-ID: <20230210125602.20437-1-tdevries@suse.de> (raw)
For i386 we have these unwinders:
...
$ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders"
The target architecture is set to "i386".
dummy DUMMY_FRAME
dwarf2 tailcall TAILCALL_FRAME
inline INLINE_FRAME
i386 epilogue NORMAL_FRAME
dwarf2 NORMAL_FRAME
dwarf2 signal SIGTRAMP_FRAME
i386 stack tramp NORMAL_FRAME
i386 sigtramp SIGTRAMP_FRAME
i386 prologue NORMAL_FRAME
...
and for amd64:
...
$ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
The target architecture is set to "i386:x86-64".
dummy DUMMY_FRAME
dwarf2 tailcall TAILCALL_FRAME
inline INLINE_FRAME
python NORMAL_FRAME
amd64 epilogue NORMAL_FRAME
i386 epilogue NORMAL_FRAME
dwarf2 NORMAL_FRAME
dwarf2 signal SIGTRAMP_FRAME
amd64 sigtramp SIGTRAMP_FRAME
amd64 prologue NORMAL_FRAME
i386 stack tramp NORMAL_FRAME
i386 sigtramp SIGTRAMP_FRAME
i386 prologue NORMAL_FRAME
...
ISTM me there's no reason for the i386 unwinders to be there for amd64.
Furthermore, there's a generic need to play around with enabling and disabling
unwinders, see PR8434. Currently, that's only available for both the
dwarf2 unwinders at once using "maint set dwarf unwinders on/off".
If I manually disable the "amd64 epilogue" unwinder, the "i386 epilogue"
unwinder becomes active and gives the wrong answer, while I'm actually
interested in the result of the dwarf2 unwinder. Of course I can also
manually disable the "i386 epilogue", but I take the fact that I have to do
that as evidence that on amd64, the "i386 epilogue" is not only unnecessary,
but in the way.
Fix this by only adding the i386 unwinders only if
"info.bfd_arch_info->bits_per_word == 32".
Note that for the x32 abi (x86_64/-mx32) the unwinder list is the same as for
amd64 (x86_64/-m64), without and with this commit.
Tested on x86_64-linux, -m64 and -m32. Not tested with -mx32.
PR tdep/30102
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30102
---
gdb/i386-tdep.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 580664d2ce5..8dccae633f7 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -8613,7 +8613,8 @@ i386_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
appended to the list first, so that it supercedes the DWARF
unwinder in function epilogues (where the DWARF unwinder
currently fails). */
- frame_unwind_append_unwinder (gdbarch, &i386_epilogue_frame_unwind);
+ if (info.bfd_arch_info->bits_per_word == 32)
+ frame_unwind_append_unwinder (gdbarch, &i386_epilogue_frame_unwind);
/* Hook in the DWARF CFI frame unwinder. This unwinder is appended
to the list before the prologue-based unwinders, so that DWARF
@@ -8792,9 +8793,12 @@ i386_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
tdep-> bnd0_regnum = -1;
/* Hook in the legacy prologue-based unwinders last (fallback). */
- frame_unwind_append_unwinder (gdbarch, &i386_stack_tramp_frame_unwind);
- frame_unwind_append_unwinder (gdbarch, &i386_sigtramp_frame_unwind);
- frame_unwind_append_unwinder (gdbarch, &i386_frame_unwind);
+ if (info.bfd_arch_info->bits_per_word == 32)
+ {
+ frame_unwind_append_unwinder (gdbarch, &i386_stack_tramp_frame_unwind);
+ frame_unwind_append_unwinder (gdbarch, &i386_sigtramp_frame_unwind);
+ frame_unwind_append_unwinder (gdbarch, &i386_frame_unwind);
+ }
/* If we have a register mapping, enable the generic core file
support, unless it has already been enabled. */
base-commit: be01687991aa6c8517b3e635b8f13b0bac6a851a
--
2.35.3
next reply other threads:[~2023-02-10 12:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 12:56 Tom de Vries [this message]
2023-02-10 17:01 ` John Baldwin
2023-02-11 8:14 ` Tom de Vries
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=20230210125602.20437-1-tdevries@suse.de \
--to=tdevries@suse.de \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).