From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118601 invoked by alias); 21 May 2019 15:48:42 -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 118467 invoked by uid 89); 21 May 2019 15:48:34 -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; Tue, 21 May 2019 15:48:33 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1hT703-000722-00; Tue, 21 May 2019 15:48:23 +0000 Date: Tue, 21 May 2019 15:48:00 -0000 From: Rich Felker To: Christophe Lyon Cc: Szabolcs Nagy , nd , Christophe Lyon , "gcc-patches@gcc.gnu.org" Subject: Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided Message-ID: <20190521154823.GC23599@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> <20190515153718.GV23599@brightrain.aerifal.cx> <2d337959-2238-eb8d-012b-9f46e64728f8@arm.com> <20190515160646.GW23599@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/msg01414.txt.bz2 On Tue, May 21, 2019 at 05:28:51PM +0200, Christophe Lyon wrote: > On Wed, 15 May 2019 at 18:06, Rich Felker wrote: > > > > On Wed, May 15, 2019 at 03:59:39PM +0000, Szabolcs Nagy wrote: > > > On 15/05/2019 16:37, Rich Felker wrote: > > > > 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: > > > >>>> 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. > > > > > > glibc uses different names now for new abis, so i was expecting > > > some *_DYNAMIC_LINKER update, but it seems uclibc always uses > > > the same fixed name > > > > > > /lib/ld-uClibc.so.0 > > > > > > i guess it makes sense for them since iirc uclibc can change > > > its runtime abi based on lot of build time config so having > > > different name for each abi variant may be impractical. > > > > Yes, this "feature" of uclibc was was of the key motivations behind > > the creation of musl... :-) > > > > Hi, > > I discussed a bit further with Szabolcs on irc, and tried to get some > feedback from uclibc-ng community (none so far) > > I propose the following 2 patches on top of this one to address part > of the concerns: > diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h > index 67edb42..d7cc923 100644 > --- a/gcc/config/arm/linux-eabi.h > +++ b/gcc/config/arm/linux-eabi.h > @@ -89,7 +89,7 @@ > #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}" > #endif > #define MUSL_DYNAMIC_LINKER \ > - "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E "%{mfloat-abi=hard:hf}.so.1" > + "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E > "%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1" > > /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to > use the GNU/Linux version, not the generic BPABI version. */ > > diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt > index c38b3f4..92bca69 100644 > --- a/libsanitizer/configure.tgt > +++ b/libsanitizer/configure.tgt > @@ -45,7 +45,7 @@ case "${target}" in > ;; > sparc*-*-solaris2.11*) > ;; > - arm*-*-uclinuxfdpiceabi) > + arm*-*-fdpiceabi) > UNSUPPORTED=1 > ;; > arm*-*-linux*) > > However, regarding -staic/-static-pie, it seems I have several options: > (a) add support for static-pie to uclibc-ng. This means creating a new > rcrt1.o or similar, which would embed parts of the dynamic linker into > static-pie executables. This seems to involve quite a bit of work > > (b) add support for FDPIC on arm to musl, which I'm not familiar with > > (c) declare -static not supported on arm-FDPIC > > (d) gather consensus that -static with pt_interp is ok (my preference, > since that's what the current patches do :-) musl definitely does not support static with pt_interp, and won't. If it works, it's by chance, and not a good idea to try relying on it. If you want to follow this path in upstream for now that's fine but it means musl users will need to apply patches. This is already done anyway, so it's not a *new* burden, but it's still annoying. > At this point, I'd prefer to stick with (d), or (c), to avoid further delaying > inclusion of FDPIC support for arm in GCC, and address improvements > later, so that it's not a constantly moving target. I'd find (c) mildly better as long as it's still easy for us to patch. Providing a -static that's not actually static is not useful and will be harder to fix later. Rich