On Mon, May 7, 2018 at 10:24 PM, Milian Wolff <[email protected]> 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
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
