From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103183 invoked by alias); 13 Dec 2018 17:13:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 103068 invoked by uid 89); 13 Dec 2018 17:13:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=artifact, H*r:112 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Dec 2018 17:13:26 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id wBDHDKal022924 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 13 Dec 2018 12:13:24 -0500 Received: by simark.ca (Postfix, from userid 112) id F24661E7B1; Thu, 13 Dec 2018 12:13:19 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id BF0881E48F; Thu, 13 Dec 2018 12:13:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Dec 2018 17:13:00 -0000 From: Simon Marchi To: Jan Vrany Cc: gdb-patches@sourceware.org, Pedro Alves Subject: Re: [PATCH] Fix various tests to use -no-pie linker flag when needed In-Reply-To: <20181213152049.7702-1-jan.vrany@fit.cvut.cz> References: <2985d86a6b3b9a3bef6e79bc2d130955@polymtl.ca> <20181213152049.7702-1-jan.vrany@fit.cvut.cz> Message-ID: <98c5b4d58f5413502ce9ee519923b5a8@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00146.txt.bz2 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