On Thu, 19 Sep 2024, Richard Sandiford wrote:
Martin Storsjö <mar...@martin.st> writes:
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.
Maybe this is my ELF bias showing, but: generating extra X=Y+OFF
symbols isn't generally valid for ELF when Y is a global symbol, since
interposition rules, comdat, weak symbols, and various other reasons,
could mean that the local definition of Y isn't the one that gets used.
Does COFF cope with that in some other way? If not, I would have
expected that there would need to be a fallback path that didn't
involve defining extra symbols.
That's indeed a fair point. COFF doesn't cope with that in other ways - so
defining such extra symbols to cope for the offsets, for global symbols
that can be interposed or swapped out at linking stage, would indeed be
wrong.
In practice, I think it's rare to reference such an interposable symbol
with an offset overall - even more so to reference it with an offset over
1 MB.
The practical cases where one mostly runs into the limitation, is when you
have large sections, and use temporary labels to reference positions
within those sections. As the temporary labels don't persist into the
object file, the references against temporary labels end up as against
section base, plus an offset. And those symbols (the section base) aren't
global.
The workaround I did for this within LLVM,
https://github.com/llvm/llvm-project/commit/06d0d449d8555ae5f1ac33e8d4bb4ae40eb080d3,
deals specifically only with temporary symbols.
// Martin
