[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
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