Re: Is it a GNU Tools failure that PIE use ET_DYN and can't be distinguished from libraries?

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

On Thu, Mar 19, 2015 at 12:15 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 19 Mar 2015 00:27, Rich Felker wrote:
>> On Wed, Mar 18, 2015 at 09:37:46PM -0400, Carlos O'Donell wrote:
>> > On 03/18/2015 04:51 PM, Roland McGrath wrote:
>> > >> Is it a failing of the tooling that we didn't provide a way for
>> > >> tools to determine PIE vs. DSO?
>> > >
>> > > It might be if we hadn't.  But we defined a PIE as an ET_DYN with a
>> > > DT_DEBUG.  (We didn't account for a case that would be useful and the
>> > > linker doesn't currently fully support: a static PIE, which is an ET_DYN
>> > > that has no PT_INTERP and might not have a PT_DYNAMIC either.)
>> >
>> > Interesting, ET_DYN + DT_DEBUG, I did not see that coming.
>> >
>> > At best I'd have defined it as ET_DYN + PT_INTERP, and I would have
>> > been happy to call libc.so.6 the first PIE.
>>
>> That excludes static pie, something I've successfully experimented
>> with using musl and which the OpenBSD folks seem to be doing
>> independently. AFAIK there's no upstream toolchain support for it, but
>> gcc can be tricked into doing something that works with -shared
>> (instead of -pie), -Wl,-Bstatic, and explicitly including a version of
>> crt1.o (OpenBSD calls this rcrt0.o, I think; my experimental version
>> was called Zcrt1.o) that processes RELATIVE relocs.
>
> from what i can tell, missing static PIE support is a matter of no one putting
> in the work in all the various places to make it a reality vs any one actively
> lobbying against it.  i'd like to see it happen ... mostly because when you have
> a system that is fully PIE down to the compiler (like Gentoo/Hardened), not

Does PIE GCC work with PCH?  It didn't work for me last time when
I tried.

-- 
H.J.