Skip to content

"Excessive TLS usage", but take this title with a grain of salt #996

Closed
@fasterthanlime

Description

@fasterthanlime

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions