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

Mon Nov 5 15:42:48 PST 2018

A long time back, I had a discussion with Chandler about cl::opt, and one of the concerns we had at the time about replacing it all with libOption was that the table gen based options are a bit heavy handed for some of the simpler tools.

The idea Chandler had back at the time was to have libOption support a simplified interface for programmatically defining options (something similar to Python's argparse).

That would make it easy to create small lightweight tools with only a few options and get rid of cl::opt except for as a vehicle for debug options.

-Chris

> On Oct 31, 2018, at 8:51 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I wish we could migrate all of llvm away from cl::opt to be honest.  The big missing feature is subcommands (which sadly I take the blame for, since I implemented it in cl::opt), which I guess needs to be implemented in lib/Option before we can port everything away from cl::opt.
> 
> On Wed, Oct 31, 2018 at 6:20 AM whitequark via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> -- 
> whitequark
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181105/165b34d5/attachment.html>