teemperor added a comment. In D61737#1497785 <https://reviews.llvm.org/D61737#1497785>, @kwk wrote:
> 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 agree, but that doesn't solve the problem with e.g. `-x` that is already occupied by LLDB but with a different meaning that in GDB. If we add a bunch of GDB options we also create the expectation that LLDB just accepts GDB flags which is as discussed not really possible. I think some form of gdb-mode/wrapper is the cleanest option for compatibility with tooling and advanced users (and it seems to be the consensus in this review). And for just making the first time lldb user experience smoother, I think adding `--args` seems like a good compromise. It's probably the first flag people throw at GDB and LLDB and doesn't seem too out of place when we add it. > I would also like to mark the driver parameters in the help to underline that > they are there for compatibility. Yeah, If we land this I would also put them in some option group "GDB Compatibility" like the REPL or SCRIPTING groups we already have. > @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. I don't think IDE's are supposed to invoke the normal lldb driver (see lldb-mi or the SB* API). And if they use the normal lldb CLI, then they probably expect more GDB similarities like identical commands, identical stdout output format, etc. 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
