Description
Terrible report incoming, apologies for everything:
I'm building a dynamic library, which eventually ends up dlopen
'd by a binary.
This fails with "cannot allocate memory in static TLS block".
I've been tracking this down all evening and I think I've narrowed down "excessive thread-local storage usage" to rand.
This is taken from objdump -t ./my-bad-lib.so
:
0000000000000020 l .tbss 0000000000001098 _ZN4rand4rngs6thread14THREAD_RNG_KEY7__getit5__KEY17h65d289a02f603765E.llvm.1869372738252406173
0x1098
(4248 bytes, I don't have a good feeling for hex sizes) is a lot - by GNU ld.so standards. If I was elected dynamic linker president, everyone would get megabytes of thread-local storage. But I'm not ld president, and rebuilding the executable that dlopens my library is.. impractical.
So I was wondering - are y'all aware that THREAD_RNG_KEY uses a lot (comparatively) of TLS space, is that expected?
If you weren't aware of that, would you be willing to look into a "fix"? Or a workaround? I'd gladly take a performance hit by opting into a feature flag if it meant reducing TLS usage significantly.
I'm also curious why -Z tls-model=global-dynamic
didn't "solve that issue" but I guess that's a question for the rustc and/or LLVM teams.
Anyway - lots of questions, very few answers. Any thoughts welcome. Sorry for the poor report, it's late and it's 2020, everyone's tired.