<div dir="ltr"><div>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.</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 31 Oct 2018 at 09:02, Kristina Brooks via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Just wanted to ask, does anyone have any objections to me working on refactoring<br>
a few common LLVM tools (objdump, nm, strings, readobj) to use the new TableGen<br>
based option interfaces and submitting a diff for each one? Just wondering if<br>
anyone else is currently working on this and so I don't end up doing redundant<br>
work as there were a few discussions regarding `llvm::cl` and I think there is<br>
a general agreement in that that should be something for LLVM parts to expose<br>
various tinkering options, not for handling regular tools.<br>
<br>
Especially considering there were a few points raised regarding threading and<br>
the global state of these options, I think this is one of the few places I can<br>
be useful and address part of the problem by moving those interfaces.<br>
<br>
I also want to improve the quality of help for those tools overall to match their<br>
GNU counterparts more closely and possibly add options for colorful output where<br>
it makes sense and makes it easier to read things like section dumps of ELF objects<br>
for example.<br>
<br>
Is anyone currently working on this and if not, how does the overall community<br>
feel about me approaching those things with differentials on tool-by-tool basis<br>
just to improve the overall experience of using those tools (instead of getting<br>
a lot of not-so-relevant information from `llvm-objdump --help`)?<br>
<br>
Let me know what you think and if someone is already working on some or all o<br>
these tools in which case I could perhaps focus on others?<br>
<br>
Thank you for your time reading this.<br>
- Kristina<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>