[lldb-dev] Break setting aliases...

[Pavel Labath via lldb-dev]

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.

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.

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