[AAELF64] Allow R_AARCH64_TLS_DTPREL to be used statically. #330
Conversation
Permit the R_AARCH64_TLS_DTPREL dynamic relocation to be used statically so that debug information can describe the location of TLS variables. All code sequences to access TLS data use immediates, hence all existing static TLS relocations are instruction relocations. To describe the location of a TLS variable in debug information requires a static data relocation. The necessary expression needed is DTPREL(S + A) which is performed by the traditional dialect dynamic relocation R_AARCH64_TLS_DTPREL. There is prior art in the x86_64 and PPC64 ABIs to use the equivalent relocation R_X86_64_DTPOFF64 and R_PPC_DTPREL64 respectively for relocating debug information statically. The 32-bit Arm ABI uses the R_ARM_TLS_LDO32 static local dynamic relocation. The advantage of using local dynamic is that these only apply to a TLS variable local to the module so no additional note is needed. An alternative design adds a new relocation code to local dynamic. fixes: ARM-software#176 a static relocation with the necessary
To use the R_AARCH64_DTPREL relocation from assembler requires an operator. The current syntax for instructions :<operator>: is not ideal for data directives due to a parsing ambiguity with labels. For example .word :operator: is parsed as label ".word :" followed by "operator:" followed by "foo". Following llvm/llvm-project#132570 suggest that we adopt %operator(expression) for data directives.
|
I've chosen to use %operator(expr) for data directives following the conversation in llvm/llvm-project#132570 based on https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers |
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
2 participants
Permit the R_AARCH64_TLS_DTPREL dynamic relocation to be used statically so that debug information can describe the location of TLS variables.
All code sequences to access TLS data use immediates, hence all existing static TLS relocations are instruction relocations.
To describe the location of a TLS variable in debug information requires a static data relocation. The necessary expression needed is DTPREL(S + A) which is performed by the traditional dialect dynamic relocation R_AARCH64_TLS_DTPREL.
There is prior art in the x86_64 and PPC64 ABIs to use the equivalent relocation R_X86_64_DTPOFF64 and R_PPC_DTPREL64 respectively for relocating debug information statically.
We also introduce a syntax for assembler operators operating on data directives, with an instance %dtprel(expr) to generate R_AARCH64_DTPREL.
The 32-bit Arm ABI uses the R_ARM_TLS_LDO32 static local dynamic relocation. The advantage of using local dynamic is that these only apply to a TLS variable local to the module so no additional note is needed. An alternative design adds a new relocation code to local dynamic.
fixes: #176