public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Tom de Vries <vries@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] [gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp Date: Mon, 23 Jan 2023 10:54:46 +0000 (GMT) [thread overview] Message-ID: <20230123105446.4A8B23858D32@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=eb015bf86b6c6764f8acfea01a25a63e9b492dc5 commit eb015bf86b6c6764f8acfea01a25a63e9b492dc5 Author: Tom de Vries <tdevries@suse.de> Date: Mon Jan 23 11:54:43 2023 +0100 [gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is compiled with nodebug, to prevent the dwarf unwinders from taking effect. For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by default, generating an .eh_frame section contribution which might enable the dwarf unwinders and bypass the architecture-specific unwinders. Currently, that happens to be not the case due to the current implementation of epilogue_unwind_valid, which assumes that in absence of debug info proving that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid. That may change though, see PR30028, in which case gdb.base/unwind-on-each-insn.exp stops being a regression test for commit 49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder"). Fix this by making sure that we don't use .eh_frame info regardless of epilogue_unwind_valid, simply by not generating it using -fno-asynchronous-unwind-tables. Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers gcc 7.5.0 and clang 13.0.1. Diff: --- gdb/testsuite/gdb.base/unwind-on-each-insn.exp | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/gdb.base/unwind-on-each-insn.exp b/gdb/testsuite/gdb.base/unwind-on-each-insn.exp index 5e822effaf1..fc48bf5c061 100644 --- a/gdb/testsuite/gdb.base/unwind-on-each-insn.exp +++ b/gdb/testsuite/gdb.base/unwind-on-each-insn.exp @@ -25,9 +25,19 @@ standard_testfile .c -foo.c +set debug_flags {debug} +set nodebug_flags {nodebug} + +# Make sure that we don't use .eh_frame info, by not generating it, +# using -fno-asynchronous-unwind-tables, if supported. +if { [gdb_can_simple_compile fno-asynchronous-unwind-tables \ + { void foo () { } } object -fno-asynchronous-unwind-tables] } { + lappend nodebug_flags additional_flags=-fno-asynchronous-unwind-tables +} + if {[prepare_for_testing_full "failed to prepare" \ - [list ${testfile} debug \ - $srcfile {debug} $srcfile2 {nodebug}]]} { + [list ${testfile} $debug_flags \ + $srcfile $debug_flags $srcfile2 $nodebug_flags]]} { return -1 }
reply other threads:[~2023-01-23 10:54 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20230123105446.4A8B23858D32@sourceware.org \ --to=vries@sourceware.org \ --cc=gdb-cvs@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).