[llvm-dev] Extending llvm-objcopy to support COFF

[James Henderson via llvm-dev]

Hi,

It's not clear to me what you mean by CLI "subcommands". Would you mind
giving a brief example?

Up to now, we've been trying to keep llvm-objcopy as close as possible to
GNU objcopy, to make transitioning between them easier (I'm thinking in
particular things like DWO generation). There are a small number of edge
cases/unusual behaviours that we have chosen not to support whilst doing
this. I guess the obvious question from me is do we need the same drop-in
replacement for COFF support?

Also, Jake has just posted up a fairly major refactor of the existing
command-line interface on Phabricator:

https://reviews.llvm.org/D44236

I don't know how your proposal would interact with this, but if the
approach we're looking at taking looks like this would just make life
harder, please shout!

James

On 7 March 2018 at 20:34, Saleem Abdulrasool via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On Wed, Mar 7, 2018 at 9:56 AM Eric Christopher via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Zach!
>>
>> I've been thinking a bit about this for a while now and I'm still of two
>> opinions:
>>
>> On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Currently llvm-objcopy only supports ELF files, and most of it's command
>>> line flags are ELF / DWARF specific that don't make any sense on COFF
>>> files.  So a useful set of options for COFF would be largely disjoint, with
>>> maybe 1-2 overlapping options.  What would be the best way to add this in
>>> llvm-objcopy?  I can think of 3 options:
>>>
>>> 1) Re-write the existing CLI of llvm-objcopy to use subcommands, and put
>>> the current set of options behind an ELF subcommand.  To me this is the
>>> cleanest approach, but it's also the most disruptive, as existing users of
>>> llvm-objcopy would have to retrain themselves to use this new subcommand,
>>> and tools / scripts may have to be updated as wells.
>>>
>>>
>> I really like this option. I like orderly commands and having an ELF
>> subcommand is really nice, however...
>>
>>
>
> While this is tempting, I don’t think that we can break compatibility with
> existing tools as it is intended to be a replacement.  However, we could do
> something like we did with readobj and readelf.  Note that the obj copy
> from binutils also works with COFF, so that should be supported too.
>
> 2) Throw in all of the COFF options to the current llvm-objcopy, and just
>>> have them be mixed with the ELF options.  I think this makes the tool more
>>> difficult to use and more confusing, but it is admittedly the simplest
>>> approach.
>>>
>>>
>> This is the sort of thing that people expect from using gnu objcopy and
>> so I'm reticent to have a tool with no way to get the "command line
>> expected syntax".
>>
>> Mostly what I want is 1 with a shim that gets me 2.
>>
>> Thoughts?
>>
>
> I think we are thinking more or less the same thing.
>
>
>> -eric
>>
>>
>>> 3) Make a new tool called llvm-coffcopy / llvm-objcopy-coff, or
>>> something to that effect.
>>>
>>> Anyone have any thoughts or strong preferences?
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
> _______________________________________________
> 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/20180308/761424e1/attachment.html>