This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Make short options mandatory for all options
Changes PlannedPublic

Authored by teemperor on Nov 12 2020, 12:26 PM.

Details

Summary

LLDB identifies all command options via their short option character (e.g. 'c' for the '-c' option).
We have 3 options that apparently don't have a short option and only a long option, so for
those we are using 4 chars that we store in an int and identify the option based on that.
This also the reason why we store the short option character as an int in most of the code
as we might also have one of those 4-character strings packed inside an integer.

It doesn't seem that really works as we apparently not all code is aware that the character is
sometimes also a 4-byte string, so that's why we have these random short options sometimes:

(lldb) target var -
Available completions:
	-e -- A basename or fullpath to a file that contains global variables. This option can be specified multiple times.
	-b -- A basename or fullpath to a shared library to use in the search for global variables. This option can be specified multiple times.

The e and b are actually just the truncated last part of this 4-byte strings file and shlb that were used for these options.
These two short options also appear to be not usable:

(lldb) target variable -e asdf
error: invalid option with value '101'

We could fix this, but this patch is instead just giving the three options a short character and removes the whole
'4-byte strings in an int' from the code base. We anyway have a few places where people accidentially used 'char'
to store the value, and that silently transforms these options into the short option of the last character ('file' -> '-e').

The added short options are:
target variable --file -> -l (F and f were already occupied).
target variable --shlib -> -S (s was already occupied)
Some commands such as memory read have a --append-outfile option, which is now aliased to -a.

Diff Detail

Event Timeline

teemperor requested review of this revision.Nov 12 2020, 12:26 PM
teemperor created this revision.
teemperor added a reviewer: labath.

You can Ctrl+F for SHORT_OPTION_ to see the changes to the changed short options (beside all the int -> char replacement).

teemperor planned changes to this revision.Nov 12 2020, 12:29 PM

Actually the char changes related to val aren't in scope for this patch, I should remove those.

Well... I'd say this is a step in the wrong direction. :(

Some of our commands are very baroque, and finding a meaningful short letter for their options can be really hard. target variable --file is actually a very good example for that, but there are more (e.g. the minidump dumping options).

I think we should just accept the fact that some options are just not important enough to deserve a short form -- all they would do is prevent that letter to be taken by some other, perhaps more useful, option. And it's easier to add a short option (if the option turns out to be useful) than it is to remove/change it. Also, tab completion makes it less important to have a very short way to spell something.

I'd much rather move in the other direction, actually. :) I.e., try to incentivise people to *not* add short form for every new option they come up with. Currently, the way to avoid a short option is really unobvious and most people are unaware of it. The fact that we use short letters to identify options is to blame. This is a consequence of us using getopt, but it's not even an inherent getopt thing -- it supports other ways to signal that a long option was parsed besides returning a character (int). It's just that we chose not to use that. In any case, the fact that we have a getopt wrapper means that we can hide all of this stuff, and present any interface we want...

For now though, I'd just settle for fixing the short option bug at hand. I am not particularly troubled by the fact that some code holds these options as chars. The generic code needs to be aware of the ints, of course, but this can be ensured by proper tests. And for the option-specific code, they only need to care about this if they actually make use of the functionality....