[LLVMdev] MachO non-external X86_64_RELOC_UNSIGNED

[Keno Fischer]

*it's not *x = *x


On Mon, Jun 9, 2014 at 6:32 PM, Keno Fischer <kfischer at college.harvard.edu>
wrote:

> Let me correct that to noting that
>
> *x = (*x-addr_of_section(r_symbolnum)) + addr_of_section(r_symbolnum)
>
> actually makes sense to do when you're moving the section (so it's *x =
> *x, sorry for the confusion). It still strikes me as inconsistent with the
> first definition though, but maybe that's ok?
>
>
> On Sun, Jun 8, 2014 at 11:59 PM, Keno Fischer <
> kfischer at college.harvard.edu> wrote:
>
>> Hello everybody,
>>
>> I would like some insights on the semantics of the X86_64_RELOC_UNSIGNED
>> relocation type. When r_extern=1, the semantics seem pretty clear:
>>
>> Let x be a pointer to r_offset of appropriate size given by r_size, then
>> *x += addr_of_symbol(r_symbolnum)
>>
>> However, when r_extern=0 the correct behavior is not clear. By analogy
>> with the above, I would have expected
>>
>> *x += addr_of_section(r_symbolnum)
>>
>> but what LLVM implements is different. In RTDyld it implements
>>
>> *x = (*x-addr_of_section(r_symbolnum)) + addr_of_section(r_symbolnum)
>>
>> or equivalently
>>
>> *x = *x
>>
>> i.e. a noop. This works because llvm codegen also emits the absolute
>> value of the address. I am unsure what is intended and would appreciate
>> some clarification. A couple of points to consider:
>>
>> 1. I checked ld64 and as far as I can tell it doesn't consider
>> non-external X86_64_RELOC_UNSIGNED but does *x +=
>> addr_of_symbol(r_symbolnum) regardless. That seems like a bug in ld64 to me
>> because other relocations in the same switch statement do check r_extern.
>>
>> 2. I implemented *x += addr_of_section(r_symbolnum) in LLVM and all tests
>> pass just fine
>>
>> 3. If the current implementation is correct r_symbolnum (and potentially
>> the entire relocation) basically meaningless, which could of course be
>> correct, but which is what originally caused me to look at this. If so I'd
>> appreciate an explanation as to why we need to have the relocation in the
>> first place.
>>
>> That's all I could find on the subject. I hope somebody else knows more
>> than I.
>>
>> Thanks,
>> Keno
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140609/4c07c608/attachment.html>