This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Bug in bfd_install_relocation?
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Ralf Dreesen <rdreesen at uni-paderborn dot de>, binutils at sourceware dot org
- Date: Tue, 30 Apr 2013 17:26:50 +0100
- Subject: Re: Bug in bfd_install_relocation?
- References: <517FD222 dot 1000300 at uni-paderborn dot de> <CAKOQZ8wkEymHArWRebeGiAroAETs-xWDayLkoC7MjJ-MrRmvhQ at mail dot gmail dot com>
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