[musl] Question about the TLS

[musl] Question about the TLS

[.]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Hi
I have one question in TLS.
I intend to incorporate a Thread-Local Storage (TLS) variable into the musl library.  However, the musl library does not currently support the 
handling of TLS variables within the ldso library.  Could you please advise if there are any potential risks or issues associated with adding TLS
 variables and the corresponding processing logic?
Best 
ye

 

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

Re: [musl] Question about the TLS

[Markus Wichmann]

Am Tue, Dec 17, 2024 at 03:11:06PM +0800 schrieb  .:
> Hi
> I have one question in TLS.
> I intend to incorporate a Thread-Local Storage (TLS) variable into the musl library.  However, the musl library does not currently support the 
> handling of TLS variables within the ldso library.  Could you please advise if there are any potential risks or issues associated with adding TLS
>  variables and the corresponding processing logic?
> Best
> ye
>
>  

Main problem that I see is the bootstrapping of TLS relocations inside
of LDSO at this time. LDSO bootstrapping at this point works like this:

- Stage 1 (dlstart.c): Process relative ldso relocations.
- Stage 2:
    - Initialize dynamic linking structures
    - Temporarily process symbolic ldso relocations
- Stage 2b: Set thread pointer to builtin TLS initially.
- Stage 3:
    - Load LD_PRELOAD + possibly app + dependencies
    - Process all relocations (including symbolic ldso relocs again)
    - Properly initialize TLS and thread pointer.

The initialization of TLS requires that the allocator (malloc et al.)
work already. This requires that all dependencies be loaded and symbolic
relocations be done. At this point, the only way I can think of to do
this would be to create a stage 4 for all the TLS stuff. You'd have to
shuffle some code around, and ensure that stage 3 never calls any stuff
that depends on TLS until it is set up in stage 4.

What do you want TLS in libc for, anyway? Mayhaps a simpler thing would
be to add a field to struct __pthread?

Ciao,
Markus

Re: [musl] Question about the TLS

[Rich Felker]

On Tue, Dec 17, 2024 at 05:25:37PM +0100, Markus Wichmann wrote:
> Am Tue, Dec 17, 2024 at 03:11:06PM +0800 schrieb  .:
> > Hi
> > I have one question in TLS.
> > I intend to incorporate a Thread-Local Storage (TLS) variable into the musl library.  However, the musl library does not currently support the 
> > handling of TLS variables within the ldso library.  Could you please advise if there are any potential risks or issues associated with adding TLS
> >  variables and the corresponding processing logic?
> > Best
> > ye
> >
> >  
> 
> Main problem that I see is the bootstrapping of TLS relocations inside
> of LDSO at this time. LDSO bootstrapping at this point works like this:
> 
> - Stage 1 (dlstart.c): Process relative ldso relocations.
> - Stage 2:
>     - Initialize dynamic linking structures
>     - Temporarily process symbolic ldso relocations
> - Stage 2b: Set thread pointer to builtin TLS initially.
> - Stage 3:
>     - Load LD_PRELOAD + possibly app + dependencies
>     - Process all relocations (including symbolic ldso relocs again)
>     - Properly initialize TLS and thread pointer.
> 
> The initialization of TLS requires that the allocator (malloc et al.)
> work already. This requires that all dependencies be loaded and symbolic
> relocations be done. At this point, the only way I can think of to do
> this would be to create a stage 4 for all the TLS stuff. You'd have to
> shuffle some code around, and ensure that stage 3 never calls any stuff
> that depends on TLS until it is set up in stage 4.
> 
> What do you want TLS in libc for, anyway? Mayhaps a simpler thing would
> be to add a field to struct __pthread?

The existing musl-internal way to do TLS is indeed putting the data in
struct __pthread. As Markus noted, there are complications doing TLS
relocations for libc/ldso itself, as they would have to be performed
twice, since it's not known whether libc can use TLS offset/slot zero
until the main executable has been processed, and it's not necessarily
even loaded yet.

Since eventually we probably want to support TLS in libc/ldso (for
example, the linked-in parts of libgcc might need it if we ever
support fenv for softfloat, even if musl code itself never does), I
think it makes sense to be on the lookout for clean solutions. One
that comes to mind is using negative offset for libc TLS (same
positioning as struct __pthread) so that it doesn't clash with
nonnegative offsets for other modules, and thereby doesn't necessitate
performing the relocations twice.

But in the short term if someone custmizing musl wants TLS, the way
that works is stuffing it in struct __pthread.

Rich