uscope (pronounced "microscope") is a new graphical debugger for Linux. Its goal is to enable you to understand what your system is actually doing as quickly and effectively as possible.

All debugging-related code is written from scratch, i.e. parsing ELF/DWARF, handling control of the subordinate process (launch, kill, step, continue, etc.), reading data from the subordinate's memory/registers and displaying it in a user-friendly manner, stack unwinding, etc.

Here's a screenshot of the debugger stopped in a simple zig program that just prints out a bunch of basic variables. You can see that a fair number of table-stakes debugger features have already been implemented, but there's still a ton more to do!

I feel strongly that the state of the art for introspection tooling needs to improve, particularly on Linux. Figuring out what your program is doing (often called observability) is a critical aspect of developing all modern software, whether it's a command line application, giant distributed system, video game, database, and so on. There are loads of graphical debuggers that are powerful and fast to use on Windows, but it's a missing piece of the puzzle on Linux.

Fundamentally, it is the process of collecting data, possibly transforming or aggregating it, then visualizing it to bring light to something you didn't previously understand. This feedback loop needs to be easy and fast for developers, and unfortunately, the existing tools are not good enough.

The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible.

Consequently, most Linux devs I know don't use a debugger and instead just printf-debug, which is often the correct choice because what's the point of a debugger that doesn't save you time? We've got to improve the situation because without a great debugger, our software quality suffers and it takes longer to deliver.

It's very early days now and it's going to be a while before it's usable as a daily driver. The table-stakes debugger features are off to a good start, but there's still a long way to go.

Currently, only C and Zig have any shot of being debugged nicely, but support for more languages is coming. Support for other platforms (at least macOS and Windows) is also planned, but very far off. There's more detail on specific features I want to implement in the README.

The debugger collects data from various sources (currently mostly ptrace), transforms those raw bytes to a common data format, then provides that to a UI for visualization. Both the backend (data collection) and frontend (data visualization) will be hackable and extensible.

For instance, I work on chess engines for a living, and it would be pretty slick if I had a debugger that understood my exact data layout and automatically rendered an interactive chessboard when I want to inspect a variable that contains a bitboard for a position. The possibilities are limitless for bespoke debug tooling for your specific problem domain once we have a simple, extensible toolkit to work with.

Reach out! We've got a Discord, and my personal email is jim at this domain. I love talking debug tooling.

Contributions are absolutely welcome, though I'd recommend reaching out before tackling a large chunk of work to make sure we're on the same page and effort isn't wasted.

You could also consider sponsoring my work. This is a very strong signal to me that I'm on the right track.