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.
mmastrac · 25m ago
As a curiosity, is there a more heuristic approach and/or toolchain integrated approach that could be used for disassembly of stdlib components?
For example, a crate that could be linked in to provide some "well-known" object shapes (hashmaps, vec, hashset, etc) with marker values that could be heuristically analyzed to understand the debuggability of those objects?
Alternatively, I'd love to have a crate with recognizers and/or heuristics that could be somewhat debugger-independent and could be worked on for the benefit of other users. I'm quite an experienced Rust developer, just not really with debuggers, happy to help if there's a sandbox project that this could be plugged into.
AtlasBarfed · 1h ago
"what we mean by fast"
I cannot tell you how much respect I feel for you
hippospark · 6h ago
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].
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.
Conscat · 5h ago
At my previous job, the product I worked on would open something like 200 DLL plugins on start-up. This would basically hang GDB while it's indexing the DWARF symbols, but LLDB gives you a very nice asynchronous progress indicator for that.
philsnow · 6h ago
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).
al13n · 3h ago
Fun fact: gdb tui was the last straw that made me start working on nnd. I tried it for the first time, and it was taking 2 seconds to respond to every input, and that made me so angry I started researching how to make a debugger :)
jcalabro · 3h ago
I had pretty much the exact same experience with my debugger (uscope). Your debugger looks awesome, nice work! Hopefully I'll have time to get back to mine at some point (or hopefully RAD comes to Linux first haha)
mbeavitt · 5h ago
check out [cgdb](https://github.com/cgdb/cgdb) - ncurses based gdb tui, with vim bindings. It's no longer actively worked on, but is decently maintained with bugfixes etc AFAIK.
alfanick · 6h ago
Sideline question: how do you end up with 2.5GB binary (ClickHouse as given in the readme)?
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.
larusso · 3h ago
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.
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.
sys_64738 · 5h ago
I couldn't python without adding -m pudb. That's not to say it's not temperamental, but I can live with the quirks once learned.
jebarker · 4h ago
I should force myself to live with it for a week and see if I get more comfortable. One face of it it certainly does everything I currently rely on vscode remote for
tieze · 5h ago
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.
tw600040 · 4h ago
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..
wormius · 1h ago
TUIs are often more responsive in general. Some of us like the terminal and want to minimize as much mouse usage as possible (yes hotkeys exist in good GUI apps, but they're still primarily built around the WIMP model).
Command line often requires a lot of switch memorization. Command Line doesn't offer the full interactive/graphical power in this sort of situation. Command line is great for scripts and long running apps, or super simple interfaces.
Different apps have different requirements. Not everything needs a TUI, not everything needs a GUI, and if you want something similar to a GUI while staying in the terminal. Perhaps you don't have access to a windowing environment for some reason; perhaps you want to keep your requirements low in general.
Finally, why do you care? Some people like it others don't. Nobody comes in and shits on any programs that are GUI if they don't like it, they just don't use it.
So, to quote The Dude: "That's just, like, your opinion man". Sorry for the snark, but... It really is, and you're free to have it. But it seems an irrelevant point, and there may be better forums/posts (maybe an "Ask HN" question would be a good option) to discuss this question in depth beyond snark.
justinrubek · 3h ago
I have many beloved TUI tools at this point, and I am considering investing further in TUI for some further projects I am building that I would want some kind of interface for beyond a command line. I'm not convinced by this argument. Would you mind elaborating on any specifics?
Short summary: No animations, No symbols, No touch optimization, no responsive design and I do most of the other stuff in the Terminal anyways so TUI is better "integration" YMMV :)
badsectoracula · 3h ago
> No animations, No symbols, No touch optimization, no responsive design
You don't have to make a GUI with any of those.
al13n · 3h ago
In this post's case, I went with TUI over GUI to make it work over SSH, which is how I use it most of the time.
fsckboy · 4h ago
are you considering emacs a tui? vi/vim? if you want to edit without a tui, i gotta recommend teco over ed/ex
KerrAvon · 4h ago
One common use case is remote debugging over serial or ssh.
edit: and a reason you would do this locally using ssh is debugging the UI layer itself. if you have to step through the window server, you can't be using the window server at the same time. Remote lldb/gdb debugging is often just flaky. I don't know why they're so unreliable, but they are.
dvektor · 6h ago
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.
worldsavior · 6h ago
Why do you use LLDB on Linux?
dvektor · 2h ago
I asked someone else what they use for rust. Normally I get by well enough with good structured tracing but lately that hasn't been cutting it.
Zambyte · 6h ago
Cool :D anyone get a chance to try this out with Zig yet?
fcoury · 5h ago
Is there anything similar to this that would support arm64? Unfortunately lldb is still not on par with even gdb.
danhau · 5h ago
Cool! Looks like the btop of debuggers. That‘s certainly a tool I would love to have.
deagle50 · 5h ago
the macOS drought continues
_bohm · 5h ago
It is really crazy how limited debugger options are on macOS. Is it simply the case that there are not that many people writing code in systems languages on macOS outside of XCode?
marssaxman · 5h ago
I used to be such a person, but after years of feeling as though Apple found people like me irritating and wished we would all stop bothering them, I finally took the hint.
Linux may not be so pretty, but it's far more comfortable.
deagle50 · 4h ago
Linux is great, my issue is laptop hardware.
marssaxman · 2h ago
What problems do you encounter? Which sorts of laptops do you prefer?
My "all Thinkpad, all the time" strategy has generally served me well (though I was disappointed by the most recent one, a T14, which would never sleep properly).
dmitrygr · 3h ago
MacBookAir + aarch64 linux vm -- best of all the worlds. Linux for the 5% of things I need linux for, amazing battery life and hardware for the remaining 95% of things my laptop does.
pimeys · 5h ago
Kind of. I am a systems engineer and want to work on an open OS I can debug with my syseng skills...
worldsavior · 5h ago
It's because macOS has security measures.
Keyframe · 6h ago
great! I already gave up on RemedyBG or RAD/Epic debugger ever on linux to happen.
theoperagoer · 6h ago
Very cool. How many architectures do you support?
baumschubser · 5h ago
It does say so right in the readme:
> Linux only
> x86 only
> 64-bit only
theoperagoer · 1h ago
no need to be a jerk
FpUser · 6h ago
It looks very useful. I will definitely test it. Thank you for such contribution.
jmclnx · 7h ago
Looks very nice, will need to give it a spin :)
colesantiago · 6h ago
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.
laserbeam · 5h ago
There’s only 1 artifact. A static executable. No “need” for a package manager. If someone builds a package manager they would just need to compile the src and ship the executable.
All you need to do otherwise is add it in PATH.
ablob · 5h ago
You can always build it yourself and put the binary somewhere in your runtime path.
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.
For example, a crate that could be linked in to provide some "well-known" object shapes (hashmaps, vec, hashset, etc) with marker values that could be heuristically analyzed to understand the debuggability of those objects?
Alternatively, I'd love to have a crate with recognizers and/or heuristics that could be somewhat debugger-independent and could be worked on for the benefit of other users. I'm quite an experienced Rust developer, just not really with debuggers, happy to help if there's a sandbox project that this could be plugged into.
I cannot tell you how much respect I feel for you
[^1]: https://www.timdbg.com/posts/writing-a-debugger-from-scratch... [^2]: https://nostarch.com/building-a-debugger
[1]:https://keowu.re/posts/Writing-a-Windows-ARM64-Debugger-for-...
--
1: https://github.com/munificent/craftinginterpreters/issues/92...
Another book added to my To-Read list
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.
(It shows only about 500 MB of machine code, and the rest of the gigabytes are debug info.)
Not sure about ClickHouse though.
No comments yet
https://github.com/EpicGamesExt/raddebugger/issues/23
https://cgdb.github.io/
Command line often requires a lot of switch memorization. Command Line doesn't offer the full interactive/graphical power in this sort of situation. Command line is great for scripts and long running apps, or super simple interfaces.
Different apps have different requirements. Not everything needs a TUI, not everything needs a GUI, and if you want something similar to a GUI while staying in the terminal. Perhaps you don't have access to a windowing environment for some reason; perhaps you want to keep your requirements low in general.
Finally, why do you care? Some people like it others don't. Nobody comes in and shits on any programs that are GUI if they don't like it, they just don't use it. So, to quote The Dude: "That's just, like, your opinion man". Sorry for the snark, but... It really is, and you're free to have it. But it seems an irrelevant point, and there may be better forums/posts (maybe an "Ask HN" question would be a good option) to discuss this question in depth beyond snark.
Short summary: No animations, No symbols, No touch optimization, no responsive design and I do most of the other stuff in the Terminal anyways so TUI is better "integration" YMMV :)
You don't have to make a GUI with any of those.
edit: and a reason you would do this locally using ssh is debugging the UI layer itself. if you have to step through the window server, you can't be using the window server at the same time. Remote lldb/gdb debugging is often just flaky. I don't know why they're so unreliable, but they are.
Linux may not be so pretty, but it's far more comfortable.
My "all Thinkpad, all the time" strategy has generally served me well (though I was disappointed by the most recent one, a T14, which would never sleep properly).
> Linux only > x86 only > 64-bit only
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.
All you need to do otherwise is add it in PATH.