This is the mail archive of the binutils@sourceware.org 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: [gold patch 1/3] Support for incremental linking: write incremental inputs, symtab, relocs


Cary Coutant <ccoutant@google.com> writes:

>>> + Â Â Â// Get the addend.
>>> + Â Â Âtypename elfcpp::Elf_types<size>::Elf_Swxword addend;
>>> + Â Â Âif (sh_type == elfcpp::SHT_RELA)
>>> + Â Â addend =
>>> + Â Â Â Â Reloc_types<sh_type, size, big_endian>::get_reloc_addend(&reloc);
>>> + Â Â Âelse
>>> + Â Â Â Â{
>>> + Â Â Â Â Â// FIXME: Get the addend for SHT_REL.
>>> + Â Â Â Â Âaddend = 0;
>>> + Â Â Â Â}
>>
>> Why does the value of the addend matter for a SHT_REL section?
>
> Because the original addend will have been overwritten by the result
> of the relocation during the previous link. Hmmm, maybe it could be
> recovered because we know the original value of the symbol. I'll have
> to think about that -- I think that would require more target-specific
> knowledge than it would take to just fetch the original addend here.

Fetching the addend is of course target specific--e.g., MIPS, in which
the full addend can be spread across two different relocs.  I wonder
whether we will need a target-specific interface which takes the old and
new value of the symbol and updates the section contents accordingly.
Simple targets like i386 can use a standard implementation.

Ian


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