--- Comment #10 from Ard Biesheuvel <ard.biesheuvel at linaro dot org> ---
(In reply to Renlin Li from comment #9)
> (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.

Thank you Renlin. May I kindly suggest that you also look at the other issue,
which is related?

In that case, a runtime relocation is emitted even for SHN_ABS symbols, which
means the resulting value becomes dependent on the load address.

You are receiving this mail because:
You are on the CC list for the bug.
bug-binutils mailing list

Reply via email to