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

[Evgeny Karpov]

Monday, September 9
Martin Storsjö <martin@martin.st> wrote:

> Sure, if we stop using offsets with adrp, this patch doesn't break 
> anything.
> 
> But my example is a totally valid object file, that all existing linkers 
> handle correctly and consistently right now - which would be broken with 
> GNU ld after your patch.

> You would need to convince the whole ecossytem to stop using 
> IMAGE_REL_ARM64_PAGEBASE_REL21 with an offset, including LLVM and MSVC.

> And why should we stop using it? I have not yet seen a coherent 
> explanation of why you want to do this in the first place?

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.

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.

Regards,
Evgeny