A debugger for Linux. Partially inspired by RemedyBG.
Mom, can we have RAD Debugger on Linux?
No, we have debugger at home.
Debugger at home:
Properties:
- Fast.
- TUI.
- Not based on gdb or lldb, implemented mostly from scratch.
- Works on large executables. (Tested mostly on 2.5 GB ClickHouse.)
What we mean by “fast”:
- Operations that can be instantaneous should be instantaneous. I.e. snappy UI, no random freezes, no long waits.
(Known exception: if the program has >~2k threads things become pretty slow. This will be improved.) - Operations that can’t be instantaneous (loading debug info, searching for functions and types) should be reasonably efficient, multi-threaded, asynchronous, cancellable, and have progress bars.
Limitations:
- Linux only
- x86 only
- 64-bit only
- for native code only (e.g. C++ or Rust, not Java or Python)
- TUI only (no REPL, no GUI)
- no remote debugging (but works fine over ssh)
- single process (doesn’t follow forks)
- no record/replay or backwards stepping
Development status:
- Most standard debugger features are there. E.g. breakpoints, conditional breakpoints (but no data breakpoints yet), stepping, showing code and disassembly, watch expressions, builtin pretty-printers for most of C++ and Rust standard library. Many quality-of-life features are there (e.g. auto-downcasting abstract cl
21 Comments
dec0dedab0de
I don't work with anything that would need this, but I love TUIs so I checked it out and saw this bit:
Operations that can't be instantaneous (loading debug info, searching for functions and types) should be reasonably efficient, multi-threaded, asynchronous, cancellable, and have progress bars.
I wish this were more common, especially the progress bars thing.
jmclnx
Looks very nice, will need to give it a spin :)
trollbridge
Awesome work. Reminds me of CodeView back in the day, which I've been wishing I could have back since, and no, a gigantic pile of Emacs or vim plugins is not the equivalent.
jebarker
This is nice. I want something like this for python that I can use on remote servers and compute nodes of clusters. I've tried pudb but I find it doesn't behave well with terminal resizing and I wish the interface was a little more configurable.
alfanick
Sideline question: how do you end up with 2.5GB binary (ClickHouse as given in the readme)?
dvektor
Very cool! I have been using LLDB quite a bit lately so I am eager to try this out. The state of debuggers dev experience really hasn't caught up to what things like Cargo have done for build systems, so I am glad to see people working on things like this.
hippospark
For those interested in writing a debugger:
There are a series of tutorials on how to write a debugger from scratch
for Windows x86-64 using Rust [1].
Additionally, there is a book titled "Building a Debugger – Write a Native x64 Debugger From Scratch" by Sy Brand [2].
[^1]: https://www.timdbg.com/posts/writing-a-debugger-from-scratch…
[^2]: https://nostarch.com/building-a-debugger
FpUser
It looks very useful. I will definitely test it. Thank you for such contribution.
Zambyte
Cool :D anyone get a chance to try this out with Zig yet?
colesantiago
How does one install this?
I don't want to go through the curl | bash either for security reasons.
It would be nice to have some package manager support, but it looks cool.
Keyframe
great! I already gave up on RemedyBG or RAD/Epic debugger ever on linux to happen.
theoperagoer
Very cool. How many architectures do you support?
philsnow
GDB already has a TUI.. it's pretty "vintage" though. I looked at the screenshot at the top of the repo README and it looks like it has a lot more creature comforts (read: any at all compared to GDB).
danhau
Cool! Looks like the btop of debuggers. That‘s certainly a tool I would love to have.
deagle50
the macOS drought continues
fcoury
Is there anything similar to this that would support arm64? Unfortunately lldb is still not on par with even gdb.
tieze
People here might also be interested in pwndbg, which adds a lot of qol improvements to the typical gdb/lldb experience. Including splitting dialogs over tmux panes, a lot more context info added to debug lines like where do pointers point to. Heap inspection. Colorization. makes for a much more friendly debugging experience.
coldblues
The RAD Debugger is getting a Linux port so hopefully we won't have to deal with the sad state of Linux debugging anymore.
tw600040
Not related to this post, but why in the world is anyone using TUI. Either go with GUI or go with commandline. This no man's land in the middle is the worst of both worlds..
al13n
Hi, author here :)
Didn't expect it to be posted, readme maybe doesn't have enough context. It just says "Essential features are there". What are those? Most of what I've ever used in any debugger:
* Showing code, disassembly, threads, stack traces, local variables.
* Watches, with a little custom expression language. E.g. you can do pointer arithmetic, type casts, turn a pointer+length into an array, show as hex, etc. Access to local and global variables, thread-local variables, registers. Type introspection (e.g. sizeof and offsets of fields).
* Pretty printers for most C++ and Rust standard library types. Probably fragile and version-dependent (e.g. fields names often changes across versions), please report when they don't work.
* Automatically down-casting abstract classes to concrete classes.
* Breakpoints, conditional breakpoints (but no data breakpoints yet).
* Stepping: into/over/out a source code line, into/over a disassembly instruction, over a source code column (when there are multple statements one line, e.g. to skip evaluation of arguments of a function call). All places where control can stop (statements) are highlighted in the code, so you usually don't get surprised by where a step takes you. (…except when there's garbage in debug info, and you end up temporarily on line 0 or something. This happens frustratingly often, and there's not much I can do about it. I already added quite a few workarounds to make stepping less janky in such cases. If a step takes you to an unexpected place, it usually under-steps rather than over-steps, so you can just step again until you end up in the correct place.)
* Various searches: file by name, function by name, function by address (like addr2line), type by name, global variable by name, thread by stack trace.
* Debugging core dumps. There's also a gdump-like tool built in (`nnd –dump-core`) that makes core dump of a running process without killing it; it uses fork to minimize downtime (usually around a second even if there are tens of GB of memory to dump).
* Customizable key bindings, see `nnd –help-files` or `nnd –help-state`.
* TUI with mouse support, tooltips, etc.
larusso
Back in my native android days I used cgdb to have a split screen view of the sources I debug. The vim like interface was exactly what I needed. Just thought about it after seeing this project.
https://cgdb.github.io/