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

[Ron Ofir]

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>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130727/8ece838b/attachment.html>