public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: lists@coryfields.com, "H.J. Lu" <hjl.tools@gmail.com>
Cc: nd@arm.com, GCC Development <gcc@gcc.gnu.org>,
	Rich Felker <dalias@libc.org>
Subject: Re: -static-pie and -static -pie
Date: Fri, 02 Feb 2018 11:33:00 -0000	[thread overview]
Message-ID: <5f151333-0c7c-e987-e674-68816d413fd2@arm.com> (raw)
In-Reply-To: <CAApLimjbutLH30Pp17DT1UkBxsJebx0zRnFRTnyJ6Bbuf=XPXw@mail.gmail.com>

On 31/01/18 15:44, Cory Fields wrote:
> After looking at this for quite a while, I'm afraid I'm unsure how to proceed.
> 
> As of now, static and static-pie are mutually exclusive. So given the
> GNU_USER_TARGET_STARTFILE_SPEC you pasted
> earlier, "static" matches before "static-pie", causing the wrong start files.
> 
> It seems to me that the static-pie target complicates things more than
> matching against static+pie individually.
> 
> If I convert -static + -pie to -static-pie, then "static" won't be
> matched in specs, where maybe it otherwise should. Same for -pie.
> 

you can change PIE_SPEC to pie|static-pie
and occurrences of static to static|static-pie
(and !static: to !static:%{!static-pie: etc.),
except where it is used to mean "no-pie static",
those should be changed to PIE_SPEC:;static:
(and i think --no-dynamic-linker should always
be passed to ld in LD_PIE_SPEC for static pie,
not just on linux systems and selected targets.)

then there should be no difference between -static -pie
and -static-pie. (and the new -static-pie flag would
be redundant.)

this would e.g. break static linking with default pie
toolchain on systems where the static libc is not pie
or missing the rcrt startup file after upgrading to gcc-8.
i'm not sure if this is a good enough reason to introduce
the -static-pie mess, however if we don't want to break
any previously working configuration then -static-pie has
to be different from -static -pie.

> Would you prefer to swallow -static and -pie and pass along only
> -static-pie? Or forward them all along, and fix the specs which look
> for static before static-pie ?
> 
> Regards,
> Cory
> 
> On Tue, Jan 30, 2018 at 2:36 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Jan 30, 2018 at 11:18 AM, Cory Fields <lists@coryfields.com> wrote:
>>> On Tue, Jan 30, 2018 at 2:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields <lists@coryfields.com> wrote:
>>>>> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Tue, Jan 30, 2018 at 10:26 AM, Cory Fields <lists@coryfields.com> wrote:
>>>>>>> Hi list
>>>>>>>
>>>>>>> I'm playing with -static-pie and musl, which seems to be in good shape
>>>>>>> for 8.0.0. Nice work :)
>>>>>>>
>>>>>>> However, the fact that "gcc -static -pie" and "gcc -static-pie"
>>>>>>> produce different results is very unexpected. I understand the case
>>>>>>> for the new link-type, but merging the options when possible would be
>>>>>>> a huge benefit to existing buildsystems that already cope with both
>>>>>>> individually.
>>>>>>>
>>>>>>> My use-case:
>>>>>>> I'd like to build with --enable-default-pie, and by adding "-static"
>>>>>>
>>>>>> Why not adding "-static-pie" instead of "-static"?
>>>>>>
>>>>>>> to my builds, produce static-pie binaries. But at the moment, that
>>>>>>> attempts to add an interp section.
>>>>>>>
>>>>>>> So my question is, if no conflicting options are found, why not hoist
>>>>>>> "-static -pie" to "-static-pie" ?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Cory
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> H.J.
>>>>>
>>>>> My build system, and plenty of others I'm sure, already handle -static
>>>>> and -pie. Having that understood to mean "static-pie" would mean that
>>>>> the combination would now just work.
>>>>>
>>>>> Asking a different way, if I request -static and -pie, without -nopie,
>>>>> quietly creating non-pie binary seems like a bug. Is there a reason
>>>>> _not_ to interpret it as -static-pie in that case?
>>>>
>>>> GNU_USER_TARGET_STARTFILE_SPEC is defined as
>>>>
>>>> #define GNU_USER_TARGET_STARTFILE_SPEC \
>>>>    "%{shared:; \
>>>>       pg|p|profile:%{static-pie:grcrt1.o%s;:gcrt1.o%s}; \
>>>>       static:crt1.o%s; \
>>>>       static-pie:rcrt1.o%s; \
>>>>       " PIE_SPEC ":Scrt1.o%s; \
>>>>       :crt1.o%s} \
>>>>     crti.o%s \
>>>>     %{static:crtbeginT.o%s; \
>>>>       shared|static-pie|" PIE_SPEC ":crtbeginS.o%s; \
>>>>       :crtbegin.o%s} \
>>>>     %{fvtable-verify=none:%s; \
>>>>       fvtable-verify=preinit:vtv_start_preinit.o%s; \
>>>>       fvtable-verify=std:vtv_start.o%s} \
>>>>     " CRTOFFLOADBEGIN
>>>>
>>>> to pick a suitable crt1.o for static PIE when -static-pie is used.
>>>>
>>>> If gcc.c can convert ... -static ... -pie and ... -pie ... -static ... to
>>>> -static-pic for GNU_USER_TARGET_STARTFILE_SPEC, it
>>>> should work.
>>>>
>>>> --
>>>> H.J.
>>>
>>> Great, that's how I've fixed it locally. Would you consider accepting
>>> a patch for this?
>>
>> I'd like to see it in GCC 8.  Please open a GCC bug and submit your
>> patch against it.
>>
>> Thanks.
>>
>> --
>> H.J.

  parent reply	other threads:[~2018-02-02 11:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30 18:26 Cory Fields
2018-01-30 18:35 ` H.J. Lu
2018-01-30 19:07   ` Cory Fields
2018-01-30 19:15     ` H.J. Lu
2018-01-30 19:18       ` Cory Fields
2018-01-30 19:36         ` H.J. Lu
2018-01-31 15:44           ` Cory Fields
2018-01-31 15:56             ` H.J. Lu
2018-01-31 15:58               ` H.J. Lu
2018-02-02 18:21                 ` Rich Felker
2018-02-02 11:33             ` Szabolcs Nagy [this message]
2018-02-02 18:32               ` Rich Felker
2018-02-02 19:08 graham stott

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=5f151333-0c7c-e987-e674-68816d413fd2@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=dalias@libc.org \
    --cc=gcc@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=lists@coryfields.com \
    --cc=nd@arm.com \
    /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).