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

[Peter Smith via llvm-commits]

https://github.com/smithp35 commented:

Thanks for the updates.

Although possibly not for this patch. It looks llvm-objdump (and gnu objdump) look to reorder $x after $d when the symbols are at the same address. This looks like worse case behaviour.

I think we could address this by looking at llvm-objdump, or we could have lld filter out the clashes.

The other tool that I thought could be affected by this is Bolt. It uses mapping symbols to determine the location of constant islands. It looks to do this with CodeOffsets and DataOffsets (some references below). Are your large programs likely to be post-processed by Bolt? 

Some references:
https://github.com/llvm/llvm-project/blob/main/bolt/include/bolt/Core/BinaryFunction.h#L1972
https://github.com/llvm/llvm-project/blob/main/bolt/lib/Core/BinaryEmitter.cpp#L539
https://github.com/llvm/llvm-project/blob/main/bolt/lib/Core/BinaryFunction.cpp#L1049

Apologies to keep bringing these up. What I want to avoid is people finding other llvm tools subtly broken. I don't think that these are a blocker for implicit mapsyms, but it should influence the level of warning we give for the option. We may want to call out Bolt specifically as a tool that could be affected for example.

I think the code here is good for llvm-mc. I don't have any more comments on this patch.

I've got a last couple of questions:
* Do you want to update llvm-objdump as whatever collation order the linker uses, it is going to order `$d` before `$x`? I think that could be done in different patch.
* If Bolt could get confused by two symbols at the same address I think we'll need to call that out in the clang driver help text. Do you think it would be worth an lld patch to remove (or make both symbols the same) when there is a clash? That would make Bolt work for a LLVM based toolchain.

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