<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/5/21 10:14 AM, Fāng-ruì Sòng
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFP8O3JsKktC_SNfxHkO281qRn6B8qTE=hCVJ2doWMwni0nsVA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Mon, Jul 5, 2021 at 9:43 AM Philip Reames <<a
href="mailto:listmail@philipreames.com"
moz-do-not-send="true">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" moz-do-not-send="true">https://reviews.llvm.org/D104889</a><br>
* llvm-nm <a href="https://reviews.llvm.org/D105330"
target="_blank" moz-do-not-send="true">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>
</div>
</blockquote>
You're right, I had missed that, and it completely resolves my
concern. Sorry for the noise. <br>
<blockquote type="cite"
cite="mid:CAFP8O3JsKktC_SNfxHkO281qRn6B8qTE=hCVJ2doWMwni0nsVA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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" moz-do-not-send="true">https://reviews.llvm.org/D104363</a>)<br>
* If we decide to support binary utility multiplexting
(<a href="https://reviews.llvm.org/D104686"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" moz-do-not-send="true">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>
</blockquote>
</body>
</html>