Show HN: BugStalker - a modern Rust debugger | Hacker News Reader

Show HN: BugStalker - a modern Rust debugger

github.com

115 pointsgodzie17 comments

Does this have a machine interface mode like gdb/lldb? Asking because I like my debuggers to be integrated with my code editor of choice which is usually done via such an interface.

Unfortunately no, but it's a good idea. I'll definitely look into this feature.

Best of luck with this project. I'm not even a rust dev but I came to say that I love this name

I’m surprised this isn’t getting more love. My experience with other debuggers with Rust was quite poor, I hope this one can fare much better. For example, I couldn’t call functions with previous debuggers

Been hoping someone would make this, looks great!

I guess I’m next hoping someone gets it working using jtag/swd debug probes for embedded targets :)

Would something like this work for you? https://probe.rs/

BugStomper would have also been a great name choice. ;)

Better than the current one - first, stalking is not really a verb that comes to mind when I think about bugs, and second, it has pretty negative connotations...

BS is a modern debugger for Linux x86-64. Written in Rust for Rust programs.

Async Rust support – debug async code with new commands: - async backtrace – inspect async task backtraces - async task – view task details - async stepover / async stepout – better control over async execution

Enhanced variable inspection: - argd / vard – print variables and arguments using Debug trait

Other: - new `call` Command – execute functions directly in the debugged program - `trigger` Command – fine-grained control over breakpoints - new project Website – better docs and resources

…and much more!

Full Changelog: https://github.com/godzie44/BugStalker/releases/tag/v0.3.0

Documentation & Demos: https://godzie44.github.io/BugStalker/

Honestly this wouldve helped me a ton when I got stuck with async errors before, Rust debugging always felt tougher than it should be.

yeah I mean you are basically stuck with a few options

- use C/C++ focused debugers with a rust plugin or similar (okay, not not compared to idk. debugging python in PyStorm)

- rely on tracing/logging and errors reported (which might sound dump as it's basically "not" debugging, but with how the rust type system plays out and enforcement of reasonable decent code style/structure etc. this is quite often good enough)

- write/extend tests (again a form of "not" debugging, but where while a "must have" even if you pinned down the bug using a debugger)

- sprinkle in dbg! statements (basically print line debugging)

The fact that it took like 10? yearts for anyone to write more then just tweeks to C/C++ debuggers even through rust has a lot of enthusiasts is I think telling ;)

Still it looks like a real nice tool to have in your toolbox.

What's the state of expression evaluation?

is this necessarily linux for dependency reasons, or could it be on OSX in the future?

Yes, I think it's possible to support macOS. However, the main challenge isn't the operating system itself but rather the architecture.

any Machine Interface planned (à la GDB/MI)?

First priority is a DAP support. But after this - why not.

Would DAP support allow this to be used with OpenOCD?

Reply on news.ycombinator.com