bobajeff 25 days ago

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.

  • godzie 25 days ago

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

otherayden 25 days ago

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

meisel 25 days ago

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

bfrog 25 days ago

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 :)

giancarlostoro 25 days ago

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

  • rob74 24 days ago

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

godzie 25 days ago

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/

gitroom 25 days ago

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

  • dathinab 24 days ago

    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.

lostmsu 21 days ago

What's the state of expression evaluation?

thurn 24 days ago

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

  • godzie 24 days ago

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

sixthDot 25 days ago

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

  • godzie 25 days ago

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

    • harpiaharpyja 23 days ago

      Would DAP support allow this to be used with OpenOCD?