[llvm] [AArch64, ELF] Allow implicit $d/$x at section beginning (PR #99718)
Fangrui Song via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 12 23:14:01 PDT 2024
MaskRay wrote:
> > Can we alleviate these concerns by marking object files that use this mapping symbol convention. That way we could fix them up later if needed.
>
> That was my first thought, too.
>
> As far as I can see, this option is essentially inventing a nonstandard variation on the Arm ELF spec, which is not fully compatible with the standard one, as the PR description mentions:
>
> > This scheme works as long as the user can rule out some error scenarios:
> >
> > * .text.1 assembled using the traditional behavior is combined with .text.2 using the new behavior
>
> Currently, as far as I can see, the only way that a user _can_ rule out this error scenario is to use their own memory and self-discipline to keep track of which objects (or which libraries, or which whole projects) they're building using this nonstandard flag.
You're absolutely right. The nonstandard option is invaluable for those with full control over their toolchain, no reliance on weird relocatable files, and a strong focus on minimizing both relocatable and executable sizes.
This aligns with the needs of (a) large-scale build environments, (b) huge open-source projects, and (c) distributions like Gentoo.
(I haven't used Gentoo for a while, but I would certainly use this option to make my builds faster and smaller.)
> Surely it would be better to mark object files to indicate explicitly that they follow this nonstandard ABI. Then at the very least a linker can detect a mixture of the two and complain, even if it can't automatically compensate. That way the user doesn't have to do it all by self-discipline.
While marking object files could be beneficial, it's essential to avoid overly restrictive compatibility checks. False positives could hinder development.
(I actually wanted to write a blog post about compatibility check and inconvenience, but I kept postponing the writing...)
For example, the following code assembled with a traditional assembler could get marked to be incompatible with `.text; .nop` using the nonstandard behavior.
```
.text
nop
.long 0
```
But pure code should not trigger incompatiblity warning.
```
.text
nop
```
https://github.com/llvm/llvm-project/pull/99718
More information about the llvm-commits
mailing list