From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84336 invoked by alias); 21 May 2019 15:29:06 -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 84327 invoked by uid 89); 21 May 2019 15:29:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=Rich, HX-Languages-Length:3953, constantly, musl X-HELO: mail-vk1-f193.google.com Received: from mail-vk1-f193.google.com (HELO mail-vk1-f193.google.com) (209.85.221.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 May 2019 15:29:04 +0000 Received: by mail-vk1-f193.google.com with SMTP id v69so4867178vke.0 for ; Tue, 21 May 2019 08:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BmLaPI+wub+4CU19d2ZaTy5D4ARtMlIrwHt1Yl+MNWg=; b=rW0BNXRPJ03lUC1zG1Tc9wAcvVl4/hbvEAtTuvtpTHRELDcb+9ILAo4DJ0sk4GyndG FDWNeAA+evPMPn2VvEx63v6Adpv6v0NdeStuR/kkD7c9xo4u12gPn1hUZk3eu8LKsKH1 rz/aBXah8bMjbpF1BXGdCSL58M402itJrmETxfOL43mgW5xgp7CRsaczxkko2rHqtfz9 tNfgHFAnZptF2xEqFJM6hWKKp3p0HDnuSw/8dD7xFKGqgTpDMvtFk0a0mPwCxBHvehMp iAMQ6uDiFRdCcVK6SMn1znL1I+BVOq6gIHS5ITK+hTRxlA+f9PYBiqZeE+uJZu52hGbw 0TRg== MIME-Version: 1.0 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> In-Reply-To: <20190515160646.GW23599@brightrain.aerifal.cx> From: Christophe Lyon Date: Tue, 21 May 2019 15:29:00 -0000 Message-ID: Subject: Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided To: Rich Felker Cc: Szabolcs Nagy , nd , Christophe Lyon , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01410.txt.bz2 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 :-) 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. Thanks, Christophe