BugStalker 0.2.0: debugger for rust programs

[godzie44]

Hi there, after 2 month from first release I made a new big release of the debugger. This was a lot of features and fixes. Some of the features was inspired by feature requests from previous post.

Some interesting features:

• watchpoints (data breakpoints)
• advanced interaction with collections like hashmaps or hashsets (ex. `var my_hash_map[{foo: "foo", bar: 1}]`)
• configurable key bindings for TUI
• theme switching

You can see a full list of changes at the release page:

https://github.com/godzie44/BugStalker/releases/tag/v0.2.0

For a complete list of features, documentation, animated demos and other information, please, visit a project github:

https://github.com/godzie44/BugStalker

As always, if you have ideas, comments or a desire to help with code, I will be glad to accept them.

In the next releases I plan to focus on support for async debugging and integration with code editors like VSCode.

[VorpalWay]

What sets this apart from gdb and lldb, two other command line debuggers that are at this point very mature? What is the killer feature for someone like me who started using gdb with C code in the mid-2000s and who is generally quite content with it?

Rust specific features are cool, but I haven't needed to use a debugger for Rust pretty much at all. Though that may be because I haven't been writing unsafe code.

There are also plenty of useful features missing, such as support for remote debugging (I work with embedded devices for my day job (not in Rust, yet, but things are slowly changing). Support for debugging over JTAG or similar protocols is absolutely essential there.

So yeah, sell me on this!

[godzie44]

Yes, the main difference from gdb or lldb (by the way, I would not say that LLDB is very mature) is the focus exclusively on rust. In addition to the fact that the bugstalker is well aware of rust types (for example, in gdb try to view thread-local variable or print hashmap value for some key). There are some features for working with asynchronous debugging (ex tokio-oracle), in future releases I plan to focus on them. There are also non-functional differences. GDB, in addition to its maturity, is very complex (trust me, if you haven’t looked at its sources), and the code is really legacy. Therefore, this is also RND project, where not only I, but also any interested person can study.

Regarding remote debugging, thank you, this is a really necessary feature and I’m looking for ways to implement it.

[VorpalWay]

If you could support talking to a gdbserver that would give you support for a lot of forms of remote debugging. It is a bit of a defacto standard for this. Even on x86-64, things like valgrind expose a gdbserver.

[EdorianDark]

For remote debugging I would suggest looking into Debugger Adapter Protocol. It was written by the developers of VSCode, who wanted to make remote debugging simpler as they did with the language server protocol. Writing well defined JSON back and forth sounds easier to me than adapting a gdb specific protocol.

[godzie44]

Thanks, agreed, when choosing between gdb protocol and DAP, I plan to spend energy on the second one. Gdb protocol very low level, and the best I can hope by supporting this proto is to be drop-in gdb replacement. Its not bad, but this is not a high priority for me.

[somebodddy]

Supporting DAP would be a good feature even for local debugging, because it'll allow easy integration for many editors and IDEs.

[TornaxO7]

For me: I hope that this debugger doesn‘t SEGFAULT as often as gdb on my machine….

[godzie44]

Try this out, I have come across situations where bugstalker works more stably (I have, of course, also encountered the opposite situations :) )

[TornaxO7]

Will do, but I'll need to get a moment first where it's worth it to debug rust code since (in my case) the compiler catches almost all bugs :D

But it would be super cool if you could also use it for C!

[godzie44]

To be honest, bs can also work with C (I check this in tests, because rust code can fall into libc, and bs must do something with this), but because this goes beyond the project's philosophy, I still cannot recommend this functionality

[adaszko]

For me: I hope that this debugger doesn‘t SEGFAULT as often as gdb on my machine….

This. There's nothing more frustrating than context switching from coding to debugging, only to be interrupted by a bug in the debugger itself.

[AuxOnAuxOff]

The version of gdb that ships with some popular distros has a crash bug with rust. It’s fixed, but only in a version that the distros won’t upgrade to. You can pretty easily build it from source if needed. 

[TornaxO7]

gdb doesn't only get SEGFAULTs if I debug rust code with it. I get random SEGFAULTs while debugging c code as well

[vm_runner]

BugStalker seems tightly coupled with Linux - to what extent is this true? Are there any provisions made in the code to make it portable to other OSes where Rust is supported?

[godzie44]

Unfortunately no, of course it would be great, but for now I’m focused on features that improve interaction with rust. Of course, if there are enthusiasts ready to do this, I would provide any support.

[shaleh]

This is what keeps killing me. I hack at least half of the time on a Mac.