[llvm-dev] Migrating llvm-objdump and a few other common binutils replacements away from llvm::cl.

[whitequark via llvm-dev]

On 2018-10-31 10:21, James Henderson via llvm-dev wrote:
> I like this proposal, personally. I'm not too familiar with the
> command-line stuff, but my experience is that seeing options relating
> to the LLVM backend in binary dumping and manipulation tools seems a
> bit weird.

I second this! I am very much looking forward to using the llvm-mc tools
as a binutils replacement both in my toolchains and manually, and 
llvm::cl
is not being very cooperative when defining the kind of argument parser
interface this requires.

> 
> This might be out of scope, but specifically regarding llvm-objdump, I
> noted a number of places where the options is MachO specific, and I
> was wondering if we could find a way to keep those options separate
> from the others, to make it more friendly to those who care about only
> ELF, for example.
> 
> On Wed, 31 Oct 2018 at 09:02, Kristina Brooks via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> 
>> Hi,
>> 
>> Just wanted to ask, does anyone have any objections to me working on
>> refactoring
>> a few common LLVM tools (objdump, nm, strings, readobj) to use the
>> new TableGen
>> based option interfaces and submitting a diff for each one? Just
>> wondering if
>> anyone else is currently working on this and so I don't end up doing
>> redundant
>> work as there were a few discussions regarding `llvm::cl` and I
>> think there is
>> a general agreement in that that should be something for LLVM parts
>> to expose
>> various tinkering options, not for handling regular tools.
>> 
>> Especially considering there were a few points raised regarding
>> threading and
>> the global state of these options, I think this is one of the few
>> places I can
>> be useful and address part of the problem by moving those
>> interfaces.
>> 
>> I also want to improve the quality of help for those tools overall
>> to match their
>> GNU counterparts more closely and possibly add options for colorful
>> output where
>> it makes sense and makes it easier to read things like section dumps
>> of ELF objects
>> for example.
>> 
>> Is anyone currently working on this and if not, how does the overall
>> community
>> feel about me approaching those things with differentials on
>> tool-by-tool basis
>> just to improve the overall experience of using those tools (instead
>> of getting
>> a lot of not-so-relevant information from `llvm-objdump --help`)?
>> 
>> Let me know what you think and if someone is already working on some
>> or all o
>> these tools in which case I could perhaps focus on others?
>> 
>> Thank you for your time reading this.
>> - Kristina
>> 
>> _______________________________________________
>> 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

-- 
whitequark