From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20954 invoked by alias); 7 May 2015 21:17:30 -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 20944 invoked by uid 89); 7 May 2015 21:17:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 May 2015 21:17:28 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YqTAa-000020-IV from joseph_myers@mentor.com ; Thu, 07 May 2015 14:17:24 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Thu, 7 May 2015 22:17:23 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1YqTAX-0007Fc-P1; Thu, 07 May 2015 21:17:21 +0000 Date: Thu, 07 May 2015 21:17:00 -0000 From: Joseph Myers To: "H.J. Lu" CC: Richard Biener , Magnus Granberg , GCC Patches , danielmicay Subject: Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2015-05/txt/msg00593.txt.bz2 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? 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. -- Joseph S. Myers joseph@codesourcery.com