kwk added a comment. In D61737#1497202 <https://reviews.llvm.org/D61737#1497202>, @jingham wrote:
> I would rather not clutter up the lldb command driver's options with gdb > command flags. That seems like it will make lldb harder to figure out and > reduce our freedom to choose reasonable short names for lldb driver options. It is good to have this discussion early on and that is exactly why I've picked this little example option `-ex` in the first place. I was about to add more options/flags/parameters that borrow from GDB. Another reason why I *just* want to add more GDB commands instead of introducing a *GDB mode* is because I don't want to make a false promise. I'd rather try to bring a lot of commands from GDB over and if one is missing, that's fine because it might not be used that often. But if we have a switch to the `lldb` binary that means we promise something that we don't keep. In essence I rather like a soft-gdb-mode in GDB just by *accidentally* allowing for the same commands *and* CLI arguments than a hard-gdb-mode. I would also like to mark the driver parameters in the help to underline that they are there for compatibility. @jingham : what is worse, not having the freedom to re-use a shortcode or keeping users away? Surely this is a provocative question but my point is that the whole point is to make LLDB more appealing as an option for an alternative debugger to GDB. > It was reasonable to add lldb aliases for the gdb commands that you use tens > to hundreds of times in a give debugging session - those get wired into your > hands... But I don't think the same consideration holds for command line > options... Well, true the commands in a debugging session are harder to remember and I will for sure tackle commands in the future but from a user's or IDE's point of view, starting the debugger comes first. Especially the IDE view on things might be worth considering here. Users can adapt but probably not all Debuggers inside of IDEs can that easily. > If we feel the need to add a driver gdb compatibility mode like this, I like > Rafael's suggestion of: > > lldb --gdb <everything after this is handled by our gdb emulation parser> This makes things much more complicated than it needs to be and puts us in a bad position because we then always promise to keep up with GDBs commands somehow. As I've mentioned before, I rather want to accidentally *bridge* the ease of adoption. Let's not put too much hurdles in a user's way just in order to get going with lldb. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61737/new/ https://reviews.llvm.org/D61737 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
