[llvm-dev] contributing llvm-lipo

[Jake Ehrlich via llvm-dev]

A) It sounds like you're pretty sure that llvm-objcopy style code could be
correctly reused here. Assuming that's the case this is probably not the
ideal option

B) This is something we want to do anyway and sounds like the most ideal
solution assuming llvm-objcopy style code is compatible

C) I have no ideas here

D) This seems strictly less ideal than B but, assuming this tool would
still fit generally into llvm-objcopy's general library format it would be
better than A. It sounds like the CopyConfig and all that logic is the
killer here. We could generalize all of that yet further but...yeah that
sounds like a losing battle and not as ideal than B.

An important thing to point out is that to proceed we *only* have to move
the MachO code into a library and we can follow up with the ELF code later
like we planned to anyway. I think that 1) goes in the correct direction
and 2) has virtually no overhead.


On Thu, May 9, 2019 at 4:22 PM Alexander Shaposhnikov <
alexander.v.shaposhnikov at gmail.com> wrote:

> Hey everyone!
> In October/November 2018 I started the implementation of llvm-objcopy for
> MachO with the long-term plan to build some popular binary-level tools on
> top of it. That effort stopped at the stage where some boilerplate code for
> reading/writing MachO files was reviewed & committed to
> LLVM/tools/llvm-objcopy.
>
> Later I started working on llvm-lipo (a drop-in replacing for the tool
> "lipo" for manipulating "fat" binaries), but that code has never been sent
> for code review. The original plan was to use the approach similar to
> llvm-strip, where the new tool is just another "driver" for llvm-objcopy.
> This approach worked well for llvm-strip (the command line interface of
> llvm-strip maps naturally onto the interface of llvm-objcopy) but turned
> out to be not flexible enough for llvm-lipo. The thing is that the tool
> lipo doesn't work "per object file", instead, it can have multiple input
> files & single output file, no output files at all, etc.
>
> So below is the proposal / request for suggestions how to move forward
> from here. It seems to me it might be a good time to try to factor out the
> reusable part of llvm-objcopy's codebase and build a library from it. At
> the beginning the library can contain : Reader + Object + Writer (for all
> the supported formats: ELF/COFF/MachO) and all the tool's specific logic
> will stay in place. There are several questions: what would be a good name
> for it and how would we want to organize the codebase.
>
> Some options which I can imagine:
>
> A) Leave the code where it is right now, create a library from it,
> put llvm-lipo.cpp into the folder llvm/tools/llvm-objcopy
>
> B) Move the code which belongs to the library
> out of the folder llvm/tools/llvm-objcopy
> and create a new folder llvm/tools/llvm-lipo for the lipo-specific code.
>
> C) Something else ?
>
> D) /* personally don't like */ Try to go with the approach when llvm-lipo
> is a symbolic link to llvm-objcopy. This kind of bloats the codebase of
> llvm-objcopy,
> I don't see many benefits on this path except some space savings.
>
> Any thoughts/suggestions/comments would be appreciated.
>
> Kind regards,
> Alex Shaposhnikov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190509/9e648583/attachment.html>