From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34976 invoked by alias); 18 May 2015 22:24:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 34965 invoked by uid 89); 18 May 2015 22:24:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 18 May 2015 22:24:46 +0000 Received: from laptop1.gw.ume.nu (ip1-67.bon.riksnet.se [77.110.8.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zorry) by smtp.gentoo.org (Postfix) with ESMTPSA id 81946340C39 for ; Mon, 18 May 2015 22:24:43 +0000 (UTC) From: Magnus Granberg To: gcc-patches@gcc.gnu.org Subject: Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option Date: Mon, 18 May 2015 22:53:00 -0000 Message-ID: <3072346.CTCrhcXNep@laptop1.gw.ume.nu> X-KMail-Dictionary: sv User-Agent: KMail/4.14.6 (Linux/3.17.7-hardened-r1; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01632.txt.bz2 fredag 08 maj 2015 10.35.44 skrev H.J. Lu: > On Thu, May 7, 2015 at 2:17 PM, Joseph Myers wrote: > > On Fri, 6 Mar 2015, H.J. Lu wrote: > >> +# We don't want to compile the compiler with -fPIE, it make PCH fail. > >> +COMPILER += @NO_PIE_CFLAGS@ > >> + > >> +# Link with -no-pie since we compile the compiler with -fno-PIE. > >> +LINKER += @NO_PIE_FLAG@ > > > > As I understand it, what we don't want is the compiler to be a PIE. That > > is, it must be linked -no-pie (and given that the compiler is not a PIE, > > compiling -fPIE would be pointless, although it wouldn't actually break > > things to have PIE objects in the compiler as long as it's linked for a > > fixed address). > > > >> +#if defined ENABLE_DEFAULT_PIE > >> +#define GNU_USER_TARGET_STARTFILE_SPEC \ > >> + "%{!shared: %{pg|p|profile:gcrt1.o%s;: \ > >> + %{" PIE_SPEC ":Scrt1.o%s} %{" NO_PIE_SPEC ":crt1.o%s}}} \ > >> + crti.o%s %{static:crtbeginT.o%s;: %{shared:crtbeginS.o%s} \ > >> + %{" PIE_SPEC ":crtbeginS.o%s} \ > >> + %{" NO_PIE_SPEC ":crtbegin.o%s}}" \ > >> + FVTABLE_VERIFY_SPEC > >> +#else > >> +#define GNU_USER_TARGET_STARTFILE_SPEC \ > >> + "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \ > >> + crti.o%s > >> %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}" \ + > >> FVTABLE_VERIFY_SPEC > >> +#endif > > > > With appropriate definitions of PIE_SPEC and NO_PIE_SPEC, shouldn't a > > single definition of GNU_USER_TARGET_STARTFILE_SPEC be able to work for > > both ENABLE_DEFAULT_PIE and !ENABLE_DEFAULT_PIE? > > Yes. > > > noted a > > possible issue with MIPS. Actually, rather more config/*.h and > > config/*/*.h headers contain specs testing for (-fpie, -fPIE, -fno-pie, > > -fno-PIE, -pie) options, which would be affected by these changes. I'd > > say this patch should include an initial attempt at adjusting those config > > headers, which should be an essentially mechanical change not requiring > > understanding anything target-specific. For link-time specs, that may > > mean using PIE_SPEC and NO_PIE_SPEC. For compile-time specs, similar new > > macros would be added. Given such adjustments included in the patch and > > the relevant target maintainers CC:ed, I might then be inclined to approve > > the patch on the basis of allowing a week for target maintainers to test > > the changes for their targets before commit, as I don't see any major > > problems with it beyond the need to update the target-specific specs. > > Here is the updated patch. I will post patches for cris, mips, powerpc > and sparc separately. The target maintainers should be able to adjust > backend ASM_SPEC with FPIE_OR_FPIC_SPEC and > NO_FPIE_AND_FPIC_SPEC. > > OK for trunk? > > Thanks. PIng Any progress on this? /Magnus G.