https://sourceware.org/bugzilla/show_bug.cgi?id=22764
--- 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? 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. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
