On Thu, 12 Sep 2024, Evgeny Karpov wrote:
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and COFF relocation records.
Yes, I agree.
But I would not consider this a limitation of the binutils implementation,
this is a limitation of the object file format. It can't be worked around
by inventing your own custom relocations, but should instead worked around
on the code generation side, to avoid needing such large offsets.
This approach is one such, quite valid. Another one is to generate extra
symbols to allow addressing anything with a smaller offset.
To unblock the current patch series, the IMAGE_REL_ARM64_PAGEBASE_REL21
relocation will remain unchanged, and the workaround below will be applied to
bypass the 1MB offset limitation.
This looks very reasonable - I presume this will make sure that you only
use the other code form if the offset actually is larger than 1 MB.
For the case when the offset actually is larger than 1 MB, I guess this
also ends up generating some other instruction sequence than just a "add
x0, x0, #imm", as the #imm is limited to <= 4096. From reading the code,
it looks like it generates something like "mov x16, #imm; add x0, x0,
x16"? That's probably quite reasonable.
I don't know how emit_move_insn behaves if the immediates are larger -
does it generate a sequence of mov/movk to materialize a larger constant?
Because the range of immediates you can encode in one single mov
instruction is pretty limited anyway.
// Martin
