Re: -static-pie and -static -pie

Re: -static-pie and -static -pie

[graham stott]

    


-------- Original message --------
From: Rich Felker <dalias@libc.org> 
Date: 02/02/2018  18:32  (GMT+00:00) 
To: Szabolcs Nagy <szabolcs.nagy@arm.com> 
Cc: lists@coryfields.com, "H.J. Lu" <hjl.tools@gmail.com>, nd@arm.com, GCC Development <gcc@gcc.gnu.org> 
Subject: Re: -static-pie and -static -pie 

On Fri, Feb 02, 2018 at 11:33:22AM +0000, Szabolcs Nagy wrote:
> 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.

Ideally, ld would have an "opportunistic pie" option to link as pie
whenever the input files are all pic, and fallback to non-pie if any
pic-incompatible (would-be-textrels) objects are present. However this
is architecturally complex to support because ld would have to know
about switching between versions of crt1.

In practice, I think users on musl-based systems like Alpine with
default-pie will want -static to continue to produce static pie by
default; this is what Alpine is doing now with their gcc package. I
think the idea is that, since the toolchain produces pie by default,
all static libraries will end up being pie anyway.

If you have an ecosystem of old and new static libraries from
different toolchains, though, that might not be a safe assumption.

Also note that libtool and various other software may interpret
-static and may not expect to be static linking when only -static-pie
but not -static appears in LDFLAGS.

I think reasonable course of action is:

1. -static-pie can always request linking as static pie. It should be
   compatible with having -static on the command line too so as not to
   break build systems that are aware of and look for -static (in
   which case the user building might need to add both options).

2. Behavior of -static with -pie (including default pie) should be
   configurable via something like --enable-default-static-pie. This
   way distros that have been using -static -pie to get static pie can
   keep doing so without patching their GCCs, and distros that need a
   more conservative behavior can have that.

Thoughts? Even if you don't want to do #2 as-is, I think an effort
should be made not to break things so that it's hard for distros to
preserve the ability of -static to work (successfully build static
pie) on default-pie toolchains.

Rich

Re: -static-pie and -static -pie

[Rich Felker]

On Fri, Feb 02, 2018 at 11:33:22AM +0000, Szabolcs Nagy wrote:
> 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.

Ideally, ld would have an "opportunistic pie" option to link as pie
whenever the input files are all pic, and fallback to non-pie if any
pic-incompatible (would-be-textrels) objects are present. However this
is architecturally complex to support because ld would have to know
about switching between versions of crt1.

In practice, I think users on musl-based systems like Alpine with
default-pie will want -static to continue to produce static pie by
default; this is what Alpine is doing now with their gcc package. I
think the idea is that, since the toolchain produces pie by default,
all static libraries will end up being pie anyway.

If you have an ecosystem of old and new static libraries from
different toolchains, though, that might not be a safe assumption.

Also note that libtool and various other software may interpret
-static and may not expect to be static linking when only -static-pie
but not -static appears in LDFLAGS.

I think reasonable course of action is:

1. -static-pie can always request linking as static pie. It should be
   compatible with having -static on the command line too so as not to
   break build systems that are aware of and look for -static (in
   which case the user building might need to add both options).

2. Behavior of -static with -pie (including default pie) should be
   configurable via something like --enable-default-static-pie. This
   way distros that have been using -static -pie to get static pie can
   keep doing so without patching their GCCs, and distros that need a
   more conservative behavior can have that.

Thoughts? Even if you don't want to do #2 as-is, I think an effort
should be made not to break things so that it's hard for distros to
preserve the ability of -static to work (successfully build static
pie) on default-pie toolchains.

Rich

Re: -static-pie and -static -pie

[Rich Felker]

On Wed, Jan 31, 2018 at 07:58:31AM -0800, H.J. Lu wrote:
> On Wed, Jan 31, 2018 at 7:56 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields <lists@coryfields.com> 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.
> >>
> >> 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
> >
> > Yes.  When you see both -static and -pie. regardless of their relative
> > order on command-line, you
> >
> > 1. Remove -static and -pie.
> > 2. Add -static-pie.
> 
> This assumes that -static -pie and -pie -static do not produce the working
> executable.  If they do, you can't change them.

That assumption is correct. Historically, GCC's specs have suppressed
--dynamic-linker when -static is present. This means when ld sees
-pie, it picks a builtin, wrong default dynamic linker name like
"/lib64/ld.so.1" and stores it in the output PT_INTERP. Perhaps there
were/are some obscure platforms on which the default worked, but in
general it doesn't.

Presumably on glibc-based systems you could have made it work as
"dynamic linked pie but with no .so's" by adding your own
-Wl,-dynamic-linker option, but I don't think that was supported
usage.

Rich

Re: -static-pie and -static -pie

[Szabolcs Nagy]

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.

Re: -static-pie and -static -pie

[H.J. Lu]

On Wed, Jan 31, 2018 at 7:56 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields <lists@coryfields.com> 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.
>>
>> 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
>
> Yes.  When you see both -static and -pie. regardless of their relative
> order on command-line, you
>
> 1. Remove -static and -pie.
> 2. Add -static-pie.
>

This assumes that -static -pie and -pie -static do not produce the working
executable.  If they do, you can't change them.



-- 
H.J.

Re: -static-pie and -static -pie

[H.J. Lu]

On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields <lists@coryfields.com> 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.
>
> 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

Yes.  When you see both -static and -pie. regardless of their relative
order on command-line, you

1. Remove -static and -pie.
2. Add -static-pie.

> for static before static-pie ?
>



-- 
H.J.

Re: -static-pie and -static -pie

[Cory Fields]

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.

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.

Re: -static-pie and -static -pie

[H.J. Lu]

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.

Re: -static-pie and -static -pie

[Cory Fields]

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?

Re: -static-pie and -static -pie

[H.J. Lu]

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.

Re: -static-pie and -static -pie

[Cory Fields]

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?

Re: -static-pie and -static -pie

[H.J. Lu]

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.

-static-pie and -static -pie

[Cory Fields]

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"
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