public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug tdep/30102] New: [gdb/tdep, amd64] Disable i386 unwinders Date: Thu, 09 Feb 2023 14:24:36 +0000 [thread overview] Message-ID: <bug-30102-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=30102 Bug ID: 30102 Summary: [gdb/tdep, amd64] Disable i386 unwinders Product: gdb Version: HEAD Status: NEW Severity: minor Priority: P2 Component: tdep Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- As mentioned here ( https://sourceware.org/pipermail/gdb-patches/2023-February/196724.html ), 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 ... So, why are the i386 unwinders there for amd64? I recently played around with disabling or moving the "amd64 epilogue" unwinder, and while investigating the effect of that, I came across a failure that was due to the "i386 epilogue" unwinder becoming active and giving the wrong answer, which suggest that the i386 unwinders shouldn't be there for amd64. Using this tentative patch: ... 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 *arc hes) 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 *ar ches) 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. */ ... we have for i386 as before, 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 dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME amd64 sigtramp SIGTRAMP_FRAME amd64 prologue NORMAL_FRAME ... -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2023-02-09 14:24 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-09 14:24 vries at gcc dot gnu.org [this message] 2023-02-09 15:21 ` [Bug tdep/30102] " vries at gcc dot gnu.org 2023-02-09 22:02 ` vries at gcc dot gnu.org 2023-02-10 12:56 ` vries at gcc dot gnu.org 2023-02-11 8:04 ` cvs-commit at gcc dot gnu.org 2023-02-11 8:05 ` vries at gcc dot gnu.org
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=bug-30102-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@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: linkBe 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).