Thanks for laying this out.  I don't think any of us have a brief for getopt, 
it was the tool at hand.  Getting some fuzzy match suggestions would be nice.

Your comment about getopts reminds me, a more fundamental problem with lldb's 
command interpreter is that the CommandObject is stateful.  So you can't 
actually call a command and then in the process of handling that command call 
back into the same command without destroying the options settings from the 
older invocation.  We actually do this  (e.g. anything that hits a breakpoint 
can call arbitrary lldb commands).  We just luck out because most commands grab 
their arguments, decide what to do with them, then do the work.  So the second 
invocation overwrites options that aren't going to get reused.  But working by 
luck is never good...

It would be much better to separate the Command definition part of the 
CommandObject from the Invocation part, so that one command definition could 
server multiple invocations.  If somebody has ambition to dig into lldb's 
command interpreter, I'd propose this task over replacing something that works 
with something else that works more nicely.


> On Feb 12, 2018, at 2:31 AM, Pavel Labath via Phabricator 
> <> wrote:
> labath added a comment.
> There are several components in the "command line parsing"
> 1. argparse: parsing a single string into the individual words (processing 
> quotes, backslashes, etc.)
> 2. resolving the "command" part of the command line (the "frame variable" 
> part of "frame variable --raw-output FOO")
> 3. resolving the arguments of a command (the "--raw-output FOO" part)
> These parts compose quite nicely, and can be individually replaced. I'll 
> briefly speak about each one :
> (1) is very specific to our interactive use case (for command line utilities, 
> the shell/os does the parsing for us). There also isn't anything nearly 
> similar in llvm (afaik).
> (2) is also quite specific to how lldb commands are structured, and there 
> also isn't a suitable llvm replacement. This is the level at which the 
> "command aliases" are resolved.
> (3) is a fairly generic piece of functionality -- we even implement it by 
> delegating to getopt (in a scarily un-thread-safe way). For this there are 
> *two* competing implementations in llvm: `llvm::cl` and `llvm::opt`. Of these 
> the first one is not suitable for our use case right now as it relies on 
> global variables. Making it work probably would be a bit or work. However, 
> using the second one should be fairly easy, and it should be generic-enough 
> (it's the thing that handles crazy gcc command lines).
> The reason I'm spelling it out this way is because I think you were mostly 
> talking about (3), but some of the difficulties Jim pointed out (command 
> aliases) just aren't relevant there.  I don't think llvm::opt handles 
> "shortest match" options yet, but that should be fairly easy to add.  On the 
> flip side, the library has recently gained argument suggestion capabilities 
> (`error: unknown argument '-gllbb', did you mean '-glldb'`), so we would get 
> that for free. Making sure tab completion works there would require a bit of 
> thought, but I think this should not interfere with this library too much 
> (after all, we use getopt now, and it does not support tab completion either).
> Repository:
>  rL LLVM

lldb-commits mailing list

Reply via email to