Re: [Libunwind-devel] tls_model("initial-exec") attribute prevents dynamic loading of libunwind via dlopen()

[Milian Wolff]

On Montag, 7. Mai 2018 21:27:04 CEST Milian Wolff wrote:
> On Mittwoch, 2. Mai 2018 13:23:03 CEST Bert Wesarg wrote:
> > Dear Milian,
> > 
> > I tried to remember why we choose the initial-exec model, but could
> > not found any reasons. By reading
> > https://www.akkadia.org/drepper/tls.pdf again, I would say
> > "local-exec" is the right way to go here. Which should be the default
> > for 'static' variables anyway. Can you please confirm, that this works
> > for you. Its just important, that there are no calls to
> > __tls_get_addr() in the asm output.
> 
> No, with the default I do see __tls_get_addr in the asm output (i.e. matches
> in Gparser.o). So probably, the default isn't OK to be used everywhere.

And local-exec doesn't compile:

/usr/bin/ld: x86_64/.libs/Ltrace.o: relocation R_X86_64_TPOFF32 against 
`tls_cache_destroyed' can not be used when making a shared object; recompile 
with -fPIC

Adding -fPIC isn't enough. I think it's because libunwind's build system uses 
static libraries to generate the shared libraries. But that doesn't seem to be 
possible with local-exec, if I'm understanding it correctly.

Using local-exec does remove the call to __tls_get_addr from the *.o files 
though.

Cheers

-- 
Milian Wolff
address@hidden
http://milianw.de

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