similar to: [RFC] Open sourcing and contributing TAPI back to the LLVM community

Hi Juergen, At a minimum I think adding the support to libobject, etc so the various llvm tools can read or even write files from/for OSX should be fairly non-controversial so how about go ahead and do that first (I'll happily review if you'd like) and then we can go from there to do anything else with TAPI and llvm? Sound good? -eric On Thu, Sep 7, 2017 at 5:01 PM Juergen Ributzka via

Great to hear, thanks! On Thu, Sep 20, 2018 at 1:56 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > A member of my team +Armando Montanez <amontanez at google.com> is going to > drop a proposal for the ELF part of this soon (like sometime next week) and > will be working on the implementation. I'll be one of the reviewers for > anything that comes out of that so

Was there any progress in the upstreaming effort? I'd be interested in having lld be able to link against tbd files, and I think it'd be cool if libtool -static could write tbd files (similar to thin archives on linux) since that should make archiving much faster. Juergen, maybe uploading your initial patch to phabricator instead of attaching might get more traction? On Wed, Apr 25, 2018

That sounds great to me, thanks Jake. I'm not Jurgen either, of course, but I'm happy to assist you if he is unavailable. I'm not also not qualified to audit the license, but do note Apple formally also released some code at https://opensource.apple.com/tarballs/tapi/. If there's anything else I can do to help, let me know. Cheers, John On 04/10/2018 06:13 PM, Jake Ehrlich

On Mon, Apr 9, 2018 at 10:11 PM, John Ericson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > 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 like there are a few of us interested in this then. I new around here and don't really know how decisions are made, so what's next? Just open a diff with the entire library?? John On 04/10/2018 05:33 PM, Jake Ehrlich wrote: > Benifits of TBD: > 1) It's human readable and diffs on TBDs correspond to changes in the > ABI. Diffs can be automatically added to review

I'm not really clear on the actual benefits of the TBD file, and why Apple migrated to them in the first place. Shouldn't a dynamic library containing only the relevant parts (e.g. the dynamic symbol table) be roughly comparable in size? And, much simpler to support? I assume that's effectively what "Mach-O Dynamic Library Stubs" actually _were_, before the introduction of

Benifits of TBD: 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. 2) The size is smaller which means they can be shipped in an SDK instead of binaries to reduce the size of an SDK 3) Stubs are producible from TBDs (or should be)

Ideally Jurgen would cut up the code on github, put up an initial diff for a minimal viable tool, and then we would review it and then continue to copy code from the github repo into llvm and review it. I'm also willing to do that if Jurgen doesn't want to at this point though. I'd like the OK from Jurgen on that and I'd also like the OK from someone that the license stuff is all

Adding Juergen to the thread. On Fri, Mar 15, 2019, 12:20 PM Shoaib Meenai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Ping. > > > > Would anyone be opposed to me trying to revive the in-tree Mach-O TAPI > code? > > > > Thanks, > > Shoaib > > > > *From: *Shoaib Meenai <smeenai at fb.com> > *Date: *Wednesday, March 6, 2019 at

Hi all, It looks like Juergen landed the TextAPI libraries for Mach-O in https://reviews.llvm.org/D53945, and also had several follow-ups, but then it was deleted entirely by r347874. I'm not sure if the entire deletion was intentional, since the commit message only mentions reverting a certain series of patches; CC Hans. In any case, I'm wondering if there are plans to revive it, since

Hi Paul, My experience has shown the same when it comes to header files and I am not claiming this is going to work out of the box for all library projects. It usually requires some cleanup first and that is why the tool comes with a verification mode to make sure the headers are the truth. Also keep in mind that you don't have to parse all the headers, but only the small set that get

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

Hello all, LLVM-TAPI seeks to decouple the necessary link-time information for a dynamic shared object from the implementation of the runtime object. This process will be referred to as dynamic shared object (DSO) stubbing throughout this proposal. A number of projects have implemented their own versions of shared object stubbing for a variety of reasons related to improving the overall linking

Since the goal is to start llvm-tapi more or less from scratch, I feel the best approach initially is to focus on the structure as a key point of feedback in initial reviews. Once the foundations are set, integrating Mach-O TAPI in parallel with the ELF implementation should be relatively straightforward. The features outside of stubbing aren't as appealing for ELF, so I probably won't be

On Tue, Apr 10, 2018 at 5:33 PM Jake Ehrlich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Benifits of TBD: > 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. > 2) The size is smaller which means

Oof, I didn't think about Clang not being in the same place. Perhaps we could put this in clang-tools-extra to solve that? As for the unification of the code bases. I was assuming we didn't want to just throw a ton of code over the wall anyway so the merge was going to need to be reviewed chunk by chunk anyhow. Support for the two formats should be possible to add in parallel (although, I

> On Apr 9, 2018, at 3:23 PM, James Y Knight via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I'm not really clear on the actual benefits of the TBD file, and why Apple migrated to them in the first place. Shouldn't a dynamic library containing only the relevant parts (e.g. the dynamic symbol table) be roughly comparable in size? And, much simpler to support? I assume

On Thu, Sep 27, 2018 at 3:12 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Sep 27, 2018 at 2:42 PM Armando Montanez via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Since the goal is to start llvm-tapi more or less from scratch, I feel >> the best approach initially is to focus on the structure as a key >> point of

Right. Usually you wouldn't want to write a .tbe from scratch, but for the sake of linking against a DSO you might only have access to a .tbe stub that was produced from the DSO. This specific functionality becomes critical when DSOs only used for linking are replaced entirely by .tbe stubs because at a SDK level the complete DSO isn't needed. This is what Apple has done to significantly