[llvm-dev] Extending llvm-objcopy to support Mach-O

[Jake Ehrlich via llvm-dev]

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.

1. Expect/Error instead of hard fail.
2. As others have stated we should keep section definitions self contained.
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.
4. Each option should be handled by a single bit of code not by an if
statement in giant function.

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.

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.

On Tue, Oct 2, 2018, 10:23 AM Jake Ehrlich <jakehehrlich at google.com> wrote:

> That's something I want to do as well for several reasons. That's an
> orthogonal issue however.
>
> On Tue, Oct 2, 2018, 10:21 AM Eric Christopher <echristo at gmail.com> wrote:
>
>> 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.
>>
>> -eric
>>
>> On Mon, Oct 1, 2018 at 4:12 PM Alexander Shaposhnikov via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hey everyone! 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.
>>> 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). Any thoughts, concerns, or strong
>>> preferences ? Kind regards, Alex
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181002/d8f29b85/attachment.html>