Command Aliases

I’d really like to add aliases for the following commands from gdb:

info b[reak] ; breakpoint list
info ar[gs] ; frame variable
info lo[cals] ; frame variable --no-args
info r[egisters] ; info registers
info al[l-registers] ; info all-registers $rax $rcx
info all-registers rax rsp ; register read rax rsp
info sh[ared] ; image list
info sy[mbol] 0x1234 ; image lookup --address 0x1234

These all have spaces in them, which I believe means they won’t work with the existing alias system. Would it make the most sense to add a new “CommandObjectMultiwordInfo” object in the Command Interpreter and break all the info stuff out there, or is it feasible to add the ability to recognize multiword aliases so something like this would work:

command alias “info break” breakpoint list

Also, it appears that command regex commands don’t show up in help -a. See example down below. Is this expected behavior?

(lldb) help command regex

(lldb) command regex f s/^$/finish/ ‘s/([0-9]+)/frame select %1/’

(lldb) command regex f s/^$/finish/ ‘s/([0-9]+)/frame select %1/’
(lldb) help -a

expression – Evaluate a C/ObjC/C++ expression in the current program context, using user defined variables and variables currently in scope.
f –
frame – A set of commands for operating on the current thread’s frames.

(lldb) help f
This command takes ‘raw’ input (no need to quote stuff).

Syntax: f

‘f’ is an abbreviation for ‘f’

Just write a new python command and name it "info". Then re-route as needed under the covers.

Two points from the peanut gallery

1) You won't be the only one wanting this - /* wtf they reinvented the wheel here... */
Multiword alias is one way to solve it - another might be a gdb-compat mode

2) Having a gdb compatible interface means being able to run the gdb testsuite - which afaik has a much superior DWARF testsuite than what's currently available to lldb

I'd really like to add aliases for the following commands from gdb:

Two points from the peanut gallery

1) You won't be the only one wanting this - /* wtf they reinvented the wheel here... */
Multiword alias is one way to solve it - another might be a gdb-compat mode

2) Having a gdb compatible interface means being able to run the gdb testsuite - which afaik has a much superior DWARF testsuite than what's currently available to lldb

Remember that a gdb compatibility mode sufficient for usefully running the gdb testsuite would mean compatibility in the details of the output printing, not just the command input. Even when working in gdb itself, you have to be very careful touching anything that affects output or you will cause massive testsuite failures (I speak from experience...) Implementing this in lldb would not be a simple task. The amount of effort it would require would be much more productively spent adding test cases to the extant test suite.


Hey Micheal,
while I don’t think we are going to accept in mainline a builtin “info” command like the one you suggested, this kind of idea seems to lead to a promising path for making tools out of which this kind of facility could then be manually crafted by users for all sorts of multiword commands.

It sounds like we need general facilities for multiword commands definition by users. Something like

(lldb) command multiword add info

And then you should be able to tell any command-defining command (e.g. command script add, command alias, command regex) that whatever command it is crafting, it is actually a subcommand, e.g.

(lldb) command alias —subcommand info — break breakpoint list

That would cause a hierarchy to be created where there is a multiword “info” command at the root, with a break subcommand, whose implementation is breakpoint list

—— break ==> breakpoint list

With that, you could easily define your info command hierarchy in your .lldbinit and anyone who wants to define their own multiword commands hierarchies would naturally be allowed to do so.

Needless to say, one should protect system commands, such that you could not say

(lldb) command alias —subcommand process doevilthings “some other command here"


(lldb) command multiword add process

or worse

(lldb) command multiword delete process

Right now our story here is fairly lacking (you can define python commands that then can “fake” multiwordedness), so if you want to work on this kind of proper multiword support, that would be great!

Enrico Granata
:envelope_with_arrow: egranata@.com
:phone: 27683

I speak from experience as well - I know precisely what you're talking about, but is it really *that* bad? It's too bad this couldn't have been a goal from the start. c'est la vie

You might want to check out Greg Parker's gdb-compatability .lldbinit file with a big honkin' regex alias to handle many of the info commands you're talking about:

Hi Michael,

I recommend this way also. Actually, we have already done this thing
for our GUI for lldb. It is not hard at all.


I’m in a room with several folks that work on Linux and Mac. One of the major complaints with lldb is the command syntax when switching between the two debuggers. Currently, everyone prefers the gdb syntax. I’m sure a large part of that is due to knowing gdb after using it for so long, but also because some of the commands are much simpler. “ptype Point” vs. “image lookup --type Point”, “info symbol 0x1234” vs. “image lookup --address 0x1234”, etc. I’m sure there are other folks dealing with this issue when they move to lldb from gdb, and there appear to be several gdb → lldb aliases already built into lldb - I assume to help with this. So instead of having several different people each trying to solve this for themselves with local python scripts or init files and all the issues that come along with those, I was thinking it would useful to get some more gdb commands it into lldb. Ie, ones like “info” that are fairly simple and don’t interfere with existing lldb commands. But we’ll take a look at the .lldbinit file Jason mailed, python scripts, and if those don’t work for us I’ll investigate Enrico’s multiword commands idea and possible local lldb modifications.


We intentionally did not simply reproduce the gdb command set because while it does some common things in a very compact way, it has limited discoverability, and is hard to extend. The irregularity of the commands also makes it hard to provide good help & command completion. So the philosophy we took with lldb was to provide a logical command structure that used options explicitly, making it easy to combine them in complex ways and allowing the command completion to figure out what all the tokens should be, etc. While hard-core gdb fans were not fond of this decision, I have also heard from quite a number of folks that they appreciate the more regular and logical ordering of the commands.

Of course, we knew that that design would make very common commands awkward, so we built in a fairly powerful alias mechanism and added built in aliases for very common commands. These look like gdb commands on purpose, but somebody coming from another debugger could easily remove these and make up an accelerated command set they are comfortable with.

However, one other way to make command entry simple is to use the shortest unique completion for commands. So for instance, while having the command called "image look --type Point" makes it really clear what the command does (and makes it easy to provide a way to limit your type search), once you've used the command a few times, you'll probably end up typing:

(lldb) i loo -t Whatever


(lldb) i<TAB>loo<TAB>-t Whatever

In this case, it is unfortunate we couldn't think up a better word for "image load" since that makes us type three characters for "lookup", but since this is not such a common command clarity won over brevity... But as that instance illustrates, it is also important to leave as much of the command space clear in the basic installation so we don't make folks type more than they need to to get to commands, particularly any aliases they want to make for themselves. For instance, adding "info" to the base command set would mean that I would now have to type "im" not "i" for image lookup. So we try to avoid that sort of thing, especially if all it does is allow another way to get at extant commands.

As you are discovering, the alias mechanism (and the even more powerful one for Python command extensions) is not completely done yet. We need to add support for multi-word commands in the alias mechanism, Enrico's suggestion seems like a good one for that, and the Python command registration needs to be able to describe the command being added to the command interpreter so that we can do the parsing and command completion for it, making these commands equals to the built-in ones. That would be great work to have done if somebody has a little spare time on their hands...

Similarly, if somebody/somebodies who are so motivated want to come up with a more complete set of gdb aliases, it would be fine to include the results of that labor in the examples directory in the lldb sources for all to share. That way people who wanted to could easily include them, but we wouldn't litter the "first couple characters" command space for the common user.