This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC 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: Segfault calling dlopen()'ed executable built with -pie and using TLS


On 2016-04-18 at 11:43 -0700, Cary Coutant wrote:
> > 
> > When I build a binary with -pie, the linker produces an ELF file
> > with
> > ET_DYN in header. So it is pretty much explicitly "a shared
> > library",
> > I guess...
> 
> Not really. There has been discussion about whether PIE executables
> should be ET_EXEC or ET_DYN, and it seems to have come down to ET_DYN
> for the reason that a PIE executable requires the dynamic loader.
> What
> distinguishes an executable from a shared library is the presence of
> an entry point.

Then, for my purposes, it is a shared library...

> 
> > Either way, is there any way to tell the linker not to do these
> > things
> > and instead produce just a shared library with an entry point?
> 
> In theory, I think you could build a shared object that has an entry
> point so it could act as an executable, but you'd need to build some
> startup files that don't currently exist. For a binary to act as an
> executable, it needs an entry point, but the entry point is not
> "main"
> -- it's "_start", defined in crt1.o, which performs a bunch of
> runtime
> initialization before actually calling "main". The crt1.o that comes
> with your compiler probably has non-PIC code in it, so you can't link
> it into a shared library.

Yes, indeed, but I'm not calling _start() from the loader, I'm calling
main()... so I guess non-PIC-ness of the startup code does not matter,
does it?

What else differs between -shared and -pie so that dlopen()'ing -shared
executable works well with TLS, but dlopen()'ing -pie executable does
not work?

(again, I'm not calling _start.)

--
Ivan Shapovalov / intelfx /

> 
> If you wanted to do this strongly enough, you could rewrite the C
> runtime startup code in crt1.o (and probably also crt0.o, crtbegin.o,
> and others) to be PIC, then link your payload with those startup
> files
> instead of the standard ones, and the -shared option. Since I haven't
> tried this, I'm not quite sure whether the dynamic loader would be
> happy with the result, but it also could probably be modified if
> necessary.
> 
> Bottom line, what you're asking for is theoretically possible, but
> not
> currently supported.
> 
> -cary

Attachment: signature.asc
Description: This is a digitally signed message part


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