In lldb, one Debugger can debug multiple different processes at a time. This is one of the ways lldb differs from gdb (*)... In lldb, the Target is the entity that represents a thing that you could debug. A Target might or might not actually be debugging anything. If it is, the Target will have a Process. You generally make a target by giving it a file and maybe an architecture. Note the "file" command in lldb is just an alias for "target create". It makes a target out of a file. Then when you want to debug that file, you would say Target::Launch.
But a Target need not have a file. For instance, if you do:
$ lldb --pid 12345
lldb has to make an empty target, attach it to the process with pid 12345, and only then will it actually know what the file is.
Note also, in both lldb and gdb, you can set breakpoints in the .lldbinit/.gdbinit file. But both these init files get read in BEFORE any of the command line arguments (including the one with the file command) get processed.
So there has to be a way to hold onto breakpoints before any target is created. This was simple in gdb since it only supports one target, so you can just stuff the breakpoints into the global list of breakpoint you were going to use. But you can't do that in lldb, because we could have many targets. That's what the lldb "dummy target" is for. It holds onto breakpoints that are made in the absence of any target, and then each time a new target gets made, it gets seeded with breakpoints from the dummy target.
Greg was worried that you could do:
and he wanted to make sure that works. I think that's what you understood as well.
Since the gdb-mi interface models the way gdb works, it really only supports having one target. So I was suggesting that the lldb-mi module keep track of this one privileged Target, and to make sure that -break-set sets breakpoints in the dummy target if that privileged Target is still empty.
(*) one lldb process can also support multiple Debuggers, but that's another story...