This organization is what I've had in mind for a while. I'd like to see a good proposal for how to reorganize HandleArgs to work for different architectures so that CopyConfig and friends can be shared across different fipe formats. That can be worked out in review though.<div><br></div><div>I'm in full support.<br><div dir="auto"><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 1, 2018, 4:11 PM Alexander Shaposhnikov <<a href="mailto:alexander.v.shaposhnikov@gmail.com">alexander.v.shaposhnikov@gmail.com</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 dir="ltr"><div dir="ltr"><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Hey everyone!</span> Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool.</div><div>Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O binaries this would enable us to build LLVM-based replacements for cctools' install_name_tool (for changing rpath(s), identification name etc) and lipo / libtool (for manipulating "fat" binaries) similarly to how llvm-strip was implemented on top of llvm-objcopy. Regarding the code organization, probably, in this case we will have separate folders: ELF, MachO and maybe a few top-level files (ObjcopyOpts.td, StripOpts.td). A<font color="#000000"><span style="white-space:pre-wrap">ny thoughts, concerns, or strong preferences ? Kind regards, Alex  </span></font></div></div></div></div></div>
</blockquote></div></div></div>