[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240121171326.GB4163@brightrain.aerifal.cx>
Date: Sun, 21 Jan 2024 12:13:26 -0500
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com, 847567161 <847567161@...com>
Subject: Re: 【Linker】Does MUSL
support using TLS for both libc and app dependencies?
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
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.
