[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Jan 2024 10:28:49 +0800
From: "847567161" <847567161@...com>
To: "musl" <musl@...ts.openwall.com>
Subject: Re: Re: 【Linker】Does MUSL support using TLS for both libc and app dependencies?
> Indeed, there currently is not support for that. It's kinda an
> omission that should be remedied, as someday we may want to support
> softfloat with fenv where TLS might come into play through linking the
> compiler runtime (libgcc.a) that contains thread-local floating point
> state. But for the time being that's not something anyone seems to be
> interested in doing.
We discovered the problem when integrating gwp_asan into musl libc.
gwp_asan is a static library that used tls of init-exec mode, It can't work with tsd for some reason.
So we think it is necessary for libc to support tls.
> That would also be the answer to your question: If the TLS is too large
> for builtin_tls, it gets allocated (which happens in line 2017).
> builtin_tls is merely an optimization to ensure small TLS sections don't
> need an allocation that can fail. This can also be understood as a
> quality improvement measure since this way, most applications cannot
> randomly on startup for TLS allocation reasons when the free memory runs
> low. Whatever good that does in an environment where the kernel gets to
> arbitrarily kill any process it wants to.
Why do we set tp in Stage 2b, is builtin_tls used before here? Can we set it later？
https://github.com/bminor/musl/blob/master/ldso/dynlink.c#L2034
> For static linking, main thread TLS is allocated with mmap in
> static_init_tls(). In that case there is at most 1 TLS module.
>
> >
> > 2、About libc and other so use tls at the same time
> > I didn’t see musl modify tls_offset when ldso uses tls, so when another so uses tls later, their tls offsets will conflict.
> >If we were ever to support TLS in libc/ldso, I think it would always
> > be accessed via the global-dynamic model, so that it doesn't have to
> >move; its DTV slot number would just get changed.
Why can't we support locl-dynamic and init-exec modes in libc?
Do you mean that 'move' refers to the dlopen scene? Could you give more details?
>As to the question: Libc itself cannot use TLS. It could in the static
>linking case (when the TLS just gets rolled into the same section as the
>application TLS), but not in the dynamic one. The dynlinker currently
>does not set up TLS in libc correctly. Not entirely familiar with the
>list of things that would be needed to allow libc to have TLS, but it is
>likely to be nontrivial. I already foresee an order-of-operations
>problem. See, the dynlinker on startup currently works like this:
>Stage 1: Process libc relative relocations
>Stage 2a: Process libc symbolic relocations
>Stage 2b: Load initial thread pointer
>Stage 3: Load dependencies, process all of the relocations.
>With TLS in libc, stage 2a would already encounter relocations
>referencing the TLS which gets allocated in stage 3 at the earliest,
>because that's when the allocator becomes available. A gordian knot.
Some of our ideas：
1、Anyway, we need to put the app's tls in the first block.
2、We can put the libc tls in the first or second part, depending on whether the app uses tls or not.
3、More details：
In Stage 2a, we can use aux to see whether the app uses tls and decode the tls size of the app.
Then we can know the tls offset of libc, it can be used for libc symbolic relocations.
Skip processing of libc in subsequent processing of TLS functions，like update_tls_size、assign_tls and so on.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
