| Issue |
132570
|
| Summary |
[AArch64] Assembly syntax for relocation specifier in data directives
|
| Labels |
backend:AArch64,
mc
|
| Assignees |
|
| Reporter |
MaskRay
|
https://reviews.llvm.org/D81446 and https://github.com/llvm/llvm-project/pull/72584 , introduced the assembly syntax `.word sym@plt-.` and `.word sym@gotpcrel` for R_AARCH64_PLT32 and R_AARCH64_GOTPCREL32 relocations.
This syntax was chosen due to an existing quirk in LLVM's AsmParser, where `@plt` was universally accepted until my recent update (commit a067175) made it an opt-in parsing feature.
( https://reviews.llvm.org/D156505 introduced `@AUTH(ib, 1234, addr)`
The use of `@plt` as a specifier applied to every subexpression is considered awkward.
The reliance on `MCSymbolRefExpr::VariantKind for representing these relocations introduces complexity and inconsistencies within LLVM's internal representation.
As detailed in https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers#relocation-specifier-flavors , this approach highlights inelegance in how LLVM handles relocation specifiers.
As a more concrete example, https://reviews.llvm.org/D156505 , which introduced `@AUTH(ib, 1234, addr)`, had to reject all kinds of invalid syntax
**after** parsing time (e.g. `.quad _g9@AUTH(ia,42) - _g8@AUTH(ia,42)`), which is not ideal.
A more standard syntax like `.word :specifier: expr` would be more desirable (another specifier cannot appear in a subexpression), but there is a parsing ambiguity: `.word :plt:fun` would be parsed as labels, and not as a relocation specifier.
(RISC-V could use `.word %specifier(expr)`, which has no ambiguity. I have proposed https://github.com/llvm/llvm-project/pull/132569 )
This issue aims to record the current undesirable and inconsistent state. @smithp35
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
