From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107817 invoked by alias); 29 Oct 2018 13:46:34 -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 37286 invoked by uid 89); 29 Oct 2018 13:45:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_05,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=reworking, opposite, H*f:sk:CAKdteO, H*f:HvSQw7Ppc X-HELO: mail-vs1-f67.google.com Received: from mail-vs1-f67.google.com (HELO mail-vs1-f67.google.com) (209.85.217.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Oct 2018 13:45:34 +0000 Received: by mail-vs1-f67.google.com with SMTP id d62so3508685vsd.2 for ; Mon, 29 Oct 2018 06:45:33 -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=CB5R3dnOxhkxVIhammmo4j+bmjlCnsJzBY16Pk/YT9Y=; b=V4ZfAU6mIf6TvyTuz2HLBTQso3/sFSOPsfyjl5Iu2hMGz1f0vtcsC1t7BSE4eFw1TQ MFQ8obwsdORxO4OCWC3bUk/y07oz4M3FKWzyvtY8Tq/6/Wq3bWRXXpihY9555Tvms700 esUfAVowUTbc6M4lT+XtUv/ylOOWn79HbJLh0= MIME-Version: 1.0 References: <20181011133518.17258-1-christophe.lyon@st.com> <20181011133518.17258-4-christophe.lyon@st.com> <26314d4c-d0cf-05c0-9460-e1df2a6147cd@arm.com> <13da7741-e438-25bc-2825-1aebd79a4767@arm.com> <20181023145716.GK5205@gate.crashing.org> In-Reply-To: From: Christophe Lyon Date: Mon, 29 Oct 2018 14:25:00 -0000 Message-ID: Subject: Re: [ARM/FDPIC v3 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided To: Segher Boessenkool Cc: Richard Earnshaw , christophe lyon St , gcc Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg01817.txt.bz2 On Fri, 26 Oct 2018 at 17:07, Christophe Lyon wrote: > > On Tue, 23 Oct 2018 at 17:14, Segher Boessenkool > wrote: > > > > On Tue, Oct 23, 2018 at 02:58:21PM +0100, Richard Earnshaw (lists) wrote: > > > On 15/10/2018 11:10, Christophe Lyon wrote: > > > > Do you mean to also make -mfdpic non-existent/rejected when GCC is not > > > > configured > > > > for arm-uclinuxfdpiceabi? > > > > > > Ideally doesn't exist, so that it doesn't show up in things like --help > > > when it doesn't work. > > > > > > > How to achieve that? > > > > > > Good question, I'm not sure, off hand. It might be possible to make the > > > config machinery add additional opt files, but it's not something I've > > > tried. You might want to try adding an additional opt file to > > > extra_options for fdpic targets. > > > > That should work yes. You could look at how 476.opt is added for powerpc, > > it is a comparable situation. > > > > Thanks, I got it to work. > > Now back to Richard's original question: > > I think this needs to be resolved. Either -mfdpic works everywhere, or > > the option should only be available when configured for -mfdpic. > It's not that -mfdpic does not work everywhere, rather it is not sufficient > to use it alone: it should be used along with fpic/fPIC/fpie/fPIE depending > on the use case. > > In practice I don't know if we want to be able to use -mfdpic with a > arm-linux-gnueabi > toolchain, or if we are ok to have to use two different toolchains > when we want to make > tests/compare code generation in both cases. > > The 1st option means I should improve the documentation patch. For the 2nd one, > I have patches in progress (which also imply reworking the doc since the option > would not also be available) > Here is an updated doc proposal (that would go in patch #1, without changing this one): @item -mfdpic @opindex mfdpic Select the FDPIC ABI, which uses function descriptors to represent pointers to functions. When the compiler is configured for @code{arm-*-uclinuxfdpiceabi} targets, this option is on by default and implies @option{-fPIE} if none of the PIC/PIE-related options is provided. On other targets, it only enables the FDPIC-specific code generation features, and the user should explicitly provide the PIC/PIE-related options as needed. The opposite @option{-mno-fdpic} option is useful (and required) to build the Linux kernel using the same toolchain as the one used to build the userland programs. Is it clearer? Does it read OK? Thanks > Christophe > > > > > > Segher