static TLS exhausted on ppc64le

[Szabolcs Nagy]

On 30/09/2019 15:02, Dan Horák wrote:
> Hi,
> 
> I would like to open a problem we have already met twice in Fedora. the
> symptom is
> 
> "/lib64/libgomp.so.1: cannot allocate memory in static TLS block"
> 
> usually when loading a lot of libraries/modules into a Python
> application. It happened on ppc64le and also on aarch64 systems.
> 
> We have 2 reports in Fedora bugzilla about with more details.
> https://bugzilla.redhat.com/show_bug.cgi?id=1722181
> https://bugzilla.redhat.com/show_bug.cgi?id=1738752
> 
> We have already discussed that briefly with Florian and other members of
> the Red Hat toolchain team, but outcome was in form of a recommendation
> to reduce the usage of "static TLS" objects in the individual libraries.
> But the open question still is - is there a fix for the TLS space
> exhaustion? I believe it can easily become a more serious problem soon.

(a workaround is preloading the problematic libs at startup time)

i think it's a bug in libgomp.so.1, gcc should not build
broken dsos by default (unless it can ensure they are never
loaded dynamically):

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgomp/configure.tgt;h=b88bf72fe3de3735929635c874b8da375c841b1d;hb=HEAD#l13

(libitm has a similar hack)

e.g. this is patched out manually when building a musl libc
based toolchain since musl does not reserve static tls for
broken dsos.

i would support removing such hacks from gcc target libs
(or at least hide it behind some obscure config option),
but i guess that should be discussed with gcc maintainers
and not on libc-alpha.