[musl] =?gb18030?B?ob5MaW5rZXKhv0RvZXMgTVVTTCBzdXBwb3J0IHVzaW5nIFRMUyBmb3IgYm90aCBsaWJjIGFuZCBhcHAgZGVwZW5kZW5jaWVzPw==?=

[musl] =?gb18030?B?ob5MaW5rZXKhv0RvZXMgTVVTTCBzdXBwb3J0IHVzaW5nIFRMUyBmb3IgYm90aCBsaWJjIGFuZCBhcHAgZGVwZW5kZW5jaWVzPw==?=

[=?gb18030?B?ODQ3NTY3MTYx?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 772 bytes --]

1¡¢About builtin_tls
  Q1: What if the size of the tls used by libc is larger than the builtin size?
      https://github.com/bminor/musl/blob/master/ldso/dynlink.c#L1785


  Q2: I haven¡¯t seen any processing of the tls segment of ldso, so how does __copy_tls take effect at this time£¬ where was  libc.tls_head be modified before this time?
      https://github.com/bminor/musl/blob/master/src/env/__init_tls.c#L64


  Q3: Is it possible to init main thread tls by calling malloc according to the tls size of libc at this time?


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.

[-- Attachment #2: Type: text/html, Size: 1027 bytes --]

Re: [musl] 【Linker】Does MUSL support using TLS for both libc and app dependencies?

[Markus Wichmann]

Am Sun, Jan 21, 2024 at 04:56:40PM +0800 schrieb 847567161:
> 1、About builtin_tls
>   Q1: What if the size of the tls used by libc is larger than the builtin size?
>       https://github.com/bminor/musl/blob/master/ldso/dynlink.c#L1785
>

What's with these HTML entities in the plain text? Your email client is
misconfigured.

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.

The line you've marked merely sets up a dummy thread-pointer. It will be
overwritten in line 2034 if the actual initial TLS allocation is too
large.

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.

>
>   Q2: I haven’t seen any processing of the tls segment of ldso, so how does __copy_tls take effect at this time， where was  libc.tls_head be modified before this time?
>       https://github.com/bminor/musl/blob/master/src/env/__init_tls.c#L64
>

See above. ldso and libc are the same in musl, and libc cannot have TLS
at this time.

>
>   Q3: Is it possible to init main thread tls by calling malloc according to the tls size of libc at this time?
>

Main thread TLS is allocated with malloc (well, calloc) in dynlink.c,
line 2017. That is the entire TLS size, no matter how many TLS modules
there are.

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.

I will not repeat myself again.

Ciao,
Markus

Re: [musl] 【Linker】Does MUSL support using TLS for both libc and app dependencies?

[Rich Felker]

On Sun, Jan 21, 2024 at 04:46:15PM +0100, Markus Wichmann wrote:
> Am Sun, Jan 21, 2024 at 04:56:40PM +0800 schrieb 847567161:
> > 1、About builtin_tls
> >   Q1: What if the size of the tls used by libc is larger than the builtin size?
> >       https://github.com/bminor/musl/blob/master/ldso/dynlink.c#L1785
> >
> 
> What's with these HTML entities in the plain text? Your email client is
> misconfigured.
> 
> As to the question: Libc itself cannot use TLS. It could in the static

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.

> 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.
> 
> The line you've marked merely sets up a dummy thread-pointer. It will be
> overwritten in line 2034 if the actual initial TLS allocation is too
> large.
> 
> 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.

The intent is always to support environments where the kernel does not
get to do that (overcommit disabled). What happens with the default
overcommit-enabled behavior is always at best a best-effort thing.

> >   Q2: I haven’t seen any processing of the tls segment of ldso, so how does __copy_tls take effect at this time， where was  libc.tls_head be modified before this time?
> >       https://github.com/bminor/musl/blob/master/src/env/__init_tls.c#L64
> >
> 
> See above. ldso and libc are the same in musl, and libc cannot have TLS
> at this time.
> 
> >
> >   Q3: Is it possible to init main thread tls by calling malloc according to the tls size of libc at this time?
> >
> 
> Main thread TLS is allocated with malloc (well, calloc) in dynlink.c,
> line 2017. That is the entire TLS size, no matter how many TLS modules
> there are.

This is not actually the public malloc but __libc_malloc. Application
code (including a potentially replaced malloc) is not valid to call at
this point (or any point before __libc_start_main).

> 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.

Rich