Bug in bfd_install_relocation?

[Richard Sandiford]

Ian Lance Taylor <iant@google.com> writes:
> On Tue, Apr 30, 2013 at 7:16 AM, Ralf Dreesen <rdreesen@uni-paderborn.de> wrote:
>> I'm trying to retarget binutils-2.23.1. It appears to me, that there is
>> a bug in'bfd_install_relocation'  (I'm not sure).
>>
>> I have a relocation entry on a symbol FOO, whichs value is 2 (addend=0).
>> The entry is passed to bfd_install_relocation.
>> The variable'relocation*  is set to'symbol->value'  in line 1017. In
>> line 1077, the'reloc_entry->addend'  is set to'relocation', while
>> 'reloc_entry->sym_ptr_ptr' remains unchanged.
>> I finally end up with a wrong relocation entry 'FOO+2', insteand of just
>> FOO.
>>
>> Does anybody have an idea, why bfd_install_relocation adds the symbols
>> value to the addend?
>
> It is impossible to apply logic to bfd_install_relocation.  It does
> what it does.  It can't be changed because every port would break, or
> at least might break.  it was a mistake to add it in the first place,
> a mistake I must take some blame for since I suggested it.
>
> The only way to make things work better would be to introduce a new
> function and change ports to start using it.  Which is more or less
> how bfd_install_relocation happened in the first place.

Ralf: FWIW, MIPS is one port that did this locally,
see elfxx-mips.c:_bfd_mips_elf_generic_reloc and how it's used.
You should be able to ignore the unshuffle/shuffle stuff.

Thanks,
Richard