Bug 253508

Summary: [rtld] RTLD_STATIC_TLS_EXTRA should be incresed
Product: Base System Reporter: Markus Kohlmeyer <rootservice>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Many People CC: rootservice, viktor.stujber+freebsd-bugs_v4CCPfay
Priority: --- Keywords: toolchain
Version: 12.2-RELEASE   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250652

Description Markus Kohlmeyer 2021-02-14 14:25:00 UTC
As you can see in the referenced Bug, the value of RTLD_STATIC_TLS_EXTRA in /usr/src/libexec/rtld-elf/rtld.h should be increased.
I'm unsure how large it realy needs be to avoid such bugs, but according to http://lists.dragonflybsd.org/pipermail/bugs/2013-June/311813.html i tried it with 1280 and the failures in PHP went away.

Hopefully this is the correct way of fixings this issue.
Thanks for your great work!
Comment 1 Viktor Ć tujber 2021-03-02 15:57:53 UTC
Any developer can drive up the static tls area size requirement arbitrarily high by flagging their thread variables with __attribute__((tls_model("initial-exec"))), especially if it's done carelessly on a large struct or array. Increasing the value might be worthwhile if developers find the current value too limiting for modern applications. Otherwise I would first turn to the developer to review and revise their possibly flawed approach.

So far I have submitted the issue as https://bugs.php.net/bug.php?id=80814

I have not had the time to review code history for freebsd's rtld and php's TSRM to maybe figure out when this all started, why it was done, and if freebsd's RTLD_STATIC_TLS_EXTRA is meant for general-purpose use.

An interesting old discussion regarding abuse of initial-exec at https://bugs.freedesktop.org/show_bug.cgi?id=35268#c15 brings up -mtls-dialect=gnu2 enabling the use of TLS descriptors to achieve improved tls performance.

IRC #clang thinks that dynamically loading modules flagged as DF_STATIC_TLS is sketchy and that those should really only be loaded along with the main executable.

There's also a handy blog post from 2 weeks ago by a LLVM developer at https://maskray.me/blog/2021-02-14-all-about-thread-local-storage that I used as a source of info. It considers this usage 'obscure', but then brings up an 'async signal safety' issue for the dynamic modes.