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?
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.
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.
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.
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.
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
By new TableGen based option interface do you mean LLVMOption?
I’m fine with this, although I believe there are currently a few options for how objdump disassembles that are actually llvm::opts defined elsewhere. Those will need to be handled specially.
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.
libOption: use it for when you need to be compatible with a particular command line flag format.
My understanding is taht cl::opt just doesn’t have the fine-grained control needed for a truly production-quality command line interface compatible with some existing tool. I think this is a matter of correctness: is it a requirement to parse the command line options in the same way as some existing program? If so, then cl::opt probably isn’t flexible enough. It may get you 90% of the way there, maybe 95%, but it will probably never truly feel native to users of the tool that it is intended to be compatible with.
GNU objdump does something different for -disassemble vs --disassemble (I have no idea what it is doing; it’s just an example where it does something different). I’m sure there are at least a few other annoying cases like that (not specifically about the number of dashes, but other random weird stuff). I’m not saying the existing GNU objdump behavior is necessarily good, just that if it is a requirement to be compatible, then I think cl::opt just doesn’t cut it.
So from that perspective, I think that moving to libOption instead of cl::opt makes sense for these tools, as I think it is a goal for them to eventually be production-quality drop-in replacements for the existing binutils tools.
(also, btw, you an probably add llvm-ar to your list of tools that need a command-line facelift)