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 :)
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)
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`.
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.
For custom pretty-printers, the long-term plan is to make the watch expression language rich enough that you can just write one-liners in the watches window to pretty-print your struct. E.g. `for entry in my_hashmap.entries_ptr.[my_hashmap.num_entries] { if entry.has_value { yield struct {key: &entry.key, value: &entry.value}; } }`. Then allow loading a collection of such printers from a file; I guess each pretty-printer would have a regex of type names for which to use it (e.g. `std:.*:unordered_(multi)?(set|map)`). There are not very many containers in standard libraries (like, 10-20?), and hopefully most of their pretty-printers can be trivial one-liners, so they would be easy enough to add and maintain that incompatibility with other debuggers wouldn't be a big concern. Currently nnd doesn't have anything like that (e.g. there are no loops in the watch expression language), I don't have a good design for the language yet, not sure if I'll ever get around to it.
(Btw, "pretty-printers" is not a good name for what I'm talking about; rather, it transforms a value into another value, e.g. an std::vector into a slice, or an unordered_map into an array of pairs, which is then printed using a normal non-customizable printer. The transformed value ~fully replaces the original value, so you can e.g. do array indexing on std::vector as if it was a slice: `v[42]`. This seems like a better way to do it than a literal pretty-printer that outputs a string.)
What kind of cooperation from library authors would help with container recognition... The current recognizers are just looking for fields begin/end (pointers) or data/len (pointer and number), etc (see src/pretty.rs, though it's not very good code). So just use those names for fields and it should work :) . I'm not sure any more formal/bureaucratic contract is needed. But it would be easy for the recognizer to also check e.g. typedefs inside the struct (I guess most languages have something that translates to typedefs in debug info? at least C++ and Rust do). E.g. maybe a convention would say that if `typedef int THIS_IS_A_VECTOR` is present inside the struct then the struct should be shown as a vector even if it has additional unrecognized fields apart from begin/end/[capacity]; or `typedef int THIS_IS_NOT_A_CONTAINER` would make the debugger show the struct plainly even if has begin+end and nothing else. That's just off the top of my head, I haven't thought in the direction of adding markup to the code.
A maintained collection of recognizers (in some new declarative language?) for containers in various versions of various libraries sure sounds nice at least in theory (then maybe I wouldn't've needed to do all the terrible things that I did in `src/pretty.rs`). But I don't want to maintain such a thing myself, and don't have useful thoughts on how to go about doing it. Except maybe this: nnd got a lot of mileage from very loose duck-typed matching; it doesn't just look for fields "begin" and "end", it also (1) strips field names to remove common suffixes and prefixes: "_M_begin_", "__begin_", "c_begin" are all matched as "begin", (2) unwraps struct if it has just one field: `foo._M_t._M_head_impl._M_whatever_other_nonsense._M_actual_data` becomes just `foo._M_actual_data`; this transformation alone is enough to remove the need for any custom pretty-printer for std::unique_ptr - it just unwraps into a plain pointer automatically. Tricks like this cut down the number of different recognizers required by a large factor, but maybe would occasionally produce false positives ("pretty-print" something that's not a container).
(Dump of thoughts about the expression language, probably not very readable: The maximally ambitious version of the language would have something like: (1) compile to bytecode or machine code for fast conditional breakpoints, (2) be able to inject the expression bytecode+interpreter (or machine code) into the debuggee for super fast conditional breakpoints, and maybe for debuggee function calls along the way, (3) have two address spaces: debuggee memory and script memory, with pointers tagged with address space id either at runtime or at compile time, ideally both (at compile time for good typechecking and error messages, at runtime for being able to do something like `let elem = if container.empty {&dummy_element} else {container.start}`; or maybe the latter is not important in practice, and the address space id should just be part of the pointer type? idk; I guess the correct way to do it is to write lots of pretty-printers for real containers in an imaginary language and see what comes up), (4) some kind of template functions for pretty-printing, (5) templates not only by type, but also maybe by address space, by whether the value's address is known (e.g. a debuggee variable may live on the stack at one point in the program and in register in another part), by variable locations if they're compiled into the bytecode (e.g. same as in the previous pair of parentheses), (6) use the same type system for the scripting language and the debugged program's types, but without RAII etc (e.g. the script would be able to create an std::vector and assign its fields, but it would be a "dead" version of the struct, with no constructor and destructor), (7) but there's at least one simplification: the script is always short-lived, so script memory allocations can just use an arena and never deallocate, so the language doesn't need RAII, GC, or even defer, just malloc. The design space of languages with multiple address spaces and tagged pointers doesn't seem very explored, at least by me (should look for prior art), so it'll take a bunch of thinking and rewriting. Probably the maximally ambitious version is too complex, and it's better to choose some simpler set of requirements, but it's not clear which one. If you somehow understood any of that and have thoughts, lmk :) )
I don't know if you have looked at LLDB but when it evaluates (non-trivial) expressions it does actually compile and link code into the inferior's address space. One of the major selling points when it came out was that you could write "real code compiled by a a real compiler (LLVM)" rather than whatever ad-hoc thing that GDB knows how to do. In theory this gave better support out of the box for things that can't be represented with pointer dereferences or whatever most debuggers support for their data visualization. The downside is that LLDB is extremely slow, and it still fails a lot when dealing with templated types because it will claim (whether honestly or not) that the specialization it wants is not present. And it doesn't look at your source code to generate a new one, which would be an excellent showcase of the LLVM stack, but I guess a bridge too far for a debugger :/
For your thing: I think you can get pretty far with what you're doing, but I do want to point out that just the standard types will probably work for Rust but in C++ ever nontrivial project has their own standard library. Most also hide their data behind a void *impl or whatever so no debugger knows how to deal with it out of the box. I don't expect you to parse the codebase for operator[] or whatever but I think you'd ideally want a simple DSL for building pretty printers, with maybe memory reads and conditionals, plus some access to debug info (e.g. casts and offsetof). I don't think that would be too awful for complexity or performance.
Looks great, reminds me of the GUD interface in emacs. I’m unable to get it to find the code for a crate in a rust workspace. I’ve tried pointing the -d argument at the crate subdirectory, but nothing shows up in the code window. Any tips for debugging this issue?
Weird. Maybe the binary is just built without debug info? Does the list of binaries at the top right say whether debug info was loaded? Are file names and line numbers shown, e.g. in stack trace? Press 'o' in the code window to see+search the source code file paths as they appear in debug info. Also feel free to create a github issue, I'm likely to miss comments here.
This looks great, thank you. I have been spending time in lldb the past couple days and lamenting how terrible of an experience it is compared to an IDE.
Do you know what would be involved in getting this to work on macOS?
