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

["H.J. Lu" <hjl.tools@gmail.com>]

On Thu, Nov 18, 2021 at 1:24 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> 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.?

How about --enable-default-pie?

-- 
H.J.