public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] configure: Allow a host makefile fragment to override PIE flag settings.
Date: Fri, 20 Aug 2021 11:29:21 +0100	[thread overview]
Message-ID: <mpttujko1dq.fsf@arm.com> (raw)
In-Reply-To: <7E483B90-25B7-494C-9BC5-2BC51D2BEB78@sandoe.co.uk> (Iain Sandoe's message of "Fri, 20 Aug 2021 11:13:09 +0100")

Iain Sandoe <iain@sandoe.co.uk> writes:
> Hi Richard,
>> Maybe it would be easier to have the makefile fragments determine
>> something like CODE_MODEL_CFLAGS, which can be "-fPIC", "-mdynamic-no-pic",
>> etc., and use:
>> 
>> COMPILER += $(NO_PIE_CFLAGS) $(CODE_MODEL_CFLAGS)
>
> OK. I have misgivings about this - the problem is that:
>
> -fPIC -fno-PIE != -fno-PIE -fPIC,  which is not obvious to many folks - who expect that
> the “last edition of a flag will be the one in force”.
>
> So the PIE-ness and the PIC-ness are decoupled in the configury but they need to be
> ordered specifically for targets that want PIC code by default (FWIW, I don’t think Darwin
> is the only default-PIC case here, from discussions on irc).

Yeah, that's what the above was supposed to achieve.  In other words,
if you force non-PIE, you also need to follow that by $(CODE_MODEL_CFLAGS),
which restates whatever the base code model is.

If it's the decoupling you're worried about, then an alternative would
be to have:

  NO_PIE_CFLAGS="-fno-PIE \$(CODE_MODEL_CFLAGS)"

I was going to suggest that originally, but thought the above might
be simpler to follow later.

Thanks,
Richard

  reply	other threads:[~2021-08-20 10:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19 18:48 Iain Sandoe
2021-08-20  8:39 ` Richard Sandiford
2021-08-20 10:13   ` Iain Sandoe
2021-08-20 10:29     ` Richard Sandiford [this message]
2021-08-25 17:42       ` Iain Sandoe
2021-08-25 17:51         ` H.J. Lu
2021-08-25 17:56           ` H.J. Lu
2021-08-25 18:10             ` Iain Sandoe
2021-08-25 18:22               ` H.J. Lu
2021-08-25 18:29                 ` Iain Sandoe
2021-08-26  6:40                   ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mpttujko1dq.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).