[sysvabi64] Add chapter on Thread Local Storage #311

smithp35 · 2025-02-20T17:37:00Z

The thread local storage chapter contains:

A description of Thread Local Storage based on addenda32
The key design decisions of AArch64 TLS such as tls variant, tls dialect, TCB size.
The ABI required code sequence for TLSDESC that must be emitted exactly, as GNU ld requires it to be.
Sequences for the different code-models.
Relaxations for GD->IE, GD->LE and IE->LE.
Synchronization requirements for Lazy TLSDESC. With advice not to support it due to overhead of synchronization.

The thread local storage chapter contains: * A description of Thread Local Storage based on addenda32 * The key design decisions of AArch64 TLS such as tls variant, tls dialect, TCB size. * The ABI required code sequence for TLSDESC that must be emitted exactly, as GNU ld requires it to be. * Sequences for the different code-models. * Relaxations for GD->IE, GD->LE and IE->LE. * Synchronization requirements for Lazy TLSDESC. With advice not to support it due to overhead of synchronization.

MaskRay · 2025-02-21T06:19:34Z

sysvabi64/sysvabi64.rst

+and ``PT_TLS`` as the program header with type PT_TLS. ``PAD`` must be
+the smallest positive integer that satisfies the following congruence:
+
+``TP + TCB + PAD ≡ PT_TLS.p_vaddr (modulo PT_TLS.p_align)``


TP+TCB+PAD on the left could be confusing, as TCB is placed before TP. Perhaps mention the requirement of TP first (= 0 (modulo p_align)), then describe PAD and this formula.

I'll see if I can word it better. I've found it difficult to try and explain the formula intuitively.

MaskRay · 2025-02-21T06:25:40Z

sysvabi64/sysvabi64.rst

+Given that ``TP ≡ 0 (modulo PT_TLS.p_align)``. An expression
+for `PAD` is ``PAD = (PT_TLS.p_vaddr - TCB) mod PT_TLS.p_align``.
+
+A significant number of dynamic linkers use a different calculation


I believe that glibc Variant I handles p_vaddr!=0 (mod p_align) correctly. The bug (https://sourceware.org/bugzilla/show_bug.cgi?id=24606
) is for Variant II (x86 etc).

I have fixed FreeBSD rtld's Variant II in https://reviews.freebsd.org/D31538 . Its Variant I may or may not have the bug.

musl has been good since 1.1.23

Therefore, it's probably not "a significant number" but yeah p_vaddr=0 (mod p_align) is good for maximum compatibility

I found it difficult to be confident on the status of the various dynamic linkers. I can remove the significant part.

The glibc bug looks good for static TLS, it does mention in https://sourceware.org/bugzilla/show_bug.cgi?id=24606#c7 that dynamic TLS still needs p_vaddr to be 0 (modulo p_align).

MaskRay · 2025-02-21T06:30:37Z

sysvabi64/sysvabi64.rst

+    add  xn, tp, :tprel_hi12:var, lsl #12 // R_AARCH64_TLSLE_ADD_TPREL_HI12 var
+    ldr  xn, [xn, #:tprel_lo12_nc:var]    // R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC var
+
+Static link time TLS Relaxations


Perhaps call this Optimization to be consistent with x86/ppc and "Relocation optimization" (ADRP) and leave the term "relocation relaxation" for RISC-V style section shrinking.

For TLS specifically I'd prefer to keep relaxation as that's what its been referred to in all the previous literature such as Drepper's ELF Handling for Thread Local Storage and the TLSDESC paper too. It should help people searching in the references.

I take the point that it ought to have been called optimization. I'll add a sentence to say that we're using relaxation as a term from the existing literature.

MaskRay · 2025-02-21T06:39:15Z

sysvabi64/sysvabi64.rst

+
+Undefined Weak Symbols
+
+An undefined weak symbol has the value 0. As the resolver function


This might be the glibc behavior, but musl doesn't have the special __dl_tlsdesc_undefweak. I think it's better to allow flexibility and require a particular behavior on undefined weak TLS.

This part is just an example of what can be done. I've written at the top of the section

The TLS resolver functions are not standardized by this ABI as they are internal to the dynamic linker

and

These examples are for illustrative purposes only

I'll see if there's anything I can do to state that there is no requirement to implement a specific resolver function.

* Edits to split up the bullet points in How to denote TLS in source. * Changed program-own state to process-state as the thread-id may not be stored separately from the programs data. * Removed typically from some of the descriptions as the typically will almost always be the case for a sysvabi platform. * Linked alignment padding to the definition. * Provided a bit more information about generation counters.

* Rearranged formulas and used TCBsize to make it clearer. * Taken out "significant" from a significant number of dynamic linkers. * Give reason for using relaxation rather than optimization. * Clarify that there is no requirement to implement any TLSDESC resolver given in the sysvabi.

smithp35

Thanks very much for the review.

I've updated based on this and some comments I received internally.

smithp35 · 2025-02-21T14:56:07Z

sysvabi64/sysvabi64.rst

+Given that ``TP ≡ 0 (modulo PT_TLS.p_align)``. An expression
+for `PAD` is ``PAD = (PT_TLS.p_vaddr - TCB) mod PT_TLS.p_align``.
+
+A significant number of dynamic linkers use a different calculation


I found it difficult to be confident on the status of the various dynamic linkers. I can remove the significant part.

The glibc bug looks good for static TLS, it does mention in https://sourceware.org/bugzilla/show_bug.cgi?id=24606#c7 that dynamic TLS still needs p_vaddr to be 0 (modulo p_align).

smithp35 · 2025-02-21T14:58:49Z

sysvabi64/sysvabi64.rst

+    add  xn, tp, :tprel_hi12:var, lsl #12 // R_AARCH64_TLSLE_ADD_TPREL_HI12 var
+    ldr  xn, [xn, #:tprel_lo12_nc:var]    // R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC var
+
+Static link time TLS Relaxations


For TLS specifically I'd prefer to keep relaxation as that's what its been referred to in all the previous literature such as Drepper's ELF Handling for Thread Local Storage and the TLSDESC paper too. It should help people searching in the references.

I take the point that it ought to have been called optimization. I'll add a sentence to say that we're using relaxation as a term from the existing literature.

smithp35 · 2025-02-21T15:14:47Z

sysvabi64/sysvabi64.rst

+
+Undefined Weak Symbols
+
+An undefined weak symbol has the value 0. As the resolver function


This part is just an example of what can be done. I've written at the top of the section

The TLS resolver functions are not standardized by this ABI as they are internal to the dynamic linker

and

These examples are for illustrative purposes only

I'll see if there's anything I can do to state that there is no requirement to implement a specific resolver function.

smithp35 · 2025-02-21T15:29:01Z

sysvabi64/sysvabi64.rst

+and ``PT_TLS`` as the program header with type PT_TLS. ``PAD`` must be
+the smallest positive integer that satisfies the following congruence:
+
+``TP + TCB + PAD ≡ PT_TLS.p_vaddr (modulo PT_TLS.p_align)``


I'll see if I can word it better. I've found it difficult to try and explain the formula intuitively.

smithp35 force-pushed the sysvabitls branch from a261722 to 98ab4d7 Compare February 20, 2025 17:47

MaskRay reviewed Feb 21, 2025

View reviewed changes

smithp35 added 2 commits February 21, 2025 14:33

smithp35 commented Feb 21, 2025

View reviewed changes

fix CI due to broken reference

be64777

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[sysvabi64] Add chapter on Thread Local Storage #311

[sysvabi64] Add chapter on Thread Local Storage #311

smithp35 commented Feb 20, 2025

MaskRay Feb 21, 2025

smithp35 Feb 21, 2025

MaskRay Feb 21, 2025

smithp35 Feb 21, 2025

MaskRay Feb 21, 2025

smithp35 Feb 21, 2025

MaskRay Feb 21, 2025

smithp35 Feb 21, 2025

smithp35 left a comment

smithp35 Feb 21, 2025

smithp35 Feb 21, 2025

smithp35 Feb 21, 2025

smithp35 Feb 21, 2025


		Undefined Weak Symbols

		An undefined weak symbol has the value 0. As the resolver function

[sysvabi64] Add chapter on Thread Local Storage #311

Are you sure you want to change the base?

[sysvabi64] Add chapter on Thread Local Storage #311

Conversation

smithp35 commented Feb 20, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smithp35 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment