<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 8 Jun 2017, at 3:30 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" class="">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Jun 7, 2017 at 2:46 PM, Michael Clark via llvm-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On 8 Jun 2017, at 4:53 AM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>> wrote:</div><br class="gmail-m_5022343054990783953Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev<span class="gmail-m_5022343054990783953Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.<wbr class="">org</a>></span><span class="gmail-m_5022343054990783953Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class="">OK. I see that the Mach-O linker is not even built when LLD is enabled in Release_40, only the PE/COFF and ELF linkers are built.<div class=""><br class=""></div><div class="">From looking at reviews it appears that Clang was able to be linked with LLD on Darwin about 2 years ago, so Mach-O support seems to have regressed.</div></div></blockquote><div class=""><br class=""></div><div class="">Only a few changes have been made to the Mach-O port in the last two years, so I'd doubt if it has regressed. It could be the case that clang's output has changed in such a way that the linker is not able to handle it.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That’s actually good news!</div><div class=""><br class=""></div><div class="">If there is a Mach-O linker that is able to self host Clang builds on macOS, then this is a really good starting point.</div><div class=""><br class=""></div><div class="">From reading a tiny bit about the history, and the LLVM pages on the design of the various linkers, it seems like there is a difference in opinion with respect to the Atom based design of the Mach-O LLD, and whether or not there was to be an abstract design that supports ELF, PE/COFF and Mach-O. It seems not. One would also assume that LTO and/or -ffunction-sections -fdata-sections would obviate the need for Atoms, and that it may in fact increase the complexity of the linker.</div></div></div></blockquote><div class=""><br class=""></div><div class="">InputSection (ELF) and Chunk (COFF) are basically "atoms". The main technical obstacle to using atoms for ELF and COFF is that the atom model used in the original linker design assumes a 1:1 mapping of symbols to "atoms" (and the symbol points to the start of the atom). In ELF and COFF symbols and InputSection/Chunk’s are decoupled because you can have multiple symbols pointing anywhere in the InputSection/Chunk.</div></div></div></blockquote><div><br class=""></div><div>Interesting.</div><div><br class=""></div><div>I will take a closer look at the Atom model.</div><div><br class=""></div><div>So a symbol has to be able to map to Atom + Addend or indirectly (N_INDR) to another symbol name, with strong exports taking precedence over weak. I’m assuming the Atom model supports indirect symbol references. I will see if I can generate some.</div><div><br class=""></div><blockquote type="cite" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class="">From my cursory examination of the source it seems that lld/lib should perhaps be renamed lld/MachO and become the MachO linker besides the ELF and COFF directproes as the common code is not being used by the ELF and the PE/COFF linkers.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The original linker design used by MachO had greater ambitions than the current ELF and COFF designs. It was more aiming for the sort of linker model explained in Paul Bowen-Hugett's talk at the 2016 LLVM developer meeting<span class="Apple-converted-space"> </span><a href="https://youtu.be/-pL94rqyQ6c?t=20m29s" class="">https://youtu.be/-pL94rqyQ6c?t=20m29s</a></div></div></blockquote><div><br class=""></div><div>Thanks for the link.</div><div><br class=""></div><div>The idea of just regenerating changed fragments within source is an interesting if somewhat lofty goal. Reminds me of Merkle hash trees.</div><div><br class=""></div><div>However as you point out, there is raw asm and branch labels in asm (presumably inside of Atoms) which are also symbols so while a distinct Atom link might still be consistent, Atom + addend referenced externally in other (inline) asm as an expression in terms of labels may no longer be valid so other fragments (with inline asm) may become invalid. The dependency graph would need to account for symbols that were expressed in asm as expressions between symbols. e.g.</div><div><br class=""></div><div>atom1:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>..</div><div>.L1</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>..</div><div><br class=""></div><div>atom2:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>..</div><div>.L2</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>..</div><div><br class=""></div><div>atom3:</div><div>.quad .L2 - .L1</div><br class=""><blockquote type="cite" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">One way to think about this is that ld64 is already a fast linker that is controlled by the people that work on LLD at Apple. So there isn't much incentive to do what ELF and COFF have done which is at this point getting to a production quality linker program. The original hope for LLD was to go beyond ld64's capabilities to enable new and interesting use cases (see the talk I linked above for some examples). However, for ELF and COFF there wasn't a linker controlled by the LLVM community for those platforms, and so merely reimplementing existing linker programs (with some extra attention to QoI and being modern) was an interesting enough goal in and of itself to push their development. The LLVM community did not want to wait to get ELF and COFF working pending the materialization of next generation linker use cases; simply meeting the requirements of existing linker uses cases was sufficient.</div><div class=""><br class=""></div><div class="">(Note: we still aren't aware of any concrete analysis or experiment demonstrating real benefit to these "next generation linker use cases"; many of them seem quite interesting, but under closer inspection there are a lot of issues that haven't been fully explored)</div><div class=""><br class=""></div><div class="">Anyway, that was a very long way of saying that the MachO linker is actually a very different design and even source organization (it was intended to be factored along certain library boundaries, but we haven’t seen any uses cases that would use that), so that moving it to lld/MachO doesn't really make much sense.</div></div></blockquote><div><br class=""></div><div><br class=""></div><div>So it probably does make sense for the ELF and PE/COFF linkers to use the Atom model some time in the future, given the Atom model is updated to correctly model indirect references and addends, etc. I will take a look…</div><br class=""><blockquote type="cite" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">I just need to figure out how to build and invoke the Mach-O linker. There is no ‘ld’ in the llvm bin directory as one would be led to believe. I’ll dig into the CMakeLists.txt. I guess lld/lib//Driver/<wbr class="">DarwinLdDriver.cpp is the entry point. lld//lib/Driver/<wbr class="">CMakeLists.txt however only appears to define a library, versus an executable and there is no top level MachO directory like there is for the other 2 linkers.</div><div class=""><br class=""></div><div class="">$ lld<br class="">lld is a generic driver.<br class="">Invoke ld.lld (Unix), ld (Mac) or lld-link (Windows) instead.<br class=""><br class=""></div><div class="">$ ld.lld --version<br class="">LLD 4.0.0<br class=""><br class=""></div><div class="">$ lld-link --version<br class="">ignoring unknown argument: --version<br class="">error: no input files<br class=""><br class=""></div><div class="">If I know which CMakeLists.txt defines the binary that hosts the main function and installs it, then I can take it from there.</div></div></div></blockquote><div class=""><br class=""></div><div class="">You can see the logic that it uses in lld/tools/lld/lld.cpp</div><div class=""><br class=""></div><div class="">To access the MachO linker, you will want to either run `lld -flavor darwin ...` or invoke lld through a symlink such that argv[0] is `ld` (this is only enabled when LLD is compiled to run on an Apple host machine (#if __APPLE__)).</div><div class=""><br class=""></div><div class="">I guess we could install an `ld64` symlink to access the MachO linker, but the actual system linker on macOS is never actually invoked via the name `ld64` (that's just a name for the linker itself; not the binary; the binary is always `ld`).</div><div class=""><br class=""></div><div class="">-- Sean Silva</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="gmail-h5"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">Curious as to pointers to primordial branches with whatever needs to be resurrected. I couldn’t find any Mach-O cmake flags to enable its build. A pointer to a branch or tag that might have a working Mach-O LLD would be a start.<div class=""><div class="gmail-m_5022343054990783953h5"><br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 7 Jun 2017, at 11:38 AM, Michael Clark <<a href="mailto:michaeljclark@mac.com" target="_blank" class="">michaeljclark@mac.com</a>> wrote:</div><br class="gmail-m_5022343054990783953m_-7136958054444710928Apple-interchange-newline"><div class=""><div style="word-wrap: break-word;" class="">Hi Rui,<div class=""><br class=""></div><div class="">The motivation would be primarily that LLVM/Clang/LLD are community projects such that if I or someone in the community added support for e.g. symbol aliases, then it could be reviewed and potentially merged. ld64 on the other hand does not have a community process for patch submission and code review that I am aware of so its unlikely that if someone from the community came up with a patch to support aliases that it would be merged.</div><div class=""><br class=""></div><div class="">In that case I might check out the LLD code and try linking “x86_64-xnu-musl” with it. My requirements are likely simpler than Apple’s however I do need symbol aliases and these are not supported by ld64. The linker synthesised symbols are likely not too difficult to add if they are not present… now on my to do list…</div><div class=""><br class=""></div><div class="">Michael.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 7 Jun 2017, at 11:30 AM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>> wrote:</div><br class="gmail-m_5022343054990783953m_-7136958054444710928Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Michael,<div class=""><br class=""></div><div class="">The Mach-O version of LLD is not being developed actively, and if some feature is missing, it is likely that it's just not implemented. What is your motivation to use LLD instead of ld64?</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jun 6, 2017 at 4:08 PM, Michael Clark via llvm-dev<span class="gmail-m_5022343054990783953Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.<wbr class="">org</a>></span><span class="gmail-m_5022343054990783953Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">Hi Folks,</div><div class=""><br class=""></div><div class="">I have a question regarding LLD support for ld64 mach-o linker synthesised symbols. I did a quick search of the LLD source and I can not find support for them so before I start trying to use lld I thought I would ask.</div><div class=""><br class=""></div><div class="">I have found a couple of cases where they are essential. i.e. where there is no other way to get the required information, such as getting the address of the mach-o headers of the current process, with ASLR enabled, if the process is not dyld as exec on macOS only provides the mach header address to dyld (*1). They are used inside of dyld and I am now using them in “x86_64-xnu-musl”.</div><div class=""><br class=""></div><div class="">It’s possible to resolve a mach-o segment offset or a mach-o section offset using these special ld64 linker synthesised symbols. See resolveUndefines:</div><div class=""><br class=""></div><div class="">- <a href="https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/Resolver.cpp.auto.html" target="_blank" class="">https://opensource.apple.com<wbr class="">/source/ld64/ld64-274.2/src/ld<wbr class="">/Resolver.cpp.auto.html</a></div><div class=""><br class=""></div><div class="">There are 4 special symbol prefixes for the mach-o linker synthesised symbols:</div><div class=""><br class=""></div>- segment$start$__SEGMENT<br class="">- segment$end$__SEGMENT<br class="">- section$start$__SEGMENT$__sect<wbr class="">ion<br class=""><div class="">- section$end$__SEGMENT$__sectio<wbr class="">n</div><div class=""><br class=""></div><div class="">In asm:</div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class="">/* get imagebase and slide for static PIE and ASLR support in x86_64-xnu-musl */</div><div class=""><br class=""></div><div class="">.align 3</div><div class="">__image_base:</div><div class="">.quad segment$start$__TEXT</div><div class="">__start_static:</div><div class="">.quad start</div><div class="">.text</div><div class="">.align 3</div><div class="">.global start</div><div class="">start:</div><div class=""> xor %rbp,%rbp</div><div class=""> mov %rsp,%rdi</div><div class=""> andq $-16,%rsp</div><div class=""> movq __image_base(%rip), %rsi</div><div class=""> leaq start(%rip), %rdx</div><div class=""> subq __start_static(%rip), %rdx</div><div class=""> call __start_c</div></blockquote><div class=""><br class=""></div><div class="">In C:</div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class="">/* run C++ constructors in __libc_start_main for x86_64-xnu-musl */</div><div class=""><br class=""></div></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class="">typedef void (*__init_fn)(int, char **, char **, char **);<br class="">extern __init_fn __init_start __asm<wbr class="">("section$start$__DATA$__mod_i<wbr class="">nit_func");<br class="">extern __init_fn __init_end __asm("section$end$__DATA$__<wbr class="">mod_init_func”);<br class=""><div class=""><br class=""></div><div class="">static void __init_mod(int argc, char **argv, char **envp, char **applep)</div><div class="">{</div><div class=""> for (__init_fn *p = &__init_start; p < &__init_end; ++p) {</div><div class=""> (*p)(argc, argv, envp, applep);</div><div class=""> }</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">Michael.</div><div class=""><br class=""></div><div class="">[1] <a href="https://github.com/opensource-apple/xnu/blob/dc0628e187c3148723505cf1f1d35bb948d3195b/bsd/kern/kern_exec.c#L1072-L1111" target="_blank" class="">https://github.com/opensou<wbr class="">rce-apple/xnu/blob/dc0628e187c<wbr class="">3148723505cf1f1d35bb948d3195b/<wbr class="">bsd/kern/kern_exec.c#L1072-L11<wbr class="">11</a></div></div><br class="">______________________________<wbr class="">_________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class=""><br class=""></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></div></div><br class="">______________________________<wbr class="">_________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a></blockquote></div></div></div></div></blockquote></div></div></div><br class=""></div><br class="">______________________________<wbr class="">_________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a></blockquote></div></blockquote></div><br class=""></body></html>