From: Pedro Alves <palves@redhat.com>
To: Alan Hayward <Alan.Hayward@arm.com>,
"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: Thu, 17 Jan 2019 17:47:00 -0000 [thread overview]
Message-ID: <85a74180-c847-39b1-8ae7-6e59340fb61c@redhat.com> (raw)
In-Reply-To: <20190107163715.5591-1-alan.hayward@arm.com>
On 01/07/2019 04:37 PM, Alan Hayward 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).
I think it'd still be good to add a GCC version check instead of
unconditionally adding the option to all GCCs. The version
of GCC we support building GDB with is not the same concept as which
GCC version the target uses/supports, considering cross debugging / bare
metal, etc. It's plausible some port may be using GCC 4.0, say. Or if
someone wants to test against an old GCC to see what it generated, etc.
Since it's easy to do, I think we should just do it.
A regex similar to the old_gcc variable in gdb.ada/arrayidx.exp should
do it?
>
> 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.
Thanks for doing this. My suspicion was correct. :-)
>
> [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]
Could you add a small test that tests the opposite? I.e., a smoke
testcase with "-fstack-protector-strong" force-enabled? Probably
test both force on and off for full coverage. Then xfail
the test on unfixed GCCs. Which means all GCCs for now.
Thanks,
Pedro Alves
prev parent reply other threads:[~2019-01-17 17:47 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
2019-01-17 16:49 ` [Ping] " Alan Hayward
2019-01-17 17:47 ` Pedro Alves [this message]
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=85a74180-c847-39b1-8ae7-6e59340fb61c@redhat.com \
--to=palves@redhat.com \
--cc=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