This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Should AArch64 *_NC relocs complain on overflow ?
- From: Jiong Wang <jiong dot wang at foss dot arm dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 08 Feb 2016 13:11:32 +0000
- Subject: Re: RFC: Should AArch64 *_NC relocs complain on overflow ?
- Authentication-results: sourceware.org; auth=none
- References: <87a8nb7bk8 dot fsf at redhat dot com> <ADC64823-9296-45C9-BCED-FFDC03CA29BB at arm dot com> <56B88C97 dot 6090308 at redhat dot com>
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."