<span>I suppose I can take this time to specify which of my mistakes I'd like to see corrected towards the making of this into a library.</span><div><br></div><div>1. Expect/Error instead of hard fail.</div><div>2. As others have stated we should keep section definitions self contained.</div><div>3. Rather than carefully maintaining an order that fragily maintains the init and finalize order there should be a generic dependency manager for this sort of thing. This could also be used for option handling.</div><div>4. Each option should be handled by a single bit of code not by an if statement in giant function.</div><div><br></div><div>With some consideration to the public interface we could make it a library and add unit testing. We could also expose the strip predictes and other details so other tools could know what the final state of an executable would be without actually running objcopy. Things like that.</div><div><br></div><div>I'm hoping to get a good chunk of time to do that in soon. I'll send out a proposal for each but I'd welcome thos contributions.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018, 10:23 AM Jake Ehrlich <<a href="mailto:jakehehrlich@google.com">jakehehrlich@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's something I want to do as well for several reasons. That's an orthogonal issue however.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018, 10:21 AM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@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">I'd give some consideration to moving the objcopy support itself into a library inside llvm (possibly lib/Object as that makes the most sense) and then the tool is just a thin wrapper on top of it.<div><br></div><div>-eric<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 1, 2018 at 4:12 PM Alexander Shaposhnikov 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: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>
_______________________________________________<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>
</blockquote></div>
</blockquote></div></div>