libunwind-devel
[Top][All Lists]
Advanced

[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: Tue, 08 May 2018 20:18:13 +0200

On Dienstag, 8. Mai 2018 08:44:29 CEST Bert Wesarg wrote:
> 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?

I use RTLD_NOW, but don't specify RTLD_GLOBAL. If I understand the docs 
correctly, the former shouldn't affect the latter, and thus I should use 
RTLD_LOCAL (or so I hope). At least, changing your RTLD_LAZY to RTLD_NOW 
doesn't change the results below.

Regarding your code, some of it doesn't compile:

```
$ make -j1
makeobj[0]: Entering directory `/tmp/tls-dlopen'
gcc -shared -fPIC -DTHEMODEL=local-exec -o libadapter-extern-local-exec.so 
adapter.c -Wl,-rpath,$PWD -L. -lmy_tls-local-exec
/usr/bin/ld: /tmp/ccMCneah.o: relocation R_X86_64_TPOFF32 against symbol 
`my_tls' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: [Makefile:25: libadapter-extern-local-exec.so] Error 1 (ignored)
gcc -shared -fPIC -DTHEMODEL=local-exec -DTHESTATIC -o libadapter-static-
local-exec.so adapter.c
/usr/bin/ld: /tmp/ccuIgB2n.o: relocation R_X86_64_TPOFF32 against `my_tls' can 
not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: [Makefile:25: libadapter-static-local-exec.so] Error 1 (ignored)
makeobj[0]: Leaving directory `/tmp/tls-dlopen'
```

Output from running it locally:

```
$ make run
makeobj[0]: Entering directory `/tmp/tls-dlopen'
gcc -shared -fPIC -DTHEMODEL=local-exec -o libadapter-extern-local-exec.so 
adapter.c -Wl,-rpath,$PWD -L. -lmy_tls-local-exec
gcc -shared -fPIC -DTHEMODEL=local-exec -DTHESTATIC -o libadapter-static-
local-exec.so adapter.c
/usr/bin/ld: /tmp/ccs45TyO.o: relocation R_X86_64_TPOFF32 against `my_tls' can 
not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: [Makefile:25: libadapter-static-local-exec.so] Error 1 (ignored)
/usr/bin/ld: /tmp/cc8X0n8N.o: relocation R_X86_64_TPOFF32 against symbol 
`my_tls' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: [Makefile:25: libadapter-extern-local-exec.so] Error 1 (ignored)
./main
1
1
2
2
extern global-dynamic:
enter
enter
1
1
exit
enter
2
exit
enter
2
exit
exit
static global-dynamic:
enter
1
enter
1
exit
enter
2
exit
enter
2
exit
exit
extern local-dynamic:
enter
enter
1
1
exit
enter
2
exit
enter
2
exit
exit
static local-dynamic:
enter
1
enter
1
exit
enter
2
exit
enter
2
exit
exit
extern initial-exec:
enter
1
enter
1
exit
enter
2
exit
enter
2
exit
exit
static initial-exec:
enter
1
enter
1
exit
enter
2
exit
enter
2
exit
exit
extern local-exec:
Could not load THEMONITOR
: Success
Could not load theenter symbol
: Success
Could not load theexit symbol
: Success
1
1
2
2
static local-exec:
Could not load THEMONITOR
: Success
Could not load theenter symbol
: Success
Could not load theexit symbol
: Success
1
1
2
2
makeobj[0]: Leaving directory `/tmp/tls-dlopen'
```
So indeed, it looks like initial-exec should be fine... Maybe it's because I 
don't load libunwind directly, but rather load a secondary library which in 
turn depends on libunwind. Once I have more time, I'll try to expand your test 
accordingly to see if that is what breaks it.

Cheers

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]