<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 11, 2018, at 11:52 AM, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Apr 10, 2018 at 5:33 PM Jake Ehrlich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Benifits of TBD:<br class="">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 class="">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 class=""></div></blockquote><div class=""><br class=""></div><div class="">I'm still skeptical that this is significant.</div></div></div></div></blockquote><div><br class=""></div>For Apple it certainly is, mostly because TBDs can support multiple architectures in a much more efficient way than fat images do. Apple has a <i class="">lot</i> of architecture/SDK variants with a lot of redundancy between what libraries export on different platforms.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">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 class=""><br class="">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></blockquote><div class=""><br class=""></div><div class="">Yea, a tool which can produce a .so from a textual description is certainly much less concerning than adding linker support for a new textual description format. If it's an official linker-supported format, it'd be yet another format that potentially needs to be standardized across multiple linkers, and kept compatible for"ever", etc. I just don't think that seems worthwhile for ELF.</div><div class=""><br class=""></div><div class="">OTOH, a standalone tool which can convert from a "full" shared-object to an interface shared-object would be _great_ to have. If that tool also has some auxiliary textual I/O format it supports, I guess that's fine, too. (We do have some existing yaml <-> ELF support, via the "obj2yaml" and "yaml2obj" tools.)</div><div class=""><br class=""></div><div class="">I'd note that reproducing all the things that are required/used from an ELF shared object during linking -- symbol type, binding-type, visibility, version, alignment (!), .gnu.warning messages, various important "SHT_NOTE" sections, and whatever other things I've forgotten about, will need to be a _significantly_ different format than what Apple has as their "TBD" format. Apple's format also has a bunch of special cases in it to make it easier to use for their platform, but a rather less generic tool. E.g., symbols starting with "_OBJC_CLASS_$" are recorded in the "objc-classes" field with the prefix removed, instead of just recording it as-is.</div><div class=""><br class=""></div><div class="">So, I'd also caution that while the project of "import apple's libtapi into LLVM for LLD/MachO" and "Make a scheme to do interface shared-libs for ELF" might seem superficially related, I'd be very surprised if that actually ended up being the case. I would really not expect it to share just about anything at all other than the concept of being a textual description for a library.</div></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>