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

[Rafael Espíndola]

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: patch
Type: application/octet-stream
Size: 902 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140206/7cfdad30/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.s
Type: application/octet-stream
Size: 220 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140206/7cfdad30/attachment-0001.obj>