> Build as a library so other people can build other interesting things as well
I firmly believe so much tech has gone to shit because things are no longer hackable. We say "move fast and break things" but we try so hard to prevent that that when we do break things we just create bigger messes and debt, so no one cleans it up. It seems slower to write hackable code but that's in the moment. In the long run it is much faster. Not to mention you get added benefits of others being able to contribute more easily with a lower likelihood of actually breaking shit.
This is great to see. It'd be lovely if Linux gets a decent debugger. Another project to keep an eye on is https://github.com/EpicGamesExt/raddebugger Although, they haven't expanded much beyond Windows, yet.
Author just did a podcast about Uscope a few minutes ago, where they mention this HN post:
Mentioned at : https://youtu.be/stWBTv6grBc?t=456
Looks promising -- it's about time, I haven't been satisfied with any debugger since the days of Periscope!
https://www.os2museum.com/files/docs/periscope/periscope-man...
Yay this is awesome! GDB is a buggy (https://sourceware.org/bugzilla/show_bug.cgi?id=18772 https://sourceware.org/bugzilla/show_bug.cgi?id=9425) mess and rough code quality, I've wanted a do something like this for a while.
To be 100% clear, it's not using gdb/gdbserver under the hood right?
The bugs I linked above are over a decade old, and I have to patch them every time I compile GDB server. Ultimately (IIRC) GDB needs to rework how it handles signals (to their credit, ptrace is a horribly stupid API, especially before PTRACE_SEIZE, so I don't blame them for having issues)
This is definitely an ambitious project, and I worry that you are biting off more than you can chew in doing so. (I've attempted my fair share of debugger projects in the past).
At a low level, one of the main problems is that Linux's kernel interfaces for debugging are just absolute trash. (I see you have multithreaded support mentioned as a future task item, and that's one of the areas where you discover just how bad it really is). And of course ptrace composes somewhat poorly with, well, anything else, so if you want to use perf_event or eBPF to help drive the low-level stuff, well, combining everything into a single event loop is just painful. (Oh, and the documentation for all of this stuff sucks.)
At the medium level, everything is hampered by the number of secret handshakes that go on between the compiler, the linker, the runtime loader, the debugger. And the chronic issue that, in the debugger, you have to be prepared for the possibility that everything is just catastrophically wrong: your stack might be garbage (or downright nonexistent), the thread-local storage register might be a garbage value, variables may have values that don't make sense. After all, you're resorting to a debugger when things don't work, and part of the reason why it might not be working is because you've accidentally corrupted everything.
And at the high level, there's the UI which, as someone who doesn't work on UI, I find terrifying in its own right.
Trying to solve not one of these issues, but all of them, at once, in a new project is ambitious. I'd personally prefer a lot more a project that only tried to tackle one slice of the stack, not all of it.
He's live on twitch right now demoing this on zig showtime: https://www.twitch.tv/kristoff_it
Nice project!
One killer feature would be the ability to connect to the debugger via a socket and control it. Gdb has this interface and for some use cases it's great.
As one of those long-tail "native" languages, Virgil might benefit from this. So far, I've had a student build a DWARF backend, and the experience from that is that DWARF is way too complicated and consequently implementations are broken and crappy in many ways. I think DWARF draws the wrong dividing line here. Control of the machine and customizing the source-level support to the language is probably better.
Keep at it!
raddbg is one worth watching too (currently only Windows x64) https://github.com/EpicGamesExt/raddebugger
Very happy to see the increasing momentum in the zig community
Nice work! I remember meeting you at Systems Distributed in NYC where you mentioned this project, so cool to see the progress. Well done!
Everyone here seems to thing GDB is awful. It's been a while for me but I remember using front-ends like Eclipse's CDT or similar and didn't find that experience so bad. Do most people use GDB straight-up? I haven't done that in probably 15 years although it's nice to have a lightweight command line on small embedded systems.
This is exciting! I use GDB and LLDB, but their TUIs/CLIs make certain things difficult (I feel like debugging seriously benefits from a proper GUI) and graphical front-ends I've tried are pretty janky. Looking forward to trying it out, but I'm excited to see something happening in this space.
This opinion is not backed by facts, any insight about linux (or even the languages in question), or even related to this post. Nevertheless, I wonder if it was a good idea to allow rust contributions to the linux project. From all of the bits and pieces I read about zig (including this project), I feel like it would have been better aligned (than rust) to pick up where the mainly C codebase left off.
Congrats on this work -- writing a debugger from scratch is a big job. I have cloned the repo, will take a proper look this w/e.
How does it compare to gf?
It's not clear to me why we'd need a new debugger instead of GDB enhancements. GDB has an extensible, modern C++ codebase with literal decades of hard earned knowledge baked into it.
How are we better off rewriting it, especially if the rewrite isn't memory safe?
Super supportive as I really value debuggers as tools even tho they are horror shows to use!
> Similarly, the following features are non-goals of the project:
> Supporting non-native languages (i.e. Java, Python, etc.)
But I think that position is likely a mistake in terms of leaving killer features on the table and baking in architecture decisions that might continue to make these kinds of features impossible / very low-class experiences.
Properly integrating with the python interpreter to be able to debug python + c/cpp extensions running in the same process is a huge missing whole in the debugger market.
I don't know how other people do it but I 'solve' this problem by attaching either a python debugger or lldb to the python process -- meaning I can debug either python or the cpp but not both at the same time. The experience is very lacking. Even just seeing the python call-stack while paused at a cpp breakpoint would be huge.
One thing that as far as I know no single debuggers has (except FoxPro from DOS) is the ability to show a large list of things, but well
In general, if something is large (text, arrays, etc) all bets are off.
Basically, something like this:
---
The second thing that is very hard with debuggers, is to tell them what to skip.
In the normal sense of 'I don't wanna debug Rust std' but also 'What the heck, why is stepping into #[Debug]???'
GDB (I don't use LLDB) is fully programmable and has multiple user interfaces (TUI, Emacs, DDD, graphical frontends and various .gdbinit configurations that emulate SoftICE L&F).
It's a power tool and takes some time and effort to learn and master. Superficially dismissing it / wasting your time with something that in all likelihood will end up going nowhere while lacking most features that make GDB great, does not a good recommendation make.
At least you'll probably learn a thing or two while you implement it, but I'd rather not waste my time using it.
How entwined is it with Linux specific APIs? Eg, how hard would it be to port to FreeBSD?
TotalView (which I rep), Linaro DDT - thoughts? (Yes, they’re both proprietary)
> The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible.
Okay, so this is the author's answer to the most important question: "why?"
For me this is a serious issue, making strong statements without any single backing example. If you experience crashes, please report to the maintainers - i guarantee that you won't be ignored. You say that it's missing some data that you need? Fine, but be precise - what data?
Otherwise it sounds like a "yeah, let's make a project for fun and pretend that it's serious by finding sort-of-justification/use case" (i'm not telling that it is the case for you - i'm telling that it sounds like it, based on your own description).
Also, would you feel nice if i put in my project's README a note that the project of you, the one that you put your effort to, "sucks"?
Make it debug systemd config problems and I'd be thrilled.
To clarify “from scratch” as in from basic materials and not “in scratch” as in the MIT graphical programming g system[0]. It appears to be written in Zig[1], which I find interesting for analysis.
> The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible.
quote from https://calabro.io/uscope
Of course gdb, lldb have their problems (e.g. smashing tui with app output, what can be easily fixed, or very very very very long tab-tab completion, and crashing of course), but I dont know anything better. I am forced to use visual studio at work and its debugger really sucks - it can't even compare strings in conditional breakpoint, it cant even skip all std::function / std::bind garbage to let me step in callback, it can't watch evaluated expressions. Probably it can evaluate exprs (immediate window?), but there are very little guides about this.
So, gdb is winner for me now. rr (record-repeat)[0] also looks very nice, but it require hardware support(((
[0] https://rr-project.org/