smithp35 wrote: > Thanks @smithp35 for your solution! I would like to kindly ask for your > expertise in reviewing the following code, which implements backend support > for -mlong-calls on AArch64 targets. It might not need to be merged, just > considering it as an optional approach. Thank you once again for your time and consideration.
I'm mostly a linker/ABI person so I'm not much of an expert in code-generation, if I can find some time I can check to see if I can spot any obvious mistakes. The thing I'd want to check for is that the rest of the backend has recorded these additional indirect calls. I'm thinking in particular of BTI which the compiler can sometimes omit when it can show there are no indirect calls to a symbol. I can't help with this being merged as this is a maintainers call. Even if the code is correct today, it will need to be maintained and future changes/transformations will need to make sure it doesn't break. The maintainers have to decide whether the use case is worth it for a wide-variety of use cases or whether it should be a downstream change. > Yes, we are indeed still using the -mlong-calls option in our older embedded > systems. This is necessary due to the lack of support for GOT-based > relocation types in these environments. As a result, we have incorporated > this option to ensure compatibility and functionality. The two linkers I'm most familiar with lld and Arm's proprietary linker armlink will statically resolve the GOT relocations when doing a static link, I would expect GNU ld to do this too. LLD will even transform the GOT access to a PC-relative one when the definition is local https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#579relocation-optimization . https://github.com/llvm/llvm-project/pull/142982 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
