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

[Michael Spencer via llvm-dev]

On Wed, Oct 31, 2018 at 2:02 AM 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
>

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.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181101/9be803e7/attachment.html>