[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Jan 2024 16:46:15 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: 847567161 <847567161@...com>
Subject: Re: 【Linker】Does MUSL
support using TLS for both libc and app dependencies?
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
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.
