<span>This isn't the same as obj2yaml. It would only contain information relavant to linking. obj2yaml attempts to be a full textual representation. Also calling the output of obj2yaml machine readable is kind of dubious since it has a reasonably complex output format and is *not* an inverse of yaml2obj as the name might suggest. No inverse of it exists as far as I am aware. obj2yaml is better for testing than reviewing the public interface of a DSO.</span><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018, 4:37 PM Rui Ueyama 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 dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018 at 4:27 PM Petr Hosek <<a href="mailto:phosek@chromium.org" target="_blank">phosek@chromium.org</a>> wrote:<br></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"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018 at 3:12 PM Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></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"><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018 at 2:42 PM Armando Montanez via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Since the goal is to start llvm-tapi more or less from scratch, I feel<br>
the best approach initially is to focus on the structure as a key<br>
point of feedback in initial reviews. Once the foundations are set,<br>
integrating Mach-O TAPI in parallel with the ELF implementation should<br>
be relatively straightforward. The features outside of stubbing aren't<br>
as appealing for ELF, so I probably won't be working on extending that<br>
functionality. With that being said, the overall design goal is<br>
generalization/abstraction where possible to welcome feature parity in<br>
case it is eventually desired. I'm sure we'll run into things that<br>
belong in the tool but end up being uniquely specialized, and it will<br>
probably be best to address them on a case-by-case basis.<br></blockquote><div><br></div><div>I'm not very sure what you meant by generalizing it, but given that</div><div><br></div><div>1) implementing a text-based ELF stub format is not appealing, and we probably won't implement, and</div></div></div></blockquote><div><br></div><div>You could use readelf/objdump, but these tools weren't designed with that use-case in mind and their output isn't adequate for many of the common use cases we're considering: it's not well-specified, it's not designed to be machine (and often human) readable or easily diffable. All the ad-hoc solutions out there, many of which were pointed out in Armando's proposal, demonstrate the need for text-based representation. While, I understand your concerns, I think we should focus on the tool and library itself and leave the discussion of direct linker support for later.</div></div></div></div></div></blockquote><div><br></div><div>I don't have an objection to creating a tool to dump a DSO contents in a machine-readable format, though looks like its goal overlaps with existing obj2yaml tool, as obj2yaml is intended to convert a native binary object file to a YAML text file.</div><div><br></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"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>We're also not firmly set on YAML. We've chosen YAML because it's already used by Apple's Mach-O implementation, but we could consider a different format and we're open to suggestions. However, given our requirements (machine and human readable, easily diffable) I'm not sure if we're going to come up with something that's significantly different from YAML. Furthermore, YAML has the advantage of already being supported in variety of languages.</div></div></div></div></div></blockquote><div><br></div><div>I guess that YAML is fine. LLVM's YAML reader is kind of slow, but that's an implementation matter.</div><div><br></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"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </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"><div class="gmail_quote"><div>2) COFF already has its own (binary) stub format,</div></div></div></blockquote><div><br></div><div>Do you have a reference that describes the format and the tooling?</div><div></div></div></div></div></div></blockquote><div><br></div><div>Maybe this one? <a href="https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-creation" target="_blank">https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-creation</a><br></div><div><br></div><div>When you create a DLL on Windows, the linker produces two files. One is a .dll file and the other is a .lib file. The DLL file contains actual code and dynamically linked to an executable. The LIB file is an archive file that contains fake object files for each exported symbols, each of which explains an exported symbol. When you link your program against a DLL, you don't directly link against a DLL. Instead, you need to pass a .lib file that corresponds to a desired .dll file.</div><div><br></div><div>That way, Windows SDKs don't have to include actual DLL files if you just want to allow linking against DLLs. (Of course you need actual DLLs to run your program though.)</div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></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"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </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"><div class="gmail_quote"><div>I don't see a point of generalizing it. Isn't it just a Mach-O only thing? If (1) is not true, then maybe we should generalize it, so I think you need to show evidences that we need a text-based ELF stub format.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Sep 26, 2018 at 2:42 PM Steven Wu <<a href="mailto:stevenwu@apple.com" target="_blank">stevenwu@apple.com</a>> wrote:<br>
><br>
> Hi Armando<br>
><br>
> Thanks for the detailed RFC and all the background research. I think the concept is good and I will be happy to work with you to integrate the ELF implementation with Apple's MachO implementation and contribute it upstream. Do you have any proposal on how to integrate with Apple's tapi and how should we collaborate?<br>
><br>
> Also, Apple's tapi does more than just stubbing. Are you interested to add ELF support for other features as well? (I guess it should not be too hard to do that).<br>
><br>
> Thanks<br>
><br>
> Steven<br>
><br>
> > On Sep 26, 2018, at 8:29 AM, Armando Montanez via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > Hello all,<br>
> ><br>
> > LLVM-TAPI seeks to decouple the necessary link-time information for a<br>
> > dynamic shared object from the implementation of the runtime object.<br>
> > This process will be referred to as dynamic shared object (DSO)<br>
> > stubbing throughout this proposal. A number of projects have<br>
> > implemented their own versions of shared object stubbing for a variety<br>
> > of reasons related to improving the overall linking experience. This<br>
> > functionality is absent from LLVM despite how close the practice is to<br>
> > LLVM’s domain. The goal of this project would be to produce a library<br>
> > for LLVM that not only provides a means for DSO stubbing, but also<br>
> > gives meaningful insight into the contents of these stubs and how they<br>
> > change. I’ve collected a few example instances of object stubbing as<br>
> > part of larger tools and the key benefits that resulted from them:<br>
> ><br>
> > - Apple’s TAPI [1]: Stubbing used to reduce SDK size and improve build times.<br>
> > - Oracle’s Solaris OS linker [2]: Stubbing used to improve build<br>
> > times, and improve robustness of build system (against dependency<br>
> > cycles and race conditions).<br>
> > - Google’s Bazel [3]: Stubbing used to improve build times.<br>
> > - Google’s Fuchsia [4] [5]: Stubbing used to improve build times.<br>
> > - Android NDK: Stubbing used to reduce size of native sdk, control<br>
> > exported symbols, and improve build times.<br>
> ><br>
> > Somewhat tangentially, a tool called libabigail [6] provides utilities<br>
> > for tracking changes relevant to ELF files in a meaningful way. One of<br>
> > libabigai’s tools provides very detailed textual XML representations<br>
> > of objects, which is especially useful in the absence of a preexisting<br>
> > textual representation of shared objects’ exposed interfaces. Glibc<br>
> > [7] and libc++ [8] have made an effort to address this in their own<br>
> > ways by using scripts to produce textual representations of object<br>
> > interfaces. This functionality makes it significantly easier to<br>
> > analyze and control symbol visibility, though the existing solutions<br>
> > are quite bespoke. Controlling these symbols can have an implicit<br>
> > benefit of reducing binary size by pruning visible symbols, but the<br>
> > more critical feature is being able to easily view and edit the<br>
> > exposed symbols in the first place. Using human-readable stubs<br>
> > addresses the issues of DSO analysis and control without requiring<br>
> > highly specialized tools. This does not strive to replace tools<br>
> > altogether; it just makes small tasks significantly more approachable.<br>
> ><br>
> > llvm-tapi would strive to be an intersection between a means to<br>
> > produce and link against stubs, and providing tools that offer more<br>
> > control and insight into the public interfaces of DSOs. More<br>
> > fundamentally, llvm-tapi would introduce a library to generate and<br>
> > ingest human-readable stubs from DSOs to address these issues directly<br>
> > in LLVM. Overall, this idea is most similar to the vein of Apple’s<br>
> > TAPI, as the original TAPI also uses human-readable stubs.<br>
> ><br>
> > In general, llvm-tapi should:<br>
> ><br>
> > 1. Produce human-readable text files from dynamic shared objects that<br>
> > are concise, readable, and contain everything required for linking<br>
> > that can’t be implicitly derived.<br>
> > 2. Produce linkable files from said human readable text files.<br>
> > 3. Provide tools to track and control the exposed interfaces of object files.<br>
> > 4. Integrate well with LLVM’s existing tools.<br>
> > 5. Strive to enable integration of the original TAPI code for Mach-O support.<br>
> ><br>
> > There are a number of key benefits to using stubs and text-based<br>
> > application binary interfaces such as:<br>
> > - Reducing the size of dynamic shared objects used exclusively for linking.<br>
> > - The ability to avoid re-linking an object when its dependencies’<br>
> > exposed interfaces do not change but their implementation does (which<br>
> > happens frequently).<br>
> > - Simplicity of viewing a diff for a changed DSO interface.<br>
> > A large number of other use cases exist; this would open up the floor<br>
> > for a variety of other tools and future work as the concept is rather<br>
> > generic.<br>
> ><br>
> > The proposed YAML format would be analogous to Apple’s .tbd format but<br>
> > differ in a few ways to support ELF object types. An example would be<br>
> > as follows:<br>
> ><br>
> > --- !tapi-tbe-v1<br>
> > soname: someobj.so<br>
> > architecture: aarch64<br>
> > symbols:<br>
> > - name: fish<br>
> >   type: object<br>
> >   size: 48<br>
> > - name: foobar<br>
> >   type: function<br>
> >   warning-text: “deprecated in SOMEOBJ_1.3”<br>
> > - name: printf<br>
> >   type: function<br>
> > - name: rndfunc<br>
> >   type: function<br>
> >   undefined: true<br>
> > ...<br>
> ><br>
> > (Note that this doesn’t account for version sets, but such<br>
> > functionality can be included in a later version.)<br>
> ><br>
> > Most of the fields are self-explanatory, with size not being relevant<br>
> > to function symbols, and warning text being purely optional. One<br>
> > reason this departs from .tbd format is to make diffs much easier:<br>
> > sorting symbols alphabetically on individual lines makes it much more<br>
> > obvious which symbols are added, removed, or modified. Despite the<br>
> > differences, the desire is for llvm-tapi to be structured such that<br>
> > integrating Apple’s Mach-O TAPI will be plausible and welcomed. Prior<br>
> > discussion [9] indicated interest in integrating Apple TAPI into LLVM,<br>
> > so I’d definitely like to leave that door open and encourage that in<br>
> > the future.<br>
> ><br>
> > I feel the best place to start this is as a library to best facilitate<br>
> > integration into other areas of LLVM, later wrapping it in a<br>
> > standalone tool and eventually considering direct integration into<br>
> > LLD. The tool will initially support basic generation of .tbe and stub<br>
> > files from .tbe or ELF. This should give enough functionality for<br>
> > manually checking shared object interface diffs, as well as having<br>
> > access to linkable stubs. The goal is for the tool to eventually<br>
> > provide additional functionality such as compatibility checking, but<br>
> > that’s a ways into the future.shared<br>
> ><br>
> > There’s multiple options for integrating llvm-tapi to work with LLD;<br>
> > LLD could directly use llvm-tapi to produce and ingest .tbe files<br>
> > directly, or llvm-tapi could be used to produce stubs that LLD can be<br>
> > taught to use. From a technical standpoint, these are not mutually<br>
> > exclusive. This step is a ways down the road, but is definitely a<br>
> > high-priority goal.<br>
> ><br>
> > I’m interested to hear your thoughts and feedback on this.<br>
> ><br>
> > Best,<br>
> > Armando<br>
> ><br>
> ><br>
> > [1] <a href="https://github.com/ributzka/tapi" rel="noreferrer" target="_blank">https://github.com/ributzka/tapi</a><br>
> > [2] <a href="https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter2-22.html" rel="noreferrer" target="_blank">https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter2-22.html</a><br>
> > [3] <a href="https://docs.bazel.build/versions/master/user-manual.html#flag--interface_shared_objects" rel="noreferrer" target="_blank">https://docs.bazel.build/versions/master/user-manual.html#flag--interface_shared_objects</a><br>
> > [4] <a href="https://fuchsia.googlesource.com/zircon/+/master/scripts/shlib-symbols" rel="noreferrer" target="_blank">https://fuchsia.googlesource.com/zircon/+/master/scripts/shlib-symbols</a><br>
> > [5] <a href="https://fuchsia.googlesource.com/zircon/+/master/scripts/dso-abi.h" rel="noreferrer" target="_blank">https://fuchsia.googlesource.com/zircon/+/master/scripts/dso-abi.h</a><br>
> > [6] <a href="https://sourceware.org/libabigail/" rel="noreferrer" target="_blank">https://sourceware.org/libabigail/</a><br>
> > [7] <a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/abilist.awk;h=bad7c3807e478e50e63c3834aa8969214bdd6f63;hb=HEAD" rel="noreferrer" target="_blank">https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/abilist.awk;h=bad7c3807e478e50e63c3834aa8969214bdd6f63;hb=HEAD</a><br>
> > [8] <a href="https://github.com/llvm-mirror/libcxx/blob/master/utils/sym_extract.py" rel="noreferrer" target="_blank">https://github.com/llvm-mirror/libcxx/blob/master/utils/sym_extract.py</a><br>
> > [9] <a href="http://lists.llvm.org/pipermail/cfe-dev/2018-April/thread.html#57576" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2018-April/thread.html#57576</a><br>
> > _______________________________________________<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>
><br>
_______________________________________________<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></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></div></div></div>
</blockquote></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></div>