Re: Segfault calling dlopen()'ed executable built with -pie and using TLS

[Ivan Shapovalov <intelfx at intelfx dot name>]

On 2016-04-19 at 14:15 -0700, Cary Coutant wrote:
> > 
> > > 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?
> 
> Maybe I misunderstood your original question. Yes, you're calling the
> payload's main() from your loader, and that's OK because your loader
> has already started up through the crt startup code. But I thought
> you
> were trying to link the payload binary so that it could also serve as
> an executable that could be launched by itself rather than via the
> loader. To do that, you need the startup code in the crt*.o files,
> and
> that code will call your payload's main().

Yes, I understand.
But what does *not* work is exactly "calling the payload's main() from
the loader". On the other hand, starting the payload directly *does*
work.

Speaking more generally, how can presence/absence of non-PIC startup
code (in the payload) influence the code path where that startup code
is *not* used?

--
Ivan Shapovalov / intelfx /

> 
> > 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?
> 
> Off the top of my head, I can't think of anything, but I suspect
> there's at least a 50% chance that there are other obstacles.
> 
> -cary

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