[LLVMdev] MachO non-external X86_64_RELOC_UNSIGNED

Keno Fischer kfischer at college.harvard.edu
Mon Jun 9 15:32:38 PDT 2014


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


More information about the llvm-dev mailing list