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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181001/d9662e09/attachment.html>

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.

I'm in full support.

On Mon, Oct 1, 2018, 4:11 PM Alexander Shaposhnikov <
alexander.v.shaposhnikov at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181001/4e640195/attachment.html>

This sounds reasonable to me. I have no objection on this being
pursued currently. I may have some comments about the design once we
have a first version of a patch up for review, though, as it'll be
easier to visualise.

James
On Tue, 2 Oct 2018 at 00:27, Jake Ehrlich <jakehehrlich at google.com>
wrote:
>
> 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.
>
> I'm in full support.
>
> On Mon, Oct 1, 2018, 4:11 PM Alexander Shaposhnikov
<alexander.v.shaposhnikov at gmail.com> 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

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/98b9658d/attachment.html>

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>

On Mon, 1 Oct 2018, Alexander Shaposhnikov via llvm-dev wrote:
> Currently, llvm-objcopy only supports ELF files while binutils' objcopy
can
> handle Mach-O files as well.
binutils' objcopy also supports COFF
> Any thoughts, concerns, or strong preferences ?
No particular, except that I'm considering having a go at starting to 
implement COFF codepaths for this as well (mainly for a strip tool, and 
for the --only-keep-debug and --add-gnu-debuglink actions). I might (no 
guarantees though) start working on that within a few months, unless 
there's already someone else working on that. (I remember seeing some 
other discussions about that but nothing that ever made it into patches.)

// Martin