llvm dev - Oct 2018 - Extending llvm-objcopy to support Mach-O

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/8877265f/attachment.html>

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>

It both is and isn't. Looking at expanding and reorganizing the tool is a
good time to move things out to make the overall effort smaller in the
future.

On Tue, Oct 2, 2018, 10:24 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/a02e6019/attachment.html>

Hey, many thanks for the replies,
yeah, in general I agree with what have been said, making a library makes
sense to me, though right now it seems to be non-trivial (to come up with a
good library interface + code reorg) (+ it's not completely but kind of
orthogonal to the proposed Mach-O effort). Probably, as for now I would
prefer to move here step by step with some incremental changes, I'm
planning to start sending patches in this direction soon (within the next
~1-2 weeks) .

On Tue, Oct 2, 2018 at 11:59 AM Eric Christopher <echristo at gmail.com>
wrote:
> It both is and isn't. Looking at expanding and reorganizing the tool is
a
> good time to move things out to make the overall effort smaller in the
> future.
>
> On Tue, Oct 2, 2018, 10:24 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/e1db1217/attachment-0001.html>