From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6473 invoked by alias); 15 May 2019 15:37: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 6398 invoked by uid 89); 15 May 2019 15:37:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=ham version=3.3.1 spammy= X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 May 2019 15:37:26 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1hQvy2-0003ai-00; Wed, 15 May 2019 15:37:18 +0000 Date: Wed, 15 May 2019 15:37:00 -0000 From: Rich Felker To: Christophe Lyon Cc: Szabolcs Nagy , Christophe Lyon , "gcc-patches@gcc.gnu.org" , nd Subject: Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided Message-ID: <20190515153718.GV23599@brightrain.aerifal.cx> References: <20190515124006.25840-1-christophe.lyon@st.com> <20190515124006.25840-4-christophe.lyon@st.com> <67018f7b-f120-b33f-886f-c081a9ee1061@arm.com> <20190515143653.GT23599@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00861.txt.bz2 On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote: > On Wed, 15 May 2019 at 16:37, Rich Felker wrote: > > > > On Wed, May 15, 2019 at 01:55:30PM +0000, Szabolcs Nagy wrote: > > > On 15/05/2019 13:39, Christophe Lyon wrote: > > > > In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie, > > > > -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code > > > > for executables rather than shared libraries by default. > > > > > > > > We also make sure to use the --fdpic assembler option, and select the > > > > appropriate linker emulation. > > > > > > > > At link time, we also default to -pie, unless we are generating a > > > > shared library or a relocatable file (-r). Note that even for static > > > > link, we must specify the dynamic linker because the executable still > > > > has to relocate itself at startup. > > > > > > > > We also force 'now' binding since lazy binding is not supported. > > > > > > > > We should also apply the same behavior for -Wl,-Ur as for -r, but I > > > > couldn't find how to describe that in the specs fragment. > > > ... > > > > +/* Unless we generate a shared library or a relocatable object, we > > > > + force -pie. */ > > > > +/* Even with -static, we have to define the dynamic-linker, as we > > > > + have some relocations to resolve at load time. */ > > > > +#undef SUBTARGET_EXTRA_LINK_SPEC > > > > +#define SUBTARGET_EXTRA_LINK_SPEC \ > > > > + "%{!mno-fdpic: -m " TARGET_FDPIC_LINKER_EMULATION \ > > > > + "%{!shared:%{!r: -pie}} \ > > > > + %{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \ > > > > + "%{mno-fdpic: -m " TARGET_LINKER_EMULATION "}" \ > > > > + "%{!r:%{!mno-fdpic: -z now}}" > > > > > > i think -dynamic-linker can be avoided for -static using > > > -static-pie linking with rcrt0.o > > > > Yes, -dynamic-linker should never be used with -static. > > So, do you mean dropping completely the line: > + %{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \ > and thus make -static unsupported, forcing users to use -static-pie instead? Rather I would have -static behave the same as -static-pie. The intent on musl when we added static pie (before glibc had it) was that -static plus -pie (including default-pie, if built as default-pie) would yield static pie output, and our patches still do this. When static-pie was upstreamed in gcc, it was done differently for compatibility with legacy versions of glibc. That's not a consideration for fdpic. > > > but more importantly: does the abi spec require the sysv dynamic > > > linker name? that sounds suboptimal (in principle the same os > > > > ABI specs typically do this and we just ignore it. BFD contains > > default dynamic linker strings for all sorts of ABIs, and they're all > > wrong -- things like /lib/ld64.so.1, etc. I don't think it's worth > > bothering with fighting the desire of folks writing ABI specs to do > > this again and again. GCC overrides them all with the actually-correct > > values when !static. > > > > > can support both normal elf and fdpic elf so you can test/use > > > an fdpic toolchain on a system with mmu, but this requires > > > different dynamic linker name ..otherwise one has to run > > > executables in a chroot or separate mount namespace to change > > > the dynamic linker) > > > > Indeed, it's a bad idea to make them clash. > > > > Not sure to understand your point: indeed FDPIC binaries work > on a system with mmu, provided you have the right dynamic > linker in the right place, as well as the needed runtime libs (libc, etc....) > > Do you want me to change anything here? I think the concern is that if the PT_INTERP name is the same for binaries with different ABIs, you wouldn't be able to have both present in the same root fs, and this would make it more of a pain to debug fdpic binaries on a full (with-mmu) host. musl always uses a different PT_INTERP name for each ABI combination, so I guess the question is whether uclibc or whatever other libc you're intending people to use would also want to do this. > > > > +#undef STARTFILE_SPEC > > > > +#define STARTFILE_SPEC "%{!mno-fdpic:%{!shared:crtreloc.o%s}} " \ > > > > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, ANDROID_STARTFILE_SPEC) > > > > diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt > > > > index b241ddb..c38b3f4 100644 > > > > --- a/libsanitizer/configure.tgt > > > > +++ b/libsanitizer/configure.tgt > > > > @@ -45,6 +45,9 @@ case "${target}" in > > > > ;; > > > > sparc*-*-solaris2.11*) > > > > ;; > > > > + arm*-*-uclinuxfdpiceabi) > > > > + UNSUPPORTED=1 > > > > + ;; > > > > > > musl libc has fdpic support on sh (e.g. with sh2eb-linux-muslfdpic > > > target and --enable-fdpic), it can probably support fdpic on arm > > > too with minimal changes, i assume the target name for that would > > > be arm-linux-muslfdpiceabi. > > > > I plan to add ARM FDPIC support as soon as there is (1) published ABI > > for relocation types, entry point contract, etc., and (2) there's > > The ABI is here: > https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt > > > tooling to support it that's either upstream or can be applied as > > clean patches to recent gcc (as opposed to some fork of gcc4 or > > whatever it was this got started as). I think those conditions are > > mostly met now. > This patch series applies on gcc trunk as of ~2 weeks ago Excellent news! > > > so i think it is better to check arm*-*fdpiceabi where the libc > > > does not matter (so we dont have to patch the same files when > > > *-muslfdpiceabi support is added). > > > Looks sane. > > > Yes, that would be appreciated. Maybe we could get musl ldso names > > added at the same time, too? I think they should just be the same as > > the existing musl ldso names but with "-fdpic" appended before > > ".so.1". > Do you mean updating config/arm/linux-eabi.h and adding -fdpic to the > 4 musl dynamic linker names? Yes, conditional on target being fdpic of course. Rich