Trying to understand some relocation handling on Mach-O X86-64

[Rafael Espíndola]

Forgot to attache the .o in the original email.

On 6 February 2014 01:27, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> It all started with pr17976. In it we avoided producing IR that would
> in turn produce a MachO that was incompatible with having atoms
> defined by symbols in __TEXT,__const.
>
> I reported the more basic issue in pr18743: the IR was valid. We
> should figure out a way to produce a valid Mach-O from it or reject it
> loudly way before it gets to ld.
>
> From there I noticed that L symbols in __TEXT,__cstring are output,
> but L symbols in similar looking sections like __TEXT,__ustring are
> not and reported pr18748 about it.
>
> The comment in the code that decides to output the L symbols says:
>
>     // Temporary labels in the string literals sections require symbols. The
>     // issue is that the x86_64 relocation format does not allow symbol +
>     // offset, and so the linker does not have enough information to resolve the
>     // access to the appropriate atom unless an external relocation is used.
>
> Now,  why would one use a symbol+offset? I tried the attached patch
> and testcase. For both __TEXT,__literal8 and __TEXT,__cstring it has
> an external symbol, a private (L) symbol and they are both referred
> from another section (.data).
>
> The output for __TEXT,__literal8 is the same as we have now. The patch
> changes the output for the cstring to be analogous to the __literal8.
> Why wouldn't this work? With it we produce the attached Mach-O. It has
> two very similar relocations. One points to __literal8 and the other
> to __cstring. Neither is external. Since the sections contain a known
> datatype, the offset tells us all that there is to know about what the
> relocations point to (the number 42 and the c string "bar") and the
> linker should be able to merge them.
>
> With this patch I was able to do a 3 stage bootstrap on OS X x86-64.
>
> Cheers,
> Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.o
Type: application/x-object
Size: 624 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140206/087dace5/attachment.o>