[llvm] [AArch64, ELF] Allow implicit $d/$x at section beginning (PR #99718)

[Peter Smith via llvm-commits]

smithp35 wrote:

> Renamed to "implicit-mapsyms"
> 
> > To give you a summary of my thoughts so far:
> > 
> > * I don't think we'll be able to change the AArch64 ABI as I don't think there's enough consensus on the GNU side for a relocatable object based solution.
> 
> Ack.
> 
> > * An alternative, likely LLVM only, opt-in option for users with large projects, in control of their own toolchain to reduce mapping symbols could be valuable to those projects.
> 
> Looks good.
> 
> > * I'd like to discourage use of the opt-in option where portability of the relocatable objects is a concern. For example, while there are no plans to do so, I couldn't guarantee the AArch64 ABI might make changes that would retain backwards compatibility.
> 
> I agree with your point about discouraging its use where portability is crucial.
> 
> Does the last sentence read as: the AArch64 ABI might make changes to break backwards compatibility. But with what?
> 
If another ISA like Thumb is to Arm is added to AArch64 [*] then we wouldn't be able to tell which instruction set to start with for an executable section. There are likely some implicit assumptions we can make if we're sensible, such as defaulting to AArch64 if there's no mapping symbol, and if the other ISA is used it needs a mapping symbol. I suspect that llvm tools could be made to work, however it could get messy with GNU and other tools. 

[*] Morello's hybrid mode does this. A subset of the CHERI instructions can be used in EM_AARCH64 after some transitioning like Arm to Thumb. The majority of experimentation with Morello has been in pure capability mode which is a separate machine from AARCH64.

> Looks good. Recording the mapping symbol scheme might depend on `SHT_AARCH64_ATTRIBUTES`, which has no GNU/LLVM toolchain implementation yet.
> 
> > [#99718 (comment)](https://github.com/llvm/llvm-project/pull/99718#issuecomment-2286565171) While I don't want to speculate too much over how to mark an object, I'm wondering if it is something you're willing to entertain?
> 
> Yes, I'm open to exploring that once the base mechanism is available.
> 

I'm expecting a build attributes implementation in GNU fairly shortly for GCS assuming it can hit early enough for the GCC release cycle. It may have to slip to the next GCC release if it doesn't make it in time though. I'm hoping that we can get a LLVM implementation started for LLVM 20.



https://github.com/llvm/llvm-project/pull/99718