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

Siddhesh Poyarekar siddhesh@gotplt.org
Thu Nov 18 09:24:13 GMT 2021


On 11/17/21 15:34, Siddhesh Poyarekar via Libc-alpha wrote:
> 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.

A third option (as we discussed offlist yesterday) could be to always 
build glibc dynamic programs as PIE as long as the toolchain supports 
it.  Would non-distribution use cases be adversely affected by not 
having an option to produce non-PIE glibc programs, e.g. iconvconfig, 
getconf, etc.?

Siddhesh


More information about the Libc-alpha mailing list