[PATCH] [PECOFF] Relocations now take into account the address which is stored at the relocation site

[Rui Ueyama]

Thanks Ron,

I haven't looked at the stackoverflow question to be on the safe side, but
looks like we can say that the DUMPBIN output strongly suggest that the
value stored at the relocation site should be added as an addend. At least
it will cause no harm if the addend is zero. So I'm OK with this patch.

If our assumption is wrong, it'll be proved to be wrong pretty easily, as
it'll become a obvious bug. I don't worry about that.

Could you write a test? Or if you are not sure how to test it, I can write
a test for you.


On Sat, Jul 27, 2013 at 10:49 AM, Ron Ofir <ron.ofir at gmail.com> wrote:

> Here's what little I have found so far:
>
> 1. In the MS COFF spec, chapter 5.6.2 "Base Relocation Types", it is said
> that "The base relocation applies all 32 bits of the difference to the
> 32-bit field at offset", which I guess means that the relocation should
> take into account whatever address is already stored at the specified
> offset. However, chapter 5.6 (the .reloc section) is only relevant to image
> files, and not object files.
> 2. The dumpbin utility adds a column named "Applied To" when printing the
> relocations table, which seems to always (no matter the relocation type)
> contain the value which is stored at the relocation site.
> 3. The Relocation Directives chapter in the DJGPP COFF Specification
> clearly states that the value currently stored at the location should be
> added to the address of the symbol pointed to by the relocation table
> entry. However, it is DJGPP and not MS...
>  On Jul 27, 2013 3:52 PM, "Ron Ofir" <ron.ofir at gmail.com> wrote:
>
>> I have added some other sources of information I've found to my
>> stackoverflow question, could you take a look there?
>> On Jul 27, 2013 3:27 PM, "Nico Rieck" <nico.rieck at gmail.com> wrote:
>>
>>> On 27.07.2013 13:07, Chandler Carruth wrote:
>>>
>>>> If this isn't covered by the spec, we shouldn't use stackoverflow to
>>>> figure
>>>> it out. Instead, Rui may need to confirm of refute it manually. =/
>>>>
>>>
>>> I've seen this for SECREL and ADDR32NB relocations. Also, dumpbin has an
>>> "Applied To" column.
>>>
>>> For example, these are relocations for .pdata, generated by MSVC,
>>> denoting start and end for a 0x30 byte main() and it's unwind info:
>>>
>>> RELOCATIONS #6
>>>                                                 Symbol    Symbol
>>>  Offset    Type              Applied To         Index     Name
>>>  --------  ----------------  -----------------  --------  ------
>>>  00000000  ADDR32NB                   00000000        11  $LN10
>>>  00000004  ADDR32NB                   00000030        11  $LN10
>>>  00000008  ADDR32NB                   00000000        14  $unwind$main
>>>
>>>
>>> -Nico
>>> ______________________________**_________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/**mailman/listinfo/llvm-commits<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>>>
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130727/2414f645/attachment.html>