<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 6, 2018 at 2:07 PM, Jean-Daniel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><br><div><br><blockquote type="cite"><div>Le 6 juin 2018 à 22:37, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> a écrit :</div><br class="m_-6788792272689900011Apple-interchange-newline"><div><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;text-decoration:none"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 6, 2018 at 11:41 AM Brian Gesiak <<a href="mailto:modocache@gmail.com" target="_blank">modocache@gmail.com</a>> wrote:<br></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 dir="ltr">Thanks for the response, Rui!<div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 5, 2018 at 5:26 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> <wbr>wrote:<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 dir="ltr">Besides the features you pointed out, I think Xcode introduced a new way of listing dynamic linking symbols, and I believe lld doesn't support that.</div></blockquote><div><br></div><div>.tbd files, is that right? A colleague of mine pointed me to Apple's libtapi open source project [1], maybe I can learn more about these files from that library. In fact, there's been discussion about bringing libtapi to LLVM on the mailing list in the past, although I don't know if anything came of it. [2]</div><div><br></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 dir="ltr">I think the real issue is the lack of maintenance and ownership of the mach-O lld tree. There's no activities for the tree for years, though we've been making efforts to keep it compile and pass all the existing tests.</div></blockquote><div><br></div><div>Excellent, thanks for letting me know. This doesn't bother me, I'm happy to try contributing to it as best I can! I would also appreciate, as your time permits, whatever guidance you can provide. For example, benefitting from several years of hindsight, would you recommend keeping the ATOM-based lld approach? [3] Prior emails discussed moving Mach-O lld away from ATOM. [4] Has the success of ELF and COFF influenced your thinking on this in the years since, or is ATOM probably still the best fit for Mach-O?</div></div></div></div></div></blockquote><div><br></div><div>That's a good question. There was a big discussion as to the design of the new (now current ELF/COFF/wasm) and the ATOM-based lld a few years ago when I started working on the new one. At the time no one including me was really sure what design is desirable, and I was exploring the design space to something good. Today, we have three working, high-performance linkers for ELF, COFF and wasm based on the new design, which I think proves the design; it is easy to add new features, easy to understand, and it delivers what users want the most (i.e. speed). Given that, if I were you, I'd try to see if the new lld's design fits mach-O. You may need to tweak the design a little bit, but I'd imagine that the difference is not as significant as between ELF and wasm (which has a different concept of memory address space mainly for security). I'd also like to get input from Apple engineers as well.</div></div></div></div></blockquote><br></div></span><div>I don’t remember but I think one of the main point was that EFL and Mach-O don’t have the same concept of section. IIRC, the concept of section in ELF was closer to the atom model than with Mach-O which uses few sections and put a lot of things in each one.</div><div><br></div><div>And a quick search gave me that:  <a href="http://llvm.1065342.n5.nabble.com/LLD-improvement-plan-td80788.html#a80871" target="_blank">http://llvm.1065342.n5.<wbr>nabble.com/LLD-improvement-<wbr>plan-td80788.html#a80871</a></div></div></blockquote><div><br></div><div>Both ELF and Mach-O have roughly the same concept of sections, Mach-O just represents them in a weird way (by putting the delimiters between sections in the symbol table instead of using actual sections). So I think that all a new-style linker would need to do is read input files by splitting object file sections into subsections using the symbol table and allocating symbols and relocations to the correct subsections. Then linking would proceed in pretty much the same way as in the other ports of the linker.</div><div><br></div><div>Thanks,</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>