Tag: debugger

We are working towards creating a modular, composable, and modern debugger library for Rust, and this month there has been a lot of exciting progress thanks to our supporters and contributors.

We have extended core functionality, implementing important debugger features such as stack unwinding (which is necessary for displaying backtraces), reading of local variables, and disassembly view.

mozilla/rr is an excellent record/replay debugger written in C/C++.

Over the last few months I've been working on porting rr to the Rust programming language. The port is still in-progress but many things work already.

The project is called "The Record and Debug tool" or "rd" for short. The repo is available on GitHub. It already has 30k+ lines of ported over Rust code.

I was somewhat inspired by the technical discussion in a mozilla/rr ticket about porting rr to Rust even though at that point in time, I was not really a fan of the Rust programming language (though I am now!)

I hope to write a longer post about my experiences while porting rr to Rust. For today I just want to share some of the reasons why I embarked on this journey.

About 3 weeks ago, we started a new project to create a new modular and composable debugger library for Rust, taking inspiration from projects such as Delve and MDB. In less than 4 weeks, we have already seen some exciting progress!

In my previous article, I argued for a case of extending the existing debuggers to provide better support for Rust. However, after some more research and thinking, I feel that we should consider the idea of creating a new debugger framework from scratch, taking inspiration from other great projects. Not-invented-here syndrome aside, I think there are some valid reasons for going in this direction.

Recently, there has been a lot of progress in the Rust logging & tracing ecosystem: projects like tracing make our lives much simpler, allowing us to track down bugs even in complex asynchronous environments in production. However, they still can’t replace interactive debuggers like gdb or lldb, which provide so much more than just stack traces and variables printing.

In an ideal world, you can use your debugger as a read-eval-print loop, writing, rewriting, and testing entire functions in an interactive session. Techniques like post-mortem debugging make it possible to prod dead processes, providing immeasurable help in understanding the state of a program just before it crashed. But the harsh reality is that debuggers can be counter-intuituve, hard to use, or just suck, and it’s doubly challenging for Rust.

It's been a while since I’ve posted about debugging rust, we’ve come a long way since 2017 and I wanted to do an update on getting set up for Rust Debugging.

Last time, I wrote about how to configure VS Code to debug Rust Cortex-M programs, but you know what's better than writing documentation for how to do a thing?

Automating it.

I'm very happy to announce my PR to add a basic debug configuration for VS Code has been merged into the cortex-m-quickstart template. VS Code is now supported out of the box when you cargo generate a new project. When I say "out of the box", I really mean "out of the box". I've also added a QEMU configuration, so you can go experiment with debugging embedded Rust with VS Code right now, without any additional hardware.

IntelliJ CLion is still leading the way for advanced refactoring and polish, but as you may know I’ve been banging on about the need for decent debuggers for Rust for years. I’m happy to say in 2020 that a good debugging experience is now available through VSCode. (Hopefully Clion will raise their debugging game)