<div dir="ltr">Benifits of TBD:<br>1) It's human readable and diffs on TBDs correspond to changes in the ABI. Diffs can be automatically added to review processes to ensure that changes to the ABI are reviewed. The TBDs also document your precise ABI.<br>2) The size is smaller which means they can be shipped in an SDK instead of binaries to reduce the size of an SDK<br>3) Stubs are producible from TBDs (or should be) which means stubs for linking can be produced even if we don't directly support them in LLD. This lets you ship the smaller TBD files in place of larger binaries and still link things without direct linker support (assuming you already ship a toolchain with your SDK or expect your users to have this tool)<br><br>Since stubs are producible from TBDs I don't really see a downside. I think we need both, I was going to propose a yaml based representation for ELF for the above reasons anyhow.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018 at 1:14 PM Andrew Kelley via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 9, 2018 at 10:11 PM, John Ericson 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_8380427565236013758gmail-">> Regardless of any of that, given that TBD files _are_ an integral part of the apple platform, supporting them is certainly a necessity in order to have a working apple linker. So, if making LLD work for Apple/MachO is the justification for adding TBD support to LLVM, that seems self-evidently a reasonable thing to do. On the other hand, it looks like the LLD mach-o code is unmaintained and nobody seems to be much interested in it. And having code for reading TBD files in LLVM seems not terribly interesting, unless it is as part of a project to make the LLD MachO linker actually functional and supported.<br>
<br></span>
Yes. I hope this can be reason enough. Hobbyists could push for LLD support for Mach-O besides Apple, and if LLD is to displace other linkers this is a necessary component as you say. Better to upstream now before the code diverges than more work later? Conversely if nothing happens, I doubt libtapi would be a greater drag on the codebase than the MachO LLD code, so whatever cost/benefit analysis exists for keeping that around could also apply to this.</blockquote><div><br><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Speaking for the Zig project here, our goal is to support cross-compilation for any target, on any target, without requiring installation of any target-specific SDK. So, for example, these use cases:<br></div><div> * on linux, compile & link a binary targeting macos<br></div><div> * on windows, compile & link a binary targeting macos<br><br></div><div>This works today, although it depends on a patch to LLD to fix the MACH-O linker that is not high enough quality to upstream.<br><br></div><div>So we have a vested interest in improving the MACH-O linker, and in fact a Zig community member has fixed at least one bug in MACH-O LLD: <a href="http://reviews.llvm.org/D35387" target="_blank">reviews.llvm.org/D35387</a><br><br></div><div>I don't fully understand how TBD or TAPI works, but I hope that it results in improvements to the MACH-O linker.<br></div><div><br></div><div> </div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>