6 ms·
Nnd – a TUI debugger alternative to GDB, LLDB
- danhau 1y agoCool! Looks like the btop of debuggers. That‘s certainly a tool I would love to have.
- coldblues 1y agoThe RAD Debugger is getting a Linux port so hopefully we won't have to deal with the sad state of Linux debugging anymore.
- jpeeler 1y agoSounds like it's a little ways off though, no? https://github.com/EpicGamesExt/raddebugger/issues/23 https://github.com/EpicGamesExt/raddebugger/issues/23
- dec0dedab0de 1y agoI 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 1y agoAt 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.
- saagarjha 1y agoYeah, they added it recently, it's quite nice. Of course what would be nicer is parsing symbols faster (come on, I have a bunch of cores on this machine) but it's better than just waiting forever that it used to do before.
- PTOB 1y agoAs someone who spends lots of time in Autodesk tools, this made me tear up a little bit.
- jmclnx 1y agoLooks very nice, will need to give it a spin :)
- trollbridge 1y agoAwesome 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 1y agoThis 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 1y agoI 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 1y agoI 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 1y agoSideline question: how do you end up with 2.5GB binary (ClickHouse as given in the readme)?
- eclbg 1y agoClickHouse 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.
- PhilipRoman 1y ago#include <iostream>
- deleted 1y ago[deleted]
- mmoskal 1y agoVery 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 1y agoHeavy use of C++ templates can significantly increase the binary size. Same for the heavy use of generated code (e.g. protocol buffers etc.).
- zX41ZdbW 1y agoThis is visible in the embedded binary viewer: https://play.clickhouse.com/binary?user=binary&zoom=0&x=16203&y=14505 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.)
- dvektor 1y agoVery 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 1y agoWhy do you use LLDB on Linux?
- hippospark 1y agoFor 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-part-1/ https://www.timdbg.com/posts/writing-a-debugger-from-scratch... [^2]: https://nostarch.com/building-a-debugger https://nostarch.com/building-a-debugger
- emmanueloga_ 1y agoCool! I did not know about that book. Added to [1]. :-) -- 1: https://github.com/munificent/craftinginterpreters/issues/922 https://github.com/munificent/craftinginterpreters/issues/92...
- _benj 1y agoNice! Thanks for sharing :-) Another book added to my To-Read list
- phaistra 1y agoI 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-Reverse-Engineering-KoiDbg/ https://keowu.re/posts/Writing-a-Windows-ARM64-Debugger-for-...
- FpUser 1y agoIt looks very useful. I will definitely test it. Thank you for such contribution.
- Zambyte 1y agoCool :D anyone get a chance to try this out with Zig yet?
- jcalabro 1y agoI just gave it a try on some zig code and no dice. Works great with C though, and I might just be doing it wrong!
- colesantiago 1y agoHow 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.
- ablob 1y agoYou can always build it yourself and put the binary somewhere in your runtime path.
- laserbeam 1y agoThere’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.
- degamad 1y agoDownload latest "nnd" file from https://github.com/al13n321/nnd/releases https://github.com/al13n321/nnd/releases and place it somewhere you like. Set the executable bit (using chmod or your file explorer's properties tab). The program is now installed.
- Keyframe 1y agogreat! I already gave up on RemedyBG or RAD/Epic debugger ever on linux to happen.
- HexDecOctBin 1y agoWhy? Ryan has explicitly said that he will soon be working on the Linux port of RADDbg.
- theoperagoer 1y agoVery cool. How many architectures do you support?
- baumschubser 1y agoIt does say so right in the readme: > Linux only > x86 only > 64-bit only
- theoperagoer 1y agono need to be a jerk
- yjftsjthsd-h 1y agoThat didn't sound impolite to me. They answered the question, and while they pointed out that you could have gotten the answer yourself with one click and a little reading (it's the 3rd section in the readme), that's... true and they weren't rude about it.
- theoperagoer 1y agoI disagree.
- philsnow 1y agoGDB 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 1y agocheck out [cgdb](https://github.com/cgdb/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.
- al13n 1y agoFun 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 1y agoI 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 1y agonvim + nvim-dap + nvim-dap-ui + gdb beats gdb's barebones TUI by a huge margin.
- deleted 1y ago[deleted]
- deagle50 1y agothe macOS drought continues
- _bohm 1y agoIt 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 1y agoKind of. I am a systems engineer and want to work on an open OS I can debug with my syseng skills...
- marssaxman 1y agoI 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 1y agoLinux is great, my issue is laptop hardware.
- dmitrygr 1y agoMacBookAir + 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 1y agoWhat 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).
- fcoury 1y agoIs there anything similar to this that would support arm64? Unfortunately lldb is still not on par with even gdb.
- tieze 1y agoPeople 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 1y agoNot 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 1y agoOne 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 1y agoare you considering emacs a tui? vi/vim? if you want to edit without a tui, i gotta recommend teco over ed/ex
- justinrubek 1y agoI 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 1y agoIn 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 1y agoI wrote about it extensively here: <https://masysma.net/37/why_terminal.xhtml 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 1y ago
- al13n 1y agoHi, 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 1y ago"what we mean by fast" I cannot tell you how much respect I feel for you
- mmastrac 1y agoAs 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 1y agoBack 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/ https://cgdb.github.io/
- udev 1y agoLove TUI debuggers since I first used the Borland IDE. It is incredible how small and well done that IDE was: hyperlinked (!) documentation, with examples (!!), and awesome debugger. All with TUI.
- gitroom 1y agobeen messing around with tui apps for a while - always get drawn back to how much faster terminal stuff feels. this kinda project honestly feels like it gets what i want better than some huge gui setup