Skip to content

[AAELF64] Allow R_AARCH64_TLS_DTPREL to be used statically. #330

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
smithp35 merged 3 commits into from
Jan 12, 2026
Merged

[AAELF64] Allow R_AARCH64_TLS_DTPREL to be used statically. #330

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
89730de
[AAELF64] Allow R_AARCH64_TLS_DTPREL to be used statically.
smithp35 May 20, 2025
c602b01
[sysvabi64] Add assembler operator for dtprel.
smithp35 May 27, 2025
532dea9
[sysvabi64] Add changelog entry to sysvabi64 for 2026Q1 release [NFC]
smithp35 Jan 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions aaelf64/aaelf64.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -295,6 +295,9 @@ changes to the content of the document for that release.
| | | - Added section for structure protection|
| | | extension relocations. |
+---------------+--------------------+-----------------------------------------+
| 2026Q1 | 12\ :sup:`th` | - R_AARCH64_TLS_DTPREL can be used as a |
| | January 2026 | static relocation as well as dynamic |
+---------------+--------------------+-----------------------------------------+

References
----------
Expand Down Expand Up @@ -1730,6 +1733,27 @@ Thread-local storage descriptors
Relocation codes ``R_<CLS>_TLSDESC_LDR``, ``R_<CLS>_TLSDESC_ADD`` and ``R_<CLS>_TLSDESC_CALL`` are needed to permit linker optimization of TLS descriptor code sequences to use Initial-exec or Local-exec TLS sequences; this can only be done if all relevant uses of TLS descriptors are marked to permit accurate relaxation. Object producers that are unable to satisfy this requirement must generate traditional General-dynamic TLS
sequences using the relocations described in `General Dynamic thread-local storage model`_. The details of TLS descriptors are beyond the scope of this specification; a general introduction can be found in [TLSDESC_].

Thread Local Storage Data Relocations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A data relocation is required to describe the location of a TLS variable in debug information.

.. class:: aaelf64-tls-data-relocations

.. table:: TLS data relocations

+------------+------------+-----------------------------+------------------------------------+-------------------------------------------+
| 1028 | 184 | R\_<CLS>\_TLS\_IMPDEF1 | | See note below |
+------------+------------+-----------------------------+------------------------------------+-------------------------------------------+
| 1029 | 185 | R\_<CLS>\_TLS\_IMPDEF2 | | See note below |
+------------+------------+-----------------------------+------------------------------------+-------------------------------------------+
| | | R\_<CLS>\_TLS\_DTPREL | DTPREL(S+A) | See note below |
+------------+------------+-----------------------------+------------------------------------+-------------------------------------------+

``R_<CLS>_TLS_DTPREL`` is both a static and dynamic relocation. When used as a static relocation ``S`` must be fully resolved at static link time to a symbol definition in the same module as the relocation.

It is implementation defined whether ``R_<CLS>_TLS_IMPDEF1`` implements ``R_<CLS>_TLS_DTPREL`` and ``R_<CLS>_TLS_IMPDEF2`` implements ``R_<CLS>_TLS_DTPMOD`` or whether ``R_<CLS>_TLS_IMPDEF1`` implements ``R_<CLS>_TLS_DTPMOD`` and ``R_<CLS>_TLS_IMPDEF2`` implements ``R_<CLS>_TLS_DTPREL``; a platform must document its choice\ [#aaelf64-f1]_.

Relocations for PAuth ABI Extension
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Expand Down
24 changes: 22 additions & 2 deletions sysvabi64/sysvabi64.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -218,6 +218,9 @@ Change History
| | | .note.gnu.property section is present. |
| | | - Update distance to GOT for small code-model |
+------------+------------------------------+-------------------------------------------------------+
| 2026Q1 | 12\ :sup:`th` January 2026 | Add assembler conventions for data directive |
| | | relocation expressions. |
+------------+------------------------------+-------------------------------------------------------+

References
----------
Expand Down Expand Up @@ -461,8 +464,8 @@ variant of PIC called PIE (position-independent executable) can be
used to build an executable. PIE assumes that global symbols cannot be
pre-empted, which means that an indirection via the GOT is not needed.

Assembler language addressing mode conventions
----------------------------------------------
Assembler language addressing mode conventions for instructions
---------------------------------------------------------------

The assembler examples in this document make use of operators to
modify the addressing mode used to form the immediate value of the
Expand Down Expand Up @@ -654,6 +657,23 @@ syntax is of the form ``#:<operator>:<symbol name>``

PageBreak oneColumn

Assembler language addressing mode conventions for data
-------------------------------------------------------

The assembler operators that apply to instructions use the syntax
``#:<operator>:<symbol name>``. This syntax is not easy to apply to
data directives due to a parsing ambiguity with labels.
Copy link
Copy Markdown
Contributor

@jrtc27 jrtc27 Jul 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that true if you make .directive #foo legal, but redundant, unless there's an operator, at which point it disambiguates? Not saying it's nicer syntax, but it would avoid having the odd syntax split between instructions and data if so.

Copy link
Copy Markdown
Contributor Author

@smithp35 smithp35 Jul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for the delay in responding. I have been taking the statement in https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers on trust

Applying this syntax to data directives, however, could create parsing ambiguity. In both GNU Assembler and LLVM, .word :plt:fun would be interpreted as .word: plt: fun, treating .word and plt as labels, rather than achieving the intended meaning.

From the GNU as manual https://sourceware.org/binutils/docs/as/Statements.html

A label is a symbol immediately followed by a colon (:). Whitespace before a label or after a colon is permitted, but you may not have whitespace between a label’s symbol and its colon. See Labels.

At least from the perspective of the syntax .word :plt:fun is not legal when written as .word: plt: fun however MaskRay may be referring to the implementations, and changing them to support .word :plt:fun may be non trivial.

We'd need to do some further investigation to clarify.


The recommended syntax for data directives is ``<directive> %operator(expression)``

.. table:: TLS operators

+-----------------------+------------+------------------+
| Operator | Data size | Relocation |
+=======================+============+==================+
| ``dtprel`` | 8 bytes | R_AARCH64_DTPREL |
+-----------------------+------------+------------------+

Code Models
===========

Expand Down