[PATCH] D72892: [MC][ARM] Resolve some pcrel fixups at assembly time

[Peter Smith via Phabricator via llvm-commits]

psmith added a comment.

My personal view is that we should be able to support adr and ldr to a global symbol defined in the same section, whether at link time or at assembly time. As well as Linux, Android and BSD there is large number of embedded systems that use assembler and are entirely statically linked that we risk breaking without a good error message. I would like to avoid that situation if at all possible. I don't think we need to support adr and ldr to symbols defined outside the section as the range is too short to practically use them.

My summary of the options:
1.) Revert D72892 <https://reviews.llvm.org/D72892>, D75039 <https://reviews.llvm.org/D75039>, don't apply D75349 <https://reviews.llvm.org/D75349> and we don't support adr, ldr to a global symbol, period.

- This breaks existing code that if only run in an executable is fine. Static linking of executables encompasses almost all embedded systems code where assembly, and use of adr/ldr is most likely to occur.
- This protects authors that run their code in a shared library and end up with a broken program due to symbol interpositioning.

2.) Keep this patch, revert D75039 <https://reviews.llvm.org/D75039> and don't apply D75349 <https://reviews.llvm.org/D75349>, essentially evaluate adr and ldr at assembly time even to global symbols. All other expressions use relocations.

- We keep all existing code building
- We protect authors from symbol interpositioning apart from adr and ldr.
- For adr and ldr to a global symbol, it is user error to use the resulting object in a shared object and interpositioning occurs.

3.) Implement D75349 <https://reviews.llvm.org/D75349> and expose adr and ldr as relocations, the linker decides if the use is valid.

- We keep all existing code building assuming linker can support the relocations.
- Linker knows the context, shared or non-shared and can decide whether to permit adr/ldr to globals in shared contexts. My existing LLD patches don't do that, but follow on patches could.
- Resolving the relocations, particularly the Arm ADR adds complexity to the linker.

I'd be happy with 2 or 3, my reason for advocating for 3 is that it could address most of the concerns at the cost of linker complexity, I'd prefer not to go back to 1 if at all possible.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72892/new/

https://reviews.llvm.org/D72892