public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Jan Vrany <jan.vrany@fit.cvut.cz>
Cc: gdb-patches@sourceware.org, Pedro Alves <palves@redhat.com>
Subject: Re: [PATCH] Fix various tests to use -no-pie linker flag when needed
Date: Thu, 13 Dec 2018 17:13:00 -0000	[thread overview]
Message-ID: <98c5b4d58f5413502ce9ee519923b5a8@polymtl.ca> (raw)
In-Reply-To: <20181213152049.7702-1-jan.vrany@fit.cvut.cz>

On 2018-12-13 10:20, Jan Vrany wrote:
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 5a5713b114..f25df0a772 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -3482,6 +3482,7 @@ set gdb_saved_set_unbuffered_mode_obj ""
>  #     dynamically load libraries at runtime.  For example, on Linux, 
> this adds
>  #     -ldl so that the test can use dlopen.
>  #   - nowarnings:  Inhibit all compiler warnings.
> +#   - nopie: Prevent creation of PIE executables.
>  #
>  # And here are some of the not too obscure options understood by 
> DejaGnu that
>  # influence the compilation:
> @@ -3603,6 +3604,18 @@ proc gdb_compile {source dest type options} {
>  	set options [lreplace $options $nowarnings $nowarnings $flag]
>      }
> 
> +    # Replace the "nopie" option with the appropriate additional_flags
> +    # to disable PIE executables.
> +    set nopie [lsearch -exact $options nopie]
> +    if {$nopie != -1} {
> +	if [target_info exists gdb,nowarnings_flag] {

s/nowarnings_flag/nopie_flag/

> +	    set flag "ldflags=[target_info gdb,nopie_flag]"
> +	} else {
> +	    set flag "ldflags=-no-pie"
> +	}
> +	set options [lreplace $options $nopie $nopie $flag]
> +    }
> +

With this, people who run tests against gcc 4.8 will be forced to create 
a specific board file to override the nopie_flag, whereas currently it's 
possible to do it all from the command line:

$ make check TESTS="gdb.arch/amd64-disp-step.exp" 
RUNTESTFLAGS='CC_FOR_TARGET="gcc-4.8"'

One way to avoid that would be to auto-detect whether the toolchain 
generates PIE executables by default.  If the nopie option is requested 
but the toolchain generates non-PIE by default, we would not pass any 
additional flags.  On Linux, we can generate an executable and use 
"readelf -h" to check for the type of ELF artifact generated.

Another way would be to check whether the toolchain knows the -no-pie 
flag, and assume that if it doesn't, it's because it probably generates 
non-PIE by default, so we don't need to pass anything.  That would break 
with toolchains that generate PIE by default but use another flag to 
disable PIE (I am not aware of any that fits in this category), but 
people would still have the possibiliy of overriding it with a board 
file.

Or maybe this just fine, and we can require the few people who test 
against gcc 4.8 to use a board file.

Simon

  reply	other threads:[~2018-12-13 17:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 19:37 Jan Vrany
2018-09-07 20:43 ` Tom Tromey
2018-09-07 22:18   ` Simon Marchi
2018-10-14  9:59     ` Jan Vrany
2018-10-16 22:18       ` Simon Marchi
2018-10-17 13:55         ` Tom Tromey
2018-10-17 14:56           ` [PATCH v2] " Jan Vrany
2018-10-17 15:12             ` [PATCH v3] " Jan Vrany
2018-10-17 15:44               ` Simon Marchi
2018-10-17 15:53                 ` Simon Marchi
2018-10-17 19:33                   ` Jan Vrany
2018-12-13 15:21                   ` [PATCH] " Jan Vrany
2018-12-13 17:13                     ` Simon Marchi [this message]
2018-12-21 20:56                       ` Simon Marchi
2018-10-17 15:47         ` Pedro Alves
2018-10-17 15:51           ` Simon Marchi

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=98c5b4d58f5413502ce9ee519923b5a8@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.vrany@fit.cvut.cz \
    --cc=palves@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).