https://bugs.freedesktop.org/show_bug.cgi?id=35268
--- Comment #15 from Rich Felker <[email protected]> --- 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.
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
