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

[Ron Ofir]

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/20130728/d1828cd0/attachment.html>