This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Should AArch64 *_NC relocs complain on overflow ?

Nick Clifton writes:

> Hi Marcus, Hi Jiong,
>> NC relocations do complain if the relocation requires some minimum alignment 
>> and the final relocated value does not meet that requirement.  Consider, for 
>> example, instructions with an implicit scaling of an address offset, 
>> relocations used for those instruction, including the NC form will gripe if 
>> the offset being inserted into the instruction is not a multiple of the 
>> implicit scaling implied.
> OK that makes sense, 
> It would be nice if we could generate a more helpful warning message for the user.
> What do you think of a patch like the one below ?  With this applied we get output 
> like the following:
> 1.c:(.text+0x4): relocation truncated to fit: R_AARCH64_LDST32_ABS_LO12_NC against symbol `var_2' defined in COMMON section in tmpdir/dump1.o
> 1.c:(.text+0x4): warning: Possibly the symbol is being referenced via a differently aligned type to its declaration>, no expected output


  For your comments:

+		  /* FIXME: Are we testing all of the appropriate reloc
+		     types here ?  */
+		  && (real_r_type == BFD_RELOC_AARCH64_LDST16_LO12
+		      || real_r_type == BFD_RELOC_AARCH64_LDST32_LO12
+		      || real_r_type == BFD_RELOC_AARCH64_LDST64_LO12
+		      || real_r_type == BFD_RELOC_AARCH64_LDST128_LO12))

  Some GOT relocation types will cause the same error.
  I once fixed another relocation against unaligned value bug, see

  That time, it was caused by wrong GOT handling for local
  symbol (R_AARCH64_LD64_GOT_LO12_NC). The relocation is against GOT
  entry address, but GOT entry for local symbol was not created, and we
  were using symbol value instead of GOT entry address, thus failed the
  8byte alignment check on AArch64.
  Therefore, I think relocation against unaligned value can origin from
  various reasons. IMHO, the safest way is, in
  "_bfd_aarch64_elf_put_addend", we return something like
  "bfd_reloc_unaligned" which is an general warning, something like
  "relocation against unaligned value warning."

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]