https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253508

Viktor Štujber <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |viktor.stujber+freebsd-bugs
                   |                            |[email protected]

--- Comment #1 from Viktor Štujber 
<[email protected]> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"

Reply via email to