Does this work with Rust?

[BatmanAoD]

The Rust language provides a script for setting up LLDB to debug Rust programs.

Do you expect this plugin to work out-of-the-box for Rust, and if not, do you have any idea how difficult it would be to make use of that rust-lldb script or merge the logic into the plugin itself?

(Sorry for not just trying this out on my own machine; looks like it requires a bit too much setup for something I might not actually be able to use yet, and in any case I'm on Windows at the moment.)

[idanarye]

I just tried it on a Rust project with GDB and it just worked. As for LLDB, I had to run :VBGcontinue after launching the debugger - apparently it got in a breakpoint somewhere in the runtime or something. Maybe that script could fix it?

@IngoHeimbach - is it simple for users to use that script with your lldb_wrapper.py? How is it done?

[IngoHeimbach]

I had a look at the rust lldb setup script. LLDB is called with the --source-before-file option to run these lldb commands before the debugging executable is loaded:

command script import "$RUSTC_SYSROOT/lib/rustlib/etc/lldb_rust_formatters.py"
type summary add --no-value --python-function lldb_rust_formatters.print_val -x ".*" --category Rust
type category enable Rust

Currently, this is not supported by lldb_wrapper.py since it the debugging executable is loaded directly after entering lldb (and I don't know if it can be implemented with the Python wrapper at all). However, this lldb command block could be sent to lldb after loading the executable (for example with VBGrawWrite). If that works, I could add the block to lldb initialization commands whenever a Rust file is opened.

[BatmanAoD]

Where is the wrapper? It doesn't look like it's part of this project.

[IngoHeimbach]

The Python binding is part of LLDB, so it should already be installed on your system. The file lldb_wrapper.py in this project uses the LLDB Python binding to provide an interface which can be used easily by vim-vebugger.

[BatmanAoD]

Curses, GitHub's search capabilities have failed me! Sorry for the dumb question.

[idanarye]

OK, I tested that script, and :VBGcontinue has nothing to do with it - the reason I had to do it is that Vebugger automatically sets a breakpoint on main, and apparently there is another main at play here. Not sure why GDB doesn't have that problem... At any rate, Vebugger 2.0 will not set a breakpoint automatically, so this should be solved once I get around to work on it (probably after the sun become a red giant but hopefully before the heat death of the universe)

It looks like the script mainly has to do with formatting, and since :VBGeval does not currently handle very well multiline formatted values, you may be better off with the default formatting...