Comment 14 for bug 1746765

(In reply to Peter Smith from comment #5)
> I think that the new error message for R_AARCH64_ABS32 from the linker makes
> some sense if the destination symbol is section relative as there is no
> dynamic relocation supported and truncating a 64-bit address is most likely
> a mistake.
>
> However if the destination symbol is absolute the linker shouldn't make the
> assumption that the symbol is an address so it should resolve the relocation
> at static link-time.
>
> I think the test:
> case BFD_RELOC_AARCH64_16:
> #if ARCH_SIZE == 64
> case BFD_RELOC_AARCH64_32:
> #endif
> if (bfd_link_pic (info)
> && (sec->flags & SEC_ALLOC) != 0
> && (sec->flags & SEC_READONLY) != 0)
> ... Give error message
> Should check that the symbol is not absolute as well.
>
> Unfortunately I can't think of a workaround for the case where the value of
> the symbols has to be in the RO-segment. For some reason the check only
> applies in RO sections, which does not make a lot of sense to me as a
> R_AARCH64_ABS32 from a RW section to an address will truncate it in the same
> way as if it were from a RO section. No dynamic relocation is generated for
> either RO or RW so I don't know why the distinction has been made.

Indeed, for a absolute symbol, the assumption that it represents an address is not correct.
A check should be added to allow absolute symbol with R_AARCH64_ABS relocation.

The condition here is to apply the constrain only in allocatable text or read-only data section, where I though is more likely to be a place to store fixed address.

I will prepare a patch, trying to fix the absolute symbol case.