[llvm-dev] Mach-O support in lld: what are the known issues?

[Peter Collingbourne via llvm-dev]

On Wed, Jun 6, 2018 at 2:07 PM, Jean-Daniel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> Le 6 juin 2018 à 22:37, Rui Ueyama <ruiu at google.com> a écrit :
>
> On Wed, Jun 6, 2018 at 11:41 AM Brian Gesiak <modocache at gmail.com> wrote:
>
>> Thanks for the response, Rui!
>>
>> On Tue, Jun 5, 2018 at 5:26 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>> 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.
>>>
>>
>> .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]
>>
>> 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.
>>>
>>
>> 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?
>>
>
> 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.
>
>
> 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.
>
> And a quick search gave me that:  http://llvm.1065342.n5.
> nabble.com/LLD-improvement-plan-td80788.html#a80871
>

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.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180606/258a86a4/attachment.html>