Hi!
So this is what I'm trying to figure out.
I have a TLS variable defined and exported in libtls_export.so.
libtls_export.so is built with -fPIC and -ftls-model=initial-exec.
This means the TLS variable in question should always be located at a constant relative offset (resolved and patched during program startup) from the thread pointer (stored in the FS register).
Now I have another shared library libtls_import.so.
I want to access the TLS variable exported by libtls_export.so in this DSO.
I do not want to build libtls_import.so with the initial-exec TLS model (I want to allow dlopen()-ing libtls_import.so)
Here's a minimal example:
// tls.h
extern __thread int my_tls;
// tls_export.c
// gcc -shared -fPIC -O2 -ftls-model=initial-exec -o libtls_export.so tls_export.c
#include "tls.h"
__thread int my_tls = 0;
// tls_import.c
// gcc -shared -fPIC -O2 -o libtls_import.so tls_import.c
#include "tls.h"
int get_my_tls() {
return my_tls;
}
While the compiler is building libtls_import.so, it has no knowledge that my_tls will always be located in a static TLS segment.
Therefore, it will emit __tls_get_addr(), which is less than ideal in terms of performance.
So my question is, is there a way to inform gcc that my_tls is always located in a static TLS segment and so it can just emit a @gottpoff placeholder instead of __tls_get_addr() in libtls_import.so?
A hacky workaround I've thought of is to calculate and cache the relative offset of the TLS variable (&my_tls - %FS essentially) and then perform our own lookup in libtls_import.so.
This should? be safe if we make sure libtls_export.so is built with the initial-exec model.
Another interesting observation is "readelf -a libtls_import.so | grep STATIC_TLS" yields no results.
So I wonder if I'm fundamentally misunderstanding how static TLS works.
Thanks,
Len
