jingham added a comment. In D61737#1498329 <https://reviews.llvm.org/D61737#1498329>, @jankratochvil wrote:
> In D61737#1498297 <https://reviews.llvm.org/D61737#1498297>, @jingham wrote: > > > 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. 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
