RFC: Should AArch64 *_NC relocs complain on overflow ?

[Jiong Wang]

On 08/02/16 16:53, Nick Clifton wrote:
> Hi Jiong,
>
>> +		  /* 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.
> Do you have a testcase that can demonstrate this ?

This can only be triggered when the .o file is postprocessed by tools 
like objcopy, where
the user might use options like --keep-global-symbol to turn a global 
symbol into local after
compilation stage that gcc was generating PIC sequences instead of 
pc-relative addressing sequences,
thus trigger this bug.

A simple testcase which contains three initialized global varibles, then 
a function simply return the middle one of them, and
compile/link with the following steps can reproduce this bug.

gcc -fpic -c 1.c
objcopy -L gb 1.o 1.modified.o
ld -shared -o lib1.so 1.modified.o
1.modified.o: In function `foo':
1.c:(.text+0x4): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC 
against `gb'

>
>>     Therefore, I think relocation against unaligned value can origin from
>>     various reasons.
> True - that is why I used "Possibly" at the start of the warning message.
> Ie the message is only a suggestion, not a guarantee.
>
>>   IMHO, the safest way is, in
>>     "_bfd_aarch64_elf_put_addend", we return something like
>>     "bfd_reloc_unaligned" which is an general warning,
> That means make changes to the generic parts of the BFD library, which I would
> prefer to avoid unless really necessary.  But if
>
>> something like
>>     "relocation against unaligned value warning."
> But that will not help ordinary programmers who will not understand why
> there is an alignment mismatch.  Given that the overflown relocation error
> has turned up more than once in real production code, and confused the
> programmers who then report bugs against the linker, I think that it is
> in our interests to be as helpful as possible.
>
> How about this rewording instead:
>
>    One possible cause of this error is that the symbol is being
>    referenced in the indicated code as if it had a larger
>    alignment than was declared where it was defined.
>
>
> Cheers
>    Nick
>
>
>