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

Martin Storsjö martin@martin.st
Mon Sep 9 13:17:45 GMT 2024


On Mon, 9 Sep 2024, Evgeny Karpov wrote:

> Friday, September 6, 2024
> Martin Storsjö <martin@martin.st> wrote:
>
>> entry:
>>          adrp x0, symbol_in_same_page
>>          add x0, x0, :lo12:symbol_in_same_page
>>          adrp x0, symbol_in_same_page+108
>>          add x0, x0, :lo12:symbol_in_same_page+108
>
>> The output instruction sequence is the exact same in the case of all 3
>> linkers - the only thing that differs is the amount of symbols retained.
>
>> Now if you apply your patch and redo the last example, linked with GNU ld,
>> the output adrp relocations turn out wrong. Previously all 3 linkers
>> agree. Thus I think your patch is wrong, and the current handling of this
>> relocation in binutils is correct.
>
> In the case of this patch, the offset should be excluded from
> relocation instructions.
>
> adrp x0, symbol_in_same_page
> add x0, x0, :lo12:symbol_in_same_page
> add x0, x0, 108
>
> It produces the same result for all three linkers. This is the
> reason why offset usage was avoided in the GCC patch series
> for aarch64-w64-mingw32.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662499.html

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?

// Martin


More information about the Binutils mailing list