https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
So we have three optimisations that don't play together well.
1) libgomp use of -ftls-model=initial-exec
2) glibc's reserved static tls area being used by shared libraries that don't
need it but may go faster if they do use it.
3) applications that dlopen most of their shared libraries in order to get
better startup time and/or follow some sort of modular programming scheme.
It seems to me that fixing (3) is the correct approach. Link libgomp into the
app, or preload it. Easy. Or possibly tackle (2) by implementing a new flag
to dlopen that says to not opportunistically use reserved static TLS, then
modify those apps that dlopen lots of shared libraries to use the flag.
Why slow down everything just for some small number of applications? Just
because libgomp.so is the victim that hits "cannot allocate memory in static
TLS block" doesn't mean the fault lies there.
