[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] tls_model("initial-exec") attribute prevents dynam
From: |
Milian Wolff |
Subject: |
Re: [Libunwind-devel] tls_model("initial-exec") attribute prevents dynamic loading of libunwind via dlopen() |
Date: |
Mon, 07 May 2018 22:24:59 +0200 |
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.
Re: [Libunwind-devel] tls_model("initial-exec") attribute prevents dynamic loading of libunwind via dlopen(), Dave Watson, 2018/05/02