[PATCH v1 1/3] aarch64: Fix IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and symbol reduction for relocations

[Martin Storsjö]

On Mon, 9 Sep 2024, Evgeny Karpov wrote:

> The main focus for the GCC 15 release is to raise the quality of GCC
> as high as possible for the new aarch64-w64-mingw32 target.
> With this change, the toolchain is able to build OpenBLAS (resolving
> an issue with large objects), build FFmpeg with -O3 (resolving
> relocation overflow), and support LTO, which also generates large
> objects with reshuffling. The quality has been raised from 72% to
> 96% unit test pass rate.

That sounds good - but you shouldn't break GNU ld, which this patch does 
(breaking interoperability, bringing a new nonstandard interpretation of 
the IMAGE_REL_ARM64_PAGEBASE_REL21 relocation), to do that.

If you want to make GCC not emit offsets for these adrp/add pairs, in 
order to work around issues in large objects that you may have, that's 
probably fine. You can do that without this patch. But you shouldn't make 
GNU ld no longer handle the adrp instructions with offset, that work 
seemingly correctly right now.

> Currently, GCC is not using offsets in relocation instructions.
> Support for symbols and offsets in native assembly was not within
> the scope of the current contribution window.
>
> How might the offset potentially be supported?
>
>    add x0, x0, symbol_in_same_page + 128
>    add x0, x0, :lo12:symbol_in_same_page + 128
>
> adrp might be unrolled to something like this or more
> optimally by binutils, with the last instruction unchanged.
>
>    adrp x0, symbol_in_same_page + (128 & ~0xfff)
>    add x0, x0, :lo12:symbol_in_same_page
>    add x0, x0, 128 & 0xfff
>    and x0, x0, ~0xfff
>
>    add x0, x0, :lo12:symbol_in_same_page + 128
>
> In this case, it makes sense to have offsets disabled in GCC.

Sorry, this example is very unclear to me. "might be unrolled by 
binutils"?

Where does binutils do this? In the assembler, or in the linker? Why does 
it do this? That instruction sequence is 5 instructions long, for 
something that equally can be just 2 instructions, why is that optimal?

Can you provide an actual, complete reproducible example of the issue that 
you're claiming?

I.e. an assembly file (or several) that one first assembles, and then 
links, to showcase the problem you're describing? Then we can 
crossreference the handling of it against LLD and MS link.exe and see what 
differs.

Whatever the issue is, the solution is not what this patch does, which 
breaks the support of one of the COFF ARM64 relocations.

// Martin