[Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Tue Mar 1 08:06:48 PST 2016

I think there's a lot of value in having lldb's help output and cl syntax
match all of the other llvm tools that people are already familiar with.
Simplicity through consistency. So lgtm
On Tue, Mar 1, 2016 at 4:22 AM Pavel Labath <labath at google.com> wrote:

> labath added a comment.
> In http://reviews.llvm.org/D17724#364450, @clayborg wrote:
> > As long as both long and short options are still supported? Can you
> still type any of:
> >
> > - --arch=x86_64
> > - --arch x86_64
> > - -arch=x86_64
> > - -arch x86_64
> > - -ax86_64
> > - -a x86_64
> All the variants work (including -a=x86_64) **except** the "-ax86_64"
> version. Not sure if it's that important to maintain this one.
> > Are we able to track which options can be used with other options with
> the llvm solution? I didn't look too close. There were bits in the old
> option definitions which defined with options could be specified with which
> other options.
> These bits were there, but they weren't used for any verification
> purposes, only for formatting the `--help` output, which I did not find
> altogether useful anyway, as it has too many options and variants (some of
> which are wrong).
>   lldb -h
>   lldb -v [[--] <PROGRAM-ARG-1> [<PROGRAM_ARG-2> ...]]
>   lldb -a <arch> -f <filename> [-c <filename>] [-s <filename>] [-o <none>]
> [-S <filename>] [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x]
> [-X] [-l <script-language>] [-d] [[--] <PROGRAM-ARG-1> [<PROGRAM_ARG-2>
> ...]]
>   lldb -n <process-name> -w [-s <filename>] [-o <none>] [-S <filename>]
> [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l
> <script-language>] [-d]
>   lldb -p <pid> [-s <filename>] [-o <none>] [-S <filename>] [-O <none>]
> [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l <script-language>]
> [-d]
>   lldb -P
>   lldb -r [<none>] -R <none>
> We can't get llvm to produce this kind of output for us, but we can use
> "option categories". By default, we have "general" and "generic" categories
> ( :P ), but I was thinking about adding a "repl" category (for --repl,
> --repl-language) and a "scripting category" (all --source and --one-line
> options, --batch, etc.). IMHO, this would help the output readability more
> than the previous "option sets" variant.
> This would not help the enforcement of option combinations in a
> declarative manner, but as we have introspection, it wouldn't be too hard
> to express "no option from the 'repl' category can be used with other
> options" with a bit of code.
> > The other thing that might throw people for a loop is if llvm doesn't
> support this style:
> >
> > % lldb /bin/ls --arch=x86_64 -- -lAF
> This works as expected.
> So, yes, there are tiny regressions, but these are not important IMO, and
> I think this makes a nice code simplification. However, if I'm not
> interested in shoving this in if people don't approve, so... let me know
> what you think
> http://reviews.llvm.org/D17724
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160301/552dbcbc/attachment.html>

More information about the lldb-commits mailing list