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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
