<div dir="ltr">Hi Jake, <div>many thanks,</div><div>yea, I have very similar feelings / thoughts.</div><div><br></div><div>After some thinking it seems to me that this discussion/problem which I have brought up is, in fact, </div><div>more relevant to the tools which really need a robust mutable model of an object file (like objcopy, strip, install_name_tool, etc),</div><div>but the particular case of "lipo" might be simpler, I need to double check that / will take a closer look again.</div><div>What I mean - the tool "lipo" manipulates "fat" binaries by extracting, removing, replacing slices<br></div><div>(slice = object file for a particular architecture),  but the slices themselves are unmodified, thus things can be simpler.</div><div>I'd like to think a bit more about it to make sure I'm not missing anything important here.</div><div><br></div><div>But anyway, I think it's very useful to discuss this problem, many thanks for your comments!</div><div><br></div><div>Kind regards,</div><div>Alex</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 9, 2019 at 4:34 PM Jake Ehrlich <<a href="mailto:jakehehrlich@google.com">jakehehrlich@google.com</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">A) It sounds like you're pretty sure that llvm-objcopy style code could be correctly reused here. Assuming that's the case this is probably not the ideal option<br><br>B) This is something we want to do anyway and sounds like the most ideal solution assuming llvm-objcopy style code is compatible<br><br>C) I have no ideas here<br><br>D) This seems strictly less ideal than B but, assuming this tool would still fit generally into llvm-objcopy's general library format it would be better than A. It sounds like the CopyConfig and all that logic is the killer here. We could generalize all of that yet further but...yeah that sounds like a losing battle and not as ideal than B.<br><br>An important thing to point out is that to proceed we *only* have to move the MachO code into a library and we can follow up with the ELF code later like we planned to anyway. I think that 1) goes in the correct direction and 2) has virtually no overhead.<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 9, 2019 at 4:22 PM Alexander Shaposhnikov <<a href="mailto:alexander.v.shaposhnikov@gmail.com" target="_blank">alexander.v.shaposhnikov@gmail.com</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"><span style="color:rgb(0,0,0);white-space:pre-wrap">Hey everyone!</span> <div>In October/November 2018 I started the implementation of llvm-objcopy for MachO with the long-term plan to build some popular binary-level tools on top of it. That effort stopped at the stage where some boilerplate code for reading/writing MachO files was reviewed & committed to LLVM/tools/llvm-objcopy. </div><div><br></div><div>Later I started working on llvm-lipo (a drop-in replacing for the tool "lipo" for manipulating "fat" binaries), but that code has never been sent for code review. The original plan was to use the approach similar to llvm-strip, where the new tool is just another "driver" for llvm-objcopy. This approach worked well for llvm-strip (the command line interface of llvm-strip maps naturally onto the interface of llvm-objcopy) but turned out to be not flexible enough for llvm-lipo. The thing is that the tool lipo doesn't work "per object file", instead, it can have multiple input files & single output file, no output files at all, etc.  </div><div><br><div>So below is the proposal / request for suggestions how to move forward from here. It seems to me it might be a good time to try to factor out the reusable part of llvm-objcopy's codebase and build a library from it. At the beginning the library can contain : Reader + Object + Writer (for all the supported formats: ELF/COFF/MachO) and all the tool's specific logic will stay in place. There are several questions: what would be a good name for it and how would we want to organize the codebase. </div></div><div><br></div><div>Some options which I can imagine:</div><div><br></div><div>A) Leave the code where it is right now, create a library from it, </div><div>put llvm-lipo.cpp into the folder llvm/tools/llvm-objcopy </div><div><br></div><div><div>B) Move the code which belongs to the library </div><div>out of the folder llvm/tools/llvm-objcopy</div><div>and create a new folder llvm/tools/llvm-lipo for the lipo-specific code.</div></div><div><br></div><div>C) Something else ?</div><div><br></div><div>D) /* personally don't like */ Try to go with the approach when llvm-lipo is a symbolic link to llvm-objcopy. This kind of bloats the codebase of llvm-objcopy,</div><div>I don't see many benefits on this path except some space savings.</div><div><br></div><div>Any thoughts/suggestions/comments would be appreciated.</div><div><br></div><div>Kind regards,</div><div>Alex Shaposhnikov</div><br class="gmail-m_1814265972123665840gmail-m_5520042753523932714gmail-Apple-interchange-newline"></div>
</blockquote></div>
</blockquote></div>