<div dir="ltr"><div dir="ltr">On Mon, Jul 5, 2021 at 9:43 AM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 7/2/21 10:14 AM, Fāng-ruì Sòng via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">llvm/tools/ include some binary utilities used as
replacement for GNU binutils, e.g. llvm-objcopy,
llvm-symbolizer, llvm-nm.<br>
In some old threads people discussed some drawbacks of using
cl::opt for user-facing utilities (I cannot find them now).<br>
Switching to OptTable is an appealing solution. I have prepared
two patches for two binary utilities: llvm-nm and llvm-strings.<br>
<br>
* llvm-strings <a href="https://reviews.llvm.org/D104889" target="_blank">https://reviews.llvm.org/D104889</a><br>
* llvm-nm <a href="https://reviews.llvm.org/D105330" target="_blank">https://reviews.llvm.org/D105330</a><br>
<br>
llvm-symbolizer was switched last year. llvm-objdump was
switched by thakis earlier this year.<br>
<br>
The switch can fix some corners with
lib/Support/CommandLine.cpp. Here is a summary:<br>
<br>
* -t=d is removed (equal sign after a short option). Use -t d
instead.<br>
* --demangle=0 (=0 to disable a boolean option) is removed. Omit
the option or use --no-demangle instead.<br>
</div>
</blockquote>
<p>To me, removing these would make the interface *worse*. This is
purely subjective, but I use the second item regularly when
locally debugging to swap back and forth between two modes
easily</p></div></blockquote><div>See Medhi's message: "I think part of the confusion on my side in this thread is that when I read "binary utilities" I thought first and foremost about `opt` and `lld`, while you're using "binary utilities" to refer to what I would call "end-user tools". I agree with you that tools like clang and lld are in a different category than `opt`."</div><div><br></div><div>The proposal is for llvm-{ar,cov,cxxfilt,nm,objcopy,objdump,readobj,size,strings,symbolizer}. The options mostly follow GNU, with a few LLVM extensions. There are really few options which default to true and may be toggled by users to false. When they have toggles, there are `--no-*` options.</div><div><br></div><div>It's not like opt or llc where you need something like -enable-new-pm=0 or -enable-lto-internalization=0</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>* To support boolean options (e.g. --demangle
--no-demangle), we don't need to compare their positions (if
(NoDemangle.getPosition() > Demangle.getPosition()) , see
llvm-nm.cpp)</p><blockquote type="cite"><div dir="ltr">
* grouped short options can be specified with one line
`setGroupedShortOptions`, instead of adding cl::Grouping to
every short options.<br>
* We don't need to add cl::cat to every option and call
`HideUnrelatedOptions` to hide unrelated options from --help.
The issue would happen with cl::opt tools if linker garbage
collection is disabled or libLLVM-13git.so is used. (See <a href="https://reviews.llvm.org/D104363" target="_blank">https://reviews.llvm.org/D104363</a>)<br>
* If we decide to support binary utility multiplexting (<a href="https://reviews.llvm.org/D104686" target="_blank">https://reviews.llvm.org/D104686</a>),
we will not get conflicting options. An option may have
different meanings in different utilities (especially for
one-letter options).<br>
<br>
<b>I expect that most users will not observe any difference.</b><br>
<br>
There is a related topic whether we should disallow the
single-dash `-long-option` form.<br>
(Discussed in 2019: <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-April/131786.html" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2019-April/131786.html</a>
Accept --long-option but not -long-option for llvm binary
utilities)<br>
<b>I'd like to disallow -long-option but may want to do this in
a separate change.</b><br>
The main point is that (1) grouped short options have syntax
conflict with one-dash long options. (2) the GNU getopt_long
style two-dash long option is much more popular.<br>
<br>
I can think of potential pushback for some Mach-O specific
options, e.g. nm -arch<br>
<a href="http://www.manpagez.com/man/1/nm/osx-10.12.6.php" target="_blank">http://www.manpagez.com/man/1/nm/osx-10.12.6.php</a>
says `-arch` has one dash.<br>
If such options may have problems, we can keep supporting one
dash forms.<br>
With OptTable, allowing one-dash forms for a specific option is
easy.<br>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">宋方睿</div></div></div>