Show HN: Uscope, a new Linux debugger written from scratch
50 comments
·January 31, 2025IAmLiterallyAB
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)
tux1968
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.
titzer
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.
sroussey
Have it use the WebKit debugger protocol and we can use browser dev tools as the UI.
:p
feelamee
> 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(((
AlotOfReading
If you're willing to deal with enterprise pricing, Undo [0] implements something reasonably comparable to rr without the hardware timer requirements.
[0] https://undo.io/
feelamee
eh, thanks
> How can I persuade my boss to pay for Undo?
fun quote.. but my boss will never pay for it because I am the only one who use gdb in our company, unfortunately)
godelski
> 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.
Analemma_
Is gdb another thing like gcc where the un-hackability and un-extendability was a deliberate choice by rms to ensure nobody would ever build proprietary toolchains on top of it?
debatem1
I don't know if it was deliberate, but writing code that interfaces with GDB is unpleasant enough that I opted to build our debugger-like tooling in eBPF + pyelftools instead.
dooglius
No, GDB has a pretty good Python extension framework
zwieback
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.
lsllc
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...
AndyKelley
He's live on twitch right now demoing this on zig showtime: https://www.twitch.tv/kristoff_it
mplemay
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.
whytevuhuni
Not really. Zig's answer to safety is mostly based on runtime panics, and the kernel really, really hates panics.
As such, the only thing left is better ergonomics, and that's not really worth the effort to switch.
Rust isn't being adopted because it's an easier language to code in, and in fact it's being adopted in spite of the fact that it's harder to code in. And that's because to some kernel devs, the promise of better security and fewer vulnerabilities is worth that much.
On the other hand, Zig is great for user-space applications. The stuff to replace GNU's coreutils with.
defen
Rust also has runtime panics (e.g. indexing outside the bounds of a slice) - how does kernel Rust handle that?
renox
Zig isn't 1.0 so..
jcranmer
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.
meitham
Very happy to see the increasing momentum in the zig community
breatheoften
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.
Hi! I've been building a debugger on my nights and weekends because it's fun, and I personally need a better debugger for my work. GDB and LLDB pain me greatly; we can and will do better!
As explained in the README, it's still very early-days and it's not ready for use yet, but check back often because it's improving all the time!
Check out https://calabro.io/uscope for a more detailed explanation.
Thanks for taking a look!