[lldb-dev] Break setting aliases...

[Greg Clayton via lldb-dev]

BTW: to see what things expand to after reach regex alias, just set this setting first:

(lldb) settings set interpreter.expand-regex-aliases true

Each time you type "b main" it will show you the expansion:

(lldb) b main
breakpoint set --name 'main'
...
(lldb) b main.cpp:12
breakpoint set --file 'main.cpp' --line 12
...

It shows the full expansion.

Greg

> 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.
> 
> 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