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

whitequark via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 31 06:20:35 PDT 2018

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

More information about the llvm-dev mailing list