Page MenuHomePhabricator

[lldb] add -ex CLI option as alias to --one-line
AbandonedPublic

Authored by kwk on May 9 2019, 8:40 AM.

Details

Summary

To ease the adoption of LLDB for users coming from GDB, I've added the
command line option -ex to the lldb binary. It is an alias to the
--one-line option which

Tells the debugger to execute this one-line lldb command after any
file provided on the command line has been loaded.

This is probably as close as we can get to gdb's -ex option which
has this documentation:

-ex command

Execute given GDB command.

Event Timeline

kwk created this revision.May 9 2019, 8:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 9 2019, 8:40 AM
kwk edited the summary of this revision. (Show Details)May 9 2019, 8:43 AM
kwk edited the summary of this revision. (Show Details)
JDevlieghere added a reviewer: labath.

Looks good to me. Added some reviewers to make sure everyone is fine with this.

Not sure if I like this change. We don't have single dash flags with multiple characters in LLDB, so this flag looks a bit out of place. And there is the bigger question if we really want to be compatible with the GDB flags (which are already incompatible with the flags LLDB is currently offering). If we really go this way then I would suggest we also add more commonly used GDB flags like --args.

lldb/tools/driver/Options.td
164

Usually alias don't have any motivation/description, so the "This exists just to ease adoption of LLDB for GDB users." isn't really necessary (and just clutters the help page IMHO).

We don't have single dash flags with multiple characters in LLDB

OK, true.

And there is the bigger question if we really want to be compatible with the GDB flags

Then do you prefer lldb --gdb -ex 'b foo' -ex r --args prog arg (like gdb --dbx) or a different binary lldb-gdb -ex 'b foo' -ex r --args prog arg?

If we really go this way then I would suggest we also add more commonly used GDB flags like --args.

Yes, --args is also planned+needed.

If it's just about adding some commonly used GDB flags I'm fine with adding them to the normal LLDB flags. If the plan is to implement most/all of the flags GDB supports, then I would prefer having something like --gdb or lldb-gdb (which seems anyway necessary to resolve the conflicts with the current LLDB flags like -x, -b, -l, etc.).

jingham requested changes to this revision.May 9 2019, 1:29 PM

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 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...

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 revision now requires changes to proceed.May 9 2019, 1:29 PM

Selecting the option parsing mode explicitly sounds like the way to go to me too. I'm wondering if we should call it --driver-mode=gdb to match the equivalent functionality in clang. Having a symlink (lldb-gdb or whatever) which automatically selects "gdb" as the "driver mode" also sounds reasonable.

lldb --gdb <everything after this is handled by our gdb emulation parser>

I wouldn't make this positional because clang's --driver-mode arg also isn't positional (it applies to the whole command line, even args that come before it). Also making this positional would open the door to having both kinds of options present at once, which is going to make parsing a lot more complicated (and it probably wouldn't be a very useful feature anyway).

kwk added a comment.May 10 2019, 12:22 AM

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.

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 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...

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>

Peanut gallery comments :)

Since I've had to deal with some of this from the gnu binutils direction as well. I think if we really want to have a command-line compatibility mode with lldb we should just have a gdb wrapper/shell/parsed option on top of the lldb libraries/binary. Some of this would necessitate better library splitting of lldb to really have a gdb compatible shell on top but it could be done. This isn't quite how we've done it so far in llvm's binutils, but as an aspirational strategy I think we can and should make it work in general. It'll also help drive much cleaner APIs as well since we'll have to implement a few things from different perspectives.

Thoughts?

In D61737#1497785, @kwk 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.

kwk added a comment.May 10 2019, 5:06 AM

@teemperor Do you recommend me to work on support for GDB's --args parameter then and ditch this review?

dxf added a subscriber: dxf.May 10 2019, 10:04 AM

I really don't want to pollute the lldb driver options with gdb equivalents (or really any duplicate spellings of already present functionality). For the lldb command line, I want us to have the freedom to do the best job of making the lldb options consistent and easy to document, understand and use, and adding in random duplicate options from gdb will only make this harder.

If you have simple gdb startup commands then translating them into the lldb way should be straightforward, and the burden of learning how lldb works from the command line for these purposes is just not that great and if you are going to use lldb you should just buck up and browse "lldb --help" a bit... If you have complex gdb command lines, you are going to have to rework them anyway to deal with other differences between lldb and gdb. I don't think mixing the two would add enough value to be worth the uglification. lldb is a different debugger from gdb and I think we should be fine with being that.

As to Eric's point, I don't think you would need to do any refactoring of lldb to create a gdb compatible shell on top of lldb. The SB API's were sufficient to do the gdb-mi mode and should be sufficient for a gdb driver as well. If you wanted to reuse the command parser code to make it run in lldb or gdb mode, that would take a bunch of work! But I think you'd be crazy to do it that way. The two command syntaxes are quite different, and I think you'd cause yourself much more trouble trying to jam the two together than you would gain from code sharing... After all, the gdb command language is pretty much unstructured, and the command line is parsed ad hoc by the command that receives it, so implementing the parser part of gdb would be very little work, and you wouldn't be able to reuse the part of lldb that does structured commands since the gdb ones aren't.

As you got further along in the project, you'd probably have to add a few more customization points to lldb to implement all the gdb features. For instance you'd probably want to be able to implement stop-hooks in something other than the lldb command line commands. But that's all work that we would want to do in lldb anyway and just haven't gotten around to. But you could probably get a pretty long way just on the current SB API's.

Finally, I agree with Raphael about IDE's. There are SB API's to do all the things you can set up with command line options - and if there's anything missing there we can and should add it. So if you want to make an IDE using lldb, you should be using the SB API's. If you are trying to use the same IDE code to drive gdb & lldb you should be using the MI interface, which again can specify everything you need to run a session after you get started so you shouldn't need compatibility with driver options. And if there's spare cycles and desire to support this sort of thing that effort would much better go into supporting the lldb-mi which is currently languishing for lack of maintainers, than in trying to fool an IDE into thinking the lldb and gdb command lines are the same.

If you have simple gdb startup commands then translating them into the lldb way should be straightforward, and the burden of learning how lldb works from the command line for these purposes is just not that great and if you are going to use lldb you should just buck up and browse "lldb --help" a bit... If you have complex gdb command lines, you are going to have to rework them anyway to deal with other differences between lldb and gdb. I don't think mixing the two would add enough value to be worth the uglification.

I use GDB to debug LLDB like: gdb -q -ex 'set break pend on' -ex 'set build-id-verbose 0' -ex 'set env ASAN_OPTIONS=alloc_dealloc_mismatch=0:detect_leaks=0' -ex 'set env LD_PRELOAD=/lib64/libasan.so.5' -ex "set env PYTHONPATH=$PWD/lib64/python2.7/site-packages:$PWD/lib64/python2.7/site-packages/lldb" -ex "set env LD_LIBRARY_PATH=$PWD/lib:$PWD/lib64/python2.7/site-packages/lldb" -iex 'set breakpoint pending on' -iex 'b __sanitizer::internal__exit' -ex 'b lldb_private::Module::ReportError' -ex 'b lldb_private::Host::SystemLog' -ex r -ex 'set scheduler-locking on' --args python ../llvm-git/tools/lldb/test/dotest.py --executable $PWD/bin/lldb -C $PWD/bin/clang --log-success -t ../llvm-git/tools/lldb/packages/Python/lldbsuite/test/ -f HelloWatchpointTestCase.test_hello_watchpoint_using_watchpoint_set_dwarf

I would like to switch one day from GDB to LLDB but so far I soon face some issue why I cannot use LLDB yet. It is usually some Fedora Linux port compatibility problem. It would be nice to just s/gdb/lldb/ for the test without rewriting all the parameters only to find out there is still something remaining to port in LLDB to make the switch possible.

IIUC we should make a new GDB-like driver using liblldb.so+SB API for both GDB commandline parameters and GDB commands compatibility. For the GDB commands interpreter there could be a fallback to forward unknown commands to LLDB interpreter.

If you have simple gdb startup commands then translating them into the lldb way should be straightforward, and the burden of learning how lldb works from the command line for these purposes is just not that great and if you are going to use lldb you should just buck up and browse "lldb --help" a bit... If you have complex gdb command lines, you are going to have to rework them anyway to deal with other differences between lldb and gdb. I don't think mixing the two would add enough value to be worth the uglification.

I use GDB to debug LLDB like: gdb -q -ex 'set break pend on' -ex 'set build-id-verbose 0' -ex 'set env ASAN_OPTIONS=alloc_dealloc_mismatch=0:detect_leaks=0' -ex 'set env LD_PRELOAD=/lib64/libasan.so.5' -ex "set env PYTHONPATH=$PWD/lib64/python2.7/site-packages:$PWD/lib64/python2.7/site-packages/lldb" -ex "set env LD_LIBRARY_PATH=$PWD/lib:$PWD/lib64/python2.7/site-packages/lldb" -iex 'set breakpoint pending on' -iex 'b __sanitizer::internal__exit' -ex 'b lldb_private::Module::ReportError' -ex 'b lldb_private::Host::SystemLog' -ex r -ex 'set scheduler-locking on' --args python ../llvm-git/tools/lldb/test/dotest.py --executable $PWD/bin/lldb -C $PWD/bin/clang --log-success -t ../llvm-git/tools/lldb/packages/Python/lldbsuite/test/ -f HelloWatchpointTestCase.test_hello_watchpoint_using_watchpoint_set_dwarf

This is a good example. Even if we added -ex to mean the same thing as -o, this still wouldn't work because pretty much none of your set commands would work in lldb without modification. So you still would have to port this command to lldb to get it to work, at which point having -ex mean the same as -o wouldn't really have helped you that much...

I would like to switch one day from GDB to LLDB but so far I soon face some issue why I cannot use LLDB yet. It is usually some Fedora Linux port compatibility problem. It would be nice to just s/gdb/lldb/ for the test without rewriting all the parameters only to find out there is still something remaining to port in LLDB to make the switch possible.

IIUC we should make a new GDB-like driver using liblldb.so+SB API for both GDB commandline parameters and GDB commands compatibility. For the GDB commands interpreter there could be a fallback to forward unknown commands to LLDB interpreter.

If someone wants to support this workflow, that would be the way to do it IMO. OTOH, I really don't want to end up again in the situation we are in with the lldb-mi where some folks did a bunch of work to get the basic functionality working, but it wasn't in the main flow of use of lldb, and the original authors lost interest and it isn't quite full-strength (e.g. doesn't work with the emacs MI adaptor) and so we're left with a bunch of unsupported code that almost works and though it would be useful in certain cases it needs work and has flakey tests and nobody is really stepping up to fix things so it ends up being a burden. That just makes lldb look bad.

kwk added a comment.May 16 2019, 1:10 AM

I withdraw from my approach and thanks to @teemperor I have found something else to work on. Thank you for this fruitful discussion.

kwk abandoned this revision.May 16 2019, 1:10 AM