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

[Rui Ueyama]

That's OK.


On Sat, Jul 27, 2013 at 9:11 PM, Ron Ofir <ron.ofir at gmail.com> wrote:

> I'll gladly write a test for it, however I'll only be available to work on
> it again on Thursday or Friday. Is that ok?
>  On Jul 28, 2013 1:56 AM, "Rui Ueyama" <ruiu at google.com> wrote:
>
>> 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/be0d3096/attachment.html>