llvm dev - Mar 2018 - Extending llvm-objcopy to support COFF

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.

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.

3) Make a new tool called llvm-coffcopy / llvm-objcopy-coff, or something
to that effect.

Anyone have any thoughts or strong preferences?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180307/d9eb6ec3/attachment.html>

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...

> 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?

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

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