[lldb-dev] Break setting aliases...

[Jim Ingham via lldb-dev]

> On Jul 22, 2020, at 12:34 AM, Pavel Labath <pavel at labath.sk> wrote:
> 
> I use "b" for file+line breakpoints and "br set -n" for function
> breakpoints, mainly because I couldn't be bothered to figure out how
> that works with the "b" command. Now that I have studied the command
> once again, I may try using it for function breakpoints as well...
> 
> I don't have any hard objections to new aliases (if "b" for name
> breakpoints doesn't pan out, I may start using "bn" as a shorthand for
> "br set -n"), though I do find the idea of beefing up the "b" command
> more appealing.
> 
> On 22/07/2020 00:03, Jim Ingham via lldb-dev wrote:
>> 
>> 
>>> On Jul 21, 2020, at 2:54 PM, Greg Clayton <clayborg at gmail.com
>>> <mailto:clayborg at gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev
>>>> <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>>> 
>>>> When we were first devising commands for lldb, we tried to be really
>>>> parsimonious with the one & two letter unique command strings that
>>>> lldb ships with by default.  I was trying to leave us as much
>>>> flexibility as possible as we evolved, and I also wanted to make sure
>>>> we weren’t taking up all the convenient short commands, leaving a
>>>> cramped space for user aliases.
>>>> 
>>>> The _regex_break command was added (and aliased by default to ‘b’) as
>>>> a way to allow quick access for various common breakpoint setting
>>>> options.  However it suffers from the problem that you can only
>>>> provide the options that are recognized by the _regexp_break command
>>>> aliases.  For instance, you can’t add the -h option to make a
>>>> hardware breakpoint.  Because the “_regex_break command works by
>>>> passing the command through a series of regex’s stopping at the first
>>>> match, trying to extend the regular expressions to also include
>>>> “anything else” while not causing one regex to claim a command that
>>>> was really meant for a regex further on in the series is really tricky.
>>>> 
>>>> That makes it kind of a wall for people.  As soon as you need to do
>>>> anything it doesn’t support you have to go to a command that is not
>>>> known to you (since “b” isn’t related to “break set” in any way that
>>>> a normal user can actually see.)
>>>> 
>>>> However, lldb has been around for a while and we only have two unique
>>>> commands of the form “b[A-Za-z]” in the current lldb command set (br
>>>> and bt).  So I think it would be okay for us to take up a few more
>>>> second letter commands to make setting breakpoints more convenient.
>>>>  I think adding:
>>>> 
>>>> bs (break source) -> break set -y
>>> 
>>> Is -y a new option you would add? I don't see it. We have --file and
>>> --line
>> 
>> Added it yesterday.
>> 
>>> 
>>>> ba (break address) -> break set -a
>>>> bn (break name) -> break set -n
>>>> 
>>>> would provide a convenient way to set the most common classes of
>>>> breakpoints while not precluding access to all the other options
>>>> available to “break set”.  We could still leave “b” by itself for the
>>>> _regex_break command - people who’ve figured out it’s intricacies
>>>> shouldn’t lose their investment.  This would be purely additive.
>>>> 
>>>> What do people think?
>>> 
>>> Can we modify the _regex_break to accept options at the start or end
>>> of the command somehow? 
>>> 
>> 
>> When the principle of so much of the rest of the lldb command line is
>> that this sort of positional ordering is NOT necessary, doing this would
>> be a shame.  At that point, I think Jonas suggestion of having a command
>>  “break break-spec-set” or whatever, that took the breakpoint modify
>> option group and then a specifier as an argument(s) which get parsed in
>> the same way that “_regexp_break” does would be a better long-term
>> supportable option.
> 
> 
> Couldn't we have "b" command work the same way as the "expr" command? If
> the user passes no arguments then he can just do "b whatever". And if he
> also wants to add any parameters then he can do "b --hardware -- whatever".
> 
> The "--" is slightly unfortunate, but it's at least consistent with our
> other commands taking raw input. We could avoid that by making the
> command not take raw input. I think most of the "modes" of the "b"
> command wouldn't need quoting in most circumstances -- source regex and
> "lib`func" modes being exceptions.

If anybody wants to work on this, I think Jonas is right, the first step would be to convert it to an actual command not a regex command.  The _regexp-break command is already hard enough to comprehend.

You could still do the actual specifier parsing with a series of regex’s if that seems best, though there might be easier ways to do it.  I also don’t think this would need to be a raw command, rather it could be a parsed command with one argument which was the breakpoint specifier and then all the other breakpoint flags.  

All the specifications you can currently pass to b are single words w/o spaces in them, or if they do have spaces they are the things you are used to having to quote in lldb: like file names with spaces.  I don’t think anybody would mind having to do:

b “file with spaces.c:12”

or 

b “+[ObjCClass selector]”

since they have to do that pretty much everywhere else in lldb.

The “b -“ thingie that Dave pointed out is the exception to this, but it would also be unnecessary, since all the other flags would be straightforwardly available.

> 
> On 21/07/2020 20:13, Jonas Devlieghere via lldb-dev wrote:
>> Furthermore, with a first-class command we can do a better job on the
> help front which is really underwhelming for _regexp_break command aliases.
> 
> FWIW, this is the first time that I looked at the help for the "b"
> command, and I have to say I found it more understandable than the "br
> set" command. :P
> 
> "br set" help starts with a long list command switches, which are
> supposed to show which options can be used together. I think this sort
> of listing is nice when the command has a couple of modes and a few
> switches, but it really misses the mark when it ends up listing 11 modes
> with approximately 20 switches in each one.
> 
> This is then followed by descriptions of the 20 or so switches. This
> list is alphabetical, which means the most commonly used options end up
> burried between the switches I've never even used.

Yes.  I’ve said many times before that making “break set” the master command for breakpoint setting was a mistake.  I didn’t expect we’d come up with so many useful breakpoint types, each with some common and some independent (or even overlapping) options.  It would have been much better to have done:

break set file
break set name
break set address

etc - with a separate subcommand per primary.  

This would actually have taken one less letter to type (“b s n” rather than “b s -n”) and make it easier to document the function of the command and its options.  For instance when -n is the primary, it means “function on which to set a breakpoint”, but when specified along with -p as the primary, it means “function in which to search for the source pattern”.  Right now you either have to make very verbose help strings or leave these distinctions to be guessed.  But set up as subcommands, -n would only exist for “break set source-regex” and could be properly documented there.

I think cutting over from the current command to ones arranged like this would be too disruptive, but it might okay to make a “break set2” that follows this pattern.  Then we could still support people with scripts that did “break set -n” or whatever, but have a way to switch over to the new one with a little notice.

Jim


> 
> OTOH, "help b" gives me a reminder of the types of breakpoints I can set
> and an example for how to set them. That is what I need most of the
> time. The thing I maybe find missing there (and what might also help
> folks needing to switch to more powerful "br set") is if each of the
> "modes" of the "b" command also listed the equivalent "br set" command.
> 
> pl