[Mesa-dev] [Bug 35268] initial-exec TLS model breaks dlopen'ed libGL

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=35268

--- Comment #15 from Rich Felker <bugdal at aerifal.cx> ---
Hi. I'm the maintainer of musl and I'd like to confirm that we don't have plans
to work around this on our side. musl aims to support extremely minimal thread
stacks if desired by the application, and reserving a large amount of
additional space like glibc does for late-loaded initial-exec TLS is contrary
to that goal. I believe it's already possible for users to "work around" this
issue by LD_PRELOAD'ing the library so that it gets assigned initial-exec TLS
space at startup, but this has symbol visibility issues if the application only
intended to use RTLD_LOCAL at dlopen time; we may consider adding another
environment variable like LD_PRELOAD but which preloads the library with
RTLD_LOCAL-like semantics, but this would still be an ugly hack and not a
proper solution. Note that, at least as I understand it, the current approach
that "works" with glibc is already fragile; if another library with large TLS
needs gets loaded via dlopen before libGL.so, this may cause libGL.so to fail
to load/work.

What I'd like to propose as the solution is eliminating the use of
__attribute__((tls_model("initial-exec"))) and instead using -mtls-dialect=gnu2
on targets where it's supported. The "gnu2" TLS dialect, documented at
http://www.fsfla.org/~lxoliva/writeups/TLS/paper-gcc2006.pdf, 
http://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt, etc., allows
libraries loaded at startup to achieve TLS access performance roughly
equivalent to initial-exec despite using general-dynamic model. This level of
performance is also possible via dlopen if the implementation is able to put
the library's TLS in extra space reserved at startup (like glibc does in most
cases). In all other cases, a variant of traditional general-dynamic model is
used, so performance is sub-optimal, but it's still moderately better (IIRC,
15-30% less time for access) than the original general-dynamic model.

So in summary, using gnu2 and leaving off the tls_model attribute instead of
using initial-exec gives:

- Essentially same performance when the library is pulled in at load time.
- Essentially same performance when the library is dlopen'd and there's extra
initial TLS space that can be assigned to it.
- Working but with reduced performance, instead of complete failure, when the
library is dlopen'd and there's no room in the initial TLS space to put its TLS
there.

Note that musl does not yet support the gnu2 TLS dialect, so for the time
being, a way to turn off both the initial-exec hack AND the gnu2 dialect would
be needed to solve the problem. But it's on our agenda, and having this issue
with GL fixed via gnu2 dialect would draw more attention to getting it added.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140129/2cfc36d7/attachment.html>