jakehehrlich added a comment. To be clear I'm only really giving my thumbs up to a specific high level plan that I believe handles a case that llvm-elfabi wouldn't otherwise handle on its own. I consider the specifics like the output format still in the air right now. I strongly believe that a unique yaml or json format should be used for this. We should discuss the specifics of what should go in that format and have a discussion on that format. The trick is to capture everything in .o files that could wind up mattering to a .tbe file and nothing more. I haven't thought though what that entails completely yet but I'll think about it and throw up my proposal. Once we have at least one proposal we can start iterating on the specifics of it.
Here's the plan I think we can converge which at least covers all of my concerns: 1. A flag is added to clang that would cause clang to emit a pre-merged format and not invoke the backend 2. The pre-merged format can then be merged into a stub or .tbe file as part of the same binary (but an effectively different tool since a symlink and options parser will be used instead) as llvm-elfabi 3. The yaml code for this format will go in llvm so that both clang and the new merging tool could use it 4. We need to discuss the specifics of the pre-merged format to ensure that it captures everything that matters (and hopefully nothing more) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60974/new/ https://reviews.llvm.org/D60974 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
