[HN Gopher] Nnd - a TUI debugger alternative to GDB, LLDB
___________________________________________________________________
Nnd - a TUI debugger alternative to GDB, LLDB
Author : zX41ZdbW
Score : 197 points
Date : 2025-05-06 13:58 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dec0dedab0de wrote:
| 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 wrote:
| 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.
| jmclnx wrote:
| Looks very nice, will need to give it a spin :)
| trollbridge wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| alfanick wrote:
| Sideline question: how do you end up with 2.5GB binary
| (ClickHouse as given in the readme)?
| PhilipRoman wrote:
| #include <iostream>
| mmoskal wrote:
| Very typical for anything with CUDA (they tend to compile
| everything for 10 different architectures times hundreds of
| template kernel parameters).
|
| Not sure about ClickHouse though.
| mrazomor wrote:
| Heavy use of C++ templates can significantly increase the
| binary size. Same for the heavy use of generated code (e.g.
| protocol buffers etc.).
| zX41ZdbW wrote:
| This is visible in the embedded binary viewer:
| https://play.clickhouse.com/binary?user=binary&zoom=0&x=1620...
|
| (It shows only about 500 MB of machine code, and the rest of
| the gigabytes are debug info.)
| eclbg wrote:
| ClickHouse is a completely stand-alone binary that doesnt rely
| on any linked libraries. Not sure how much of this explains the
| large binary size, though.
| dvektor wrote:
| 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 wrote:
| Why do you use LLDB on Linux?
| dvektor wrote:
| 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.
| hippospark wrote:
| 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
| emmanueloga_ wrote:
| Cool! I did not know about that book. Added to [1]. :-)
|
| --
|
| 1:
| https://github.com/munificent/craftinginterpreters/issues/92...
| _benj wrote:
| Nice! Thanks for sharing :-)
|
| Another book added to my To-Read list
| phaistra wrote:
| I recently found a super cool article[1] which also gives a
| good overview of how a debugger works.
|
| [1]:https://keowu.re/posts/Writing-a-Windows-ARM64-Debugger-
| for-...
| FpUser wrote:
| It looks very useful. I will definitely test it. Thank you for
| such contribution.
| Zambyte wrote:
| Cool :D anyone get a chance to try this out with Zig yet?
| colesantiago wrote:
| 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 wrote:
| 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 wrote:
| You can always build it yourself and put the binary somewhere
| in your runtime path.
| Keyframe wrote:
| great! I already gave up on RemedyBG or RAD/Epic debugger ever on
| linux to happen.
| theoperagoer wrote:
| Very cool. How many architectures do you support?
| baumschubser wrote:
| It does say so right in the readme:
|
| > Linux only > x86 only > 64-bit only
| theoperagoer wrote:
| no need to be a jerk
| philsnow wrote:
| 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).
| mbeavitt wrote:
| 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.
| cassepipe wrote:
| Since gdb uses readline, you can use vim binding on the
| command line by configuring your ~/.inputrc (will work for
| bash, rlwrap, etc.)
| arch_rust wrote:
| I developed https://github.com/wcampbell0x2a/heretek as a
| modern equivalent
| al13n wrote:
| 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 wrote:
| 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)
| shmerl wrote:
| nvim + nvim-dap + nvim-dap-ui + gdb beats gdb's barebones TUI
| by a huge margin.
| danhau wrote:
| Cool! Looks like the btop of debuggers. That's certainly a tool I
| would love to have.
| deagle50 wrote:
| the macOS drought continues
| _bohm wrote:
| 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?
| pimeys wrote:
| Kind of. I am a systems engineer and want to work on an open
| OS I can debug with my syseng skills...
| marssaxman wrote:
| 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 wrote:
| Linux is great, my issue is laptop hardware.
| dmitrygr wrote:
| 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.
| marssaxman wrote:
| 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).
| worldsavior wrote:
| It's because macOS has security measures.
| saagarjha wrote:
| Apple continuously makes the life of third party debuggers
| difficult, to the point where doing so today on a "stock"
| system requires malware-like techniques to get around their
| mitigations.
| fcoury wrote:
| Is there anything similar to this that would support arm64?
| Unfortunately lldb is still not on par with even gdb.
| tieze wrote:
| 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 wrote:
| The RAD Debugger is getting a Linux port so hopefully we won't
| have to deal with the sad state of Linux debugging anymore.
| jpeeler wrote:
| Sounds like it's a little ways off though, no?
|
| https://github.com/EpicGamesExt/raddebugger/issues/23
| tw600040 wrote:
| 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..
| KerrAvon wrote:
| 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.
| fsckboy wrote:
| are you considering emacs a tui? vi/vim? if you want to edit
| without a tui, i gotta recommend teco over ed/ex
| justinrubek wrote:
| 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?
| al13n wrote:
| 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.
| Linux-Fan wrote:
| I wrote about it extensively here:
| <https://masysma.net/37/why_terminal.xhtml>.
|
| 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 wrote:
| > No animations, No symbols, No touch optimization, no
| responsive design
|
| You don't have to make a GUI with any of those.
| perching_aix wrote:
| You don't, but others can and do. With these being
| limitations for TUIs however, others can't do either,
| making this a selling point (not a TUI afficionado, just
| passing by).
| wormius wrote:
| 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.
| JCattheATM wrote:
| Sometimes it's really nice having a terminal tool with a
| minimal interface without needing switches.
|
| Other times it's just a contrarian thing.
| al13n wrote:
| 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.
| AtlasBarfed wrote:
| "what we mean by fast"
|
| I cannot tell you how much respect I feel for you
| mmastrac wrote:
| 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.
| larusso wrote:
| 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/
___________________________________________________________________
(page generated 2025-05-06 23:00 UTC)