From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125444 invoked by alias); 6 Aug 2019 14:24:37 -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 125302 invoked by uid 89); 6 Aug 2019 14:24:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Aug 2019 14:24:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5C547344; Tue, 6 Aug 2019 07:24:22 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6A8F73F706; Tue, 6 Aug 2019 07:24:21 -0700 (PDT) From: Richard Sandiford To: Christophe Lyon Mail-Followup-To: Christophe Lyon ,Christophe Lyon , Szabolcs Nagy , Rich Felker , nd , "gcc-patches\@gcc.gnu.org" , richard.sandiford@arm.com Cc: Christophe Lyon , Szabolcs Nagy , Rich Felker , nd , "gcc-patches\@gcc.gnu.org" Subject: Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided 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> <929589a5-dc82-087c-f9d8-dacbb55a82c3@arm.com> <611566ee-a939-aef6-4354-16fbf8ad822a@st.com> Date: Tue, 06 Aug 2019 14:28:00 -0000 In-Reply-To: (Christophe Lyon's message of "Thu, 1 Aug 2019 12:13:28 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00362.txt.bz2 Christophe Lyon writes: > On Tue, 16 Jul 2019 at 12:34, Richard Sandiford > wrote: >> >> Christophe Lyon writes: >> > On 22/05/2019 10:45, Christophe Lyon wrote: >> >> On Wed, 22 May 2019 at 10:39, Szabolcs Nagy wrote: >> >>> >> >>> On 21/05/2019 16:28, Christophe Lyon wrote: >> >>>> --- 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" >> >>> >> >>> the line break seems wrong (either needs \ or no newline) >> >>> >> >> Sorry, that's a mailer artifact. >> >> >> >>>> --- a/libsanitizer/configure.tgt >> >>>> +++ b/libsanitizer/configure.tgt >> >>>> @@ -45,7 +45,7 @@ case "${target}" in >> >>>> ;; >> >>>> sparc*-*-solaris2.11*) >> >>>> ;; >> >>>> - arm*-*-uclinuxfdpiceabi) >> >>>> + arm*-*-fdpiceabi) >> >>> >> >>> should be *fdpiceabi instead of *-fdpiceabi i think. >> >> >> >> Indeed, thanks >> >> . >> >> >> > FWIW, here is the updated patch: >> > - handles musl -fdpic suffix >> > - disables sanitizers for arm*-*-fdpiceabi >> > - does not handle -static in a special way, so using -static produces binaries that request the non-existing /usr/lib/ld.so.1, thus effectively making -static broken/unsupported (this does lead to a few more FAIL in the testsuite) >> > >> > The plan is to work -static-pie later, as discussed. >> >> Could you make -static without -mno-fdpic an error via a %e spec, >> so that the failure mode is a bit more user-friendly? >> > > Sure. > Do you know if there is a way to catch linker options in the specs? > Would it be possible to still accept -static -Wl,-dynamic-linker XXX ? Ah, no, don't know a way of doing that. Maybe the error isn't feasible after all then (at least not without significant work). Richard