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 <pa...@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 <clayb...@gmail.com >>> <mailto:clayb...@gmail.com>> wrote: >>> >>> >>> >>>> On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev >>>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
