From: Alan Hayward <Alan.Hayward@arm.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: nd <nd@arm.com>
Subject: Re: [PATCH] Testsuite: Ensure stack protection is off for GCC
Date: Mon, 07 Jan 2019 16:57:00 -0000 [thread overview]
Message-ID: <E3635032-C274-4184-9C34-BB618A51E254@arm.com> (raw)
In-Reply-To: <20190107163715.5591-1-alan.hayward@arm.com>
Forgot to mention: this fixes ~60 tests when running make check on Ubuntu.
> On 7 Jan 2019, at 16:37, Alan Hayward <Alan.Hayward@arm.com> wrote:
>
> Using -fstack-protector-strong will cause GDB to break on the wrong line
> when placing a breakpoint on a function. This is caused by due to
> inadequate dwarf line numbering, and is being tracked by the GCC bug
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
>
> GCC (and Clang) provided by Debian/Ubuntu default to Stack Protector
> being enabled.
>
> So, ensure that when running the GDB testsuite, stack protector is always
> turned off for GCC (option has existed since GCC 4.1.0).
>
> Also, ensure that this does not cause infinite recursion due to
> test_compiler_info having to compile a file itself.
>
> Restore change in ovldbreak.exp which worked around the issue.
>
> [Side note - this fix would be improved by checking for Ubuntu/Debian,
> but I don't see any existing checks for that in the testsuite]
>
> 2019-01-07 Alan Hayward <alan.hayward@arm.com>
>
> * gdb.cp/ovldbreak.exp: Only allow a single break line.
> * lib/gdb.exp (get_compiler_info): Use getting_compiler_info option.
> (gdb_compile): Remove stack protector for GCC and prevent recursion.
> ---
> gdb/testsuite/gdb.cp/ovldbreak.exp | 2 +-
> gdb/testsuite/lib/gdb.exp | 17 +++++++++++++++--
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.cp/ovldbreak.exp b/gdb/testsuite/gdb.cp/ovldbreak.exp
> index 494f2a12e9..3ffd04209a 100644
> --- a/gdb/testsuite/gdb.cp/ovldbreak.exp
> +++ b/gdb/testsuite/gdb.cp/ovldbreak.exp
> @@ -209,7 +209,7 @@ for {set idx 0} {$idx < [llength $overloads]} {incr idx} {
>
> # Verify the breakpoints.
> set bptable "Num\[\t \]+Type\[\t \]+Disp Enb Address\[\t \]+What.*\[\r\n]+"
> -append bptable "\[0-9\]+\[\t \]+breakpoint\[\t \]+keep\[\t \]y\[\t \]+$hex\[\t \]+in main(\\((|void)\\))? at.*$srcfile:4\[89\]\[\r\n\]+"
> +append bptable "\[0-9\]+\[\t \]+breakpoint\[\t \]+keep\[\t \]y\[\t \]+$hex\[\t \]+in main(\\((|void)\\))? at.*$srcfile:49\[\r\n\]+"
> append bptable "\[\t \]+breakpoint already hit 1 time\[\r\n\]+."
> foreach ovld $overloads {
> append bptable [format "\[0-9\]+\[\t \]+breakpoint\[\t \]+keep y\[\t \]+$hex\[\t \]+in foo::overload1arg\\(%s\\) at.*$srcfile:%d\[\r\n\]+" $ovld \
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index ed9f89d5a7..7443638a72 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -3276,12 +3276,12 @@ proc get_compiler_info {{arg ""}} {
> # We have to use -E and -o together, despite the comments
> # above, because of how DejaGnu handles remote host testing.
> set ppout "$outdir/compiler.i"
> - gdb_compile "${ifile}" "$ppout" preprocess [list "$arg" quiet]
> + gdb_compile "${ifile}" "$ppout" preprocess [list "$arg" quiet getting_compiler_info]
> set file [open $ppout r]
> set cppout [read $file]
> close $file
> } else {
> - set cppout [ gdb_compile "${ifile}" "" preprocess [list "$arg" quiet] ]
> + set cppout [ gdb_compile "${ifile}" "" preprocess [list "$arg" quiet getting_compiler_info] ]
> }
> eval log_file $saved_log
>
> @@ -3519,6 +3519,7 @@ proc gdb_compile {source dest type options} {
> }
> set shlib_found 0
> set shlib_load 0
> + set getting_compiler_info 0
> foreach opt $options {
> if {[regexp {^shlib=(.*)} $opt dummy_var shlib_name]
> && $type == "executable"} {
> @@ -3549,11 +3550,23 @@ proc gdb_compile {source dest type options} {
> }
> } elseif { $opt == "shlib_load" && $type == "executable" } {
> set shlib_load 1
> + } elseif { $opt == "getting_compiler_info" } {
> + # If this is set, calling test_compiler_info will cause recursion.
> + set getting_compiler_info 1
> } else {
> lappend new_options $opt
> }
> }
>
> + # Ensure stack protector is disabled for GCC, as this will causes problems
> + # with DWARF line numbering.
> + # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
> + # This option defaults to on for Debian/Ubuntu.
> + if { $getting_compiler_info == 0 && [test_compiler_info "gcc-*"] } {
> + # Put it at the front to not override any user-provided value
> + lappend new_options "early_flags=-fno-stack-protector"
> + }
> +
> # Because we link with libraries using their basename, we may need
> # (depending on the platform) to set a special rpath value, to allow
> # the executable to find the libraries it depends on.
> --
> 2.17.2 (Apple Git-113)
>
next prev parent reply other threads:[~2019-01-07 16:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 16:37 Alan Hayward
2019-01-07 16:57 ` Alan Hayward [this message]
2019-01-17 16:49 ` [Ping] " Alan Hayward
2019-01-17 17:47 ` Pedro Alves
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=E3635032-C274-4184-9C34-BB618A51E254@arm.com \
--to=alan.hayward@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=nd@arm.com \
/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