Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 11/17/21 14:40, Florian Weimer wrote:
>> Yes, it should.  $libc_cv_pie_default is overwritten only in case of
>> --enable-pie-programs=yes, otherwise it is left alone, much like
>> --enable-static-pie.
> 
> But that doesn't make sense, does it?  If the user requests non-PIE
> programs, they should get that.

I suppose you're right.  That is current behaviour with 
--enable-static-pie too; wouldn't a similar argument hold for 
--enable-static-pie=no?  Or is the rationale in that case is that 
*static-pie* is disabled, not pie itself and hence the default PIE 
toolchain could get away with building PIE dynamic programs, just not 
static ones?

I wonder if the clearer option is to have a new
--enable-pie=<no|dynamic|yes/full>, where "no" disables PIE (even on 
default-PIE toolchains), "dynamic" enables PIE for dynamic programs and 
"full" or "yes" enables static-pie on architectures that support it, 
terminating with an error if it's not supported.  --enable-static-pie=no 
could then imply --enable-pie=dynamic and could be deprecated.  I don't 
remember if we have ever deprecated configure flags before.

Even simpler, we could have just a yes/no option and enable static-pie 
transparently on architectures that support it, making an explicit 
--enable-static-pie=no equivalent to disabling all PIE.  It may in 
theory break a use case but I don't know if there's actually a use case 
where one would strictly want only dynamic PIE and not static PIE.

What do you think?

Siddhesh