binutils

Bug #1746765
Comment #15

Comment 15 for bug 1746765

Revision history for this message

In Sourceware.org Bugzilla #22764, Ard Biesheuvel (ard-biesheuvel) wrote on 2018-02-02:

#15

(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?

https://sourceware.org/bugzilla/show_bug.cgi?id=20402

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

(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?

https://sourceware.org/bugzilla/show_bug.cgi?id=20402

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