This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 03/16/2015 05:55 PM, Carlos O'Donell wrote:
> While looking at recent ABI comparison failures I noticed that 
> some internal Red Hat tooling was looking at PIEs and treating
> their exported dynamic symbols as fixed ABI/API that must not
> change.

That's a conservative first approximation, but it's independent of
ET_DYN/ETEXEC.

> The truth is that from the tooling perspective you can't tell the
> difference between a PIE and an ET_DYN, except that you might guess
> PIE if you see PT_INTERP (and you'd be wrong for libc.so and
> ld.so)

I don't think this matters.

> Is it a failing of the tooling that we didn't provide a way for
> tools to determine PIE vs. DSO?

No, it's conceivable that we ship code where the executable provides a
public ABI.  From my memory, candidates are PostgreSQL and Apache httpd.
 For other distributions, this could apply to the Perl, Python, Lua
interpreters.

Manual inspection is needed to tell if symbols exported from an
executable form a public ABI or not.  If the tooling ignores exported
symbols just because the object is ET_EXEC, it is broken and risks
missing relevant ABI changes.

-- 
Florian Weimer / Red Hat Product Security


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]