[PATCH] D101873: [clang] Support clang -fpic -fno-semantic-interposition for AArch64

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D101873#2741903 <https://reviews.llvm.org/D101873#2741903>, @peter.smith wrote:

> In D101873#2741299 <https://reviews.llvm.org/D101873#2741299>, @MaskRay wrote:
>
>> https://gist.github.com/MaskRay/2d4dfcfc897341163f734afb59f689c6 has more information about -fno-semantic-interposition.
>>
>>> Can Clang default to -fno-semantic-interposition?
>>
>> I think we can probably make non-x86 default to -fno-semantic-interposition (dso_local inference, given D72197 <https://reviews.llvm.org/D72197>. x86 may find default -fno-semantic-interposition too aggressive.
>
> Thanks for the link, and the explanation that -fno-semantic-interposition is not the default.
>
> I'm not (yet) convinced that we could make -fno-semantic-interposition the default, primarily due to data and not functions, I agree that interpositioning functions is rarely used. For data the classic example for symbol-interposition was errno, a shared library can't know if any other library or executable will define it so it must define, but it must use only one value for the definition. I'm not sure if that still holds in today's environment with shared C libraries used by practically everything but I think the principle still applies.

errno needs to be thread-local. C11 7.5.2 says "and errno which expands to a modifiable lvalue that has type int and thread local storage duration, the value of which is set to a positive error number by several library functions."
Do you mean that in some environment it may be defined in more than one shared object?

> Looking at the gist I've got one concern for AArch64 and Arm. The ABI relies on thunks which are only defined for symbols of type STT_FUNC. Changing branches to STT_FUNC to STT_SECTION will break long range thunks on AArch64 and interworking for Arm (there is a possibility that the bottom bit for STT_FUNC may get used in the future for AArch64 as well). This is solvable by keeping the local label and setting STT_FUNC on it.

I'll unlikely touch 32-bit arm.

For aarch64, aaelf64/aaelf64.rst says

  A linker may use a veneer (a sequence of instructions) to implement a relocated branch if the relocation is either
  
  ``R_<CLS>_CALL26``, ``R_<CLS>_JUMP26`` or ``R_<CLS>_PLT32`` and:
  
  - The target symbol has type ``STT_FUNC``.
  
  - Or, the target symbol and relocated place are in separate sections input to the linker.
  
  - Or, the target symbol is undefined (external to the link unit).

If `bl .Lhigh_target$local` and `.Lhigh_target$local` are in the same section, the fixup is resolved at assembly time;
otherwise, they are in separate sections and satisfy the ABI requirement.

I just changed `bl high_target` in `test/lld/ELF/aarch64-thunk-script.s` and noticed that both GNU ld and ld.lld can produce a thunk, regardless of the symbol type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101873