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

[Bert Wesarg]

On Mon, May 7, 2018 at 10:24 PM, Milian Wolff <address@hidden> wrote:
> 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.

Ok, that was a dead end. Back to square zero. I found my old sandbox
regarding tls and dlopen. And it still passes the initial-exec test.

Can you run 'make run' in the following archive. Note that I open the
lib with RTLD_LOCAL, which you do to, aren't you?

Bert

>
> Cheers
>

tls-dlopen.tar.gz
Description: application/gzip