[HN Gopher] Show HN: Uscope, a new Linux debugger written from s...
___________________________________________________________________
Show HN: Uscope, a new Linux debugger written from scratch
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!
Author : jcalabro
Score : 158 points
Date : 2025-01-31 17:07 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| adolph wrote:
| 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.
|
| 0. https://scratch.mit.edu/
|
| 1. https://github.com/jcalabro/uscope
| TZubiri wrote:
| lol, I think no one expected a linux debugger to be written in
| the visual programming language for kids.
| duskwuff wrote:
| I'd be very impressed if it were, though.
| AdmiralAsshat wrote:
| "written from scratch" is one of those phrases that seems to
| cause any submission to instantly hit HN frontpage, along with
| "for fun and profit", "considered harmful", and a couple
| others.
| lsllc wrote:
| 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...
| malkia wrote:
| Somehow this brought the memory of Numega's awesome SoftICE!
| zwieback wrote:
| Oh yea, we used both SoftICE and Periscope. I loved the
| pushbutton to fire off an NMI directly on the ISA bus. It was
| sad when your device driver crashed but it was a fun
| experience to push that button.
| malkia wrote:
| I've used only few times back then, but it was impressive
| (previous experience was with Borland's / Turbo debuggers
| which was nice also, but Numega was just another class)
| tux1968 wrote:
| 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.
| quotemstr wrote:
| 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?
| ziddoap wrote:
| Consider this part of the post:
|
| > _I 've been building a debugger on my nights and weeks
| because it's fun_
| dima55 wrote:
| I'm considering the part that says "GDB and LLDB pain me
| greatly". This project both says "I'm doing this for fun" and
| "the state of the art is bad, and I'm trying to fix it", so
| this is a fair question.
|
| GDB is great. He says it crashes a lot, and cannot interpret
| some of his types. Maybe that's his experience, but I haven't
| had those issues after literally decades of using gdb. Some
| bug reports would be nice.
| Agingcoder wrote:
| Decades for me as well, and we've had very different
| experiences : gdb is very powerful , but the user
| experience is atrocious and it does crash a lot.
|
| To be fair, in a number of cases the type issues I had were
| not gdb's fault but bad DWARF produced by the compiler.
| marssaxman wrote:
| After literally decades of occasionally dipping into GDB
| only to quickly remember why I would rather use no debugger
| at all than _that_ , it's hard to imagine what you could
| mean by "great". What are you comparing it to?
| chc4 wrote:
| > GDB has an extensible, modern C++ codebase with literal
| decades of hard earned knowledge baked into it.
|
| I literally laughed outloud at this. Have you ever actually
| opened a GDB source file? It is, as a whole, extremely poor
| quality code. Almost all of it is doing C string manipulation
| and raw pointer arithmetic; almost none of it uses C++ smart
| pointers, nevermind the rest of "modern C++"; the vast majority
| is completely uncommented, and "literal decades of hard earned
| knowledge" can be better translated as "literal decades of
| historical baggage, cruft, and hacks". I regularly cause GDB to
| segfault in normal, mundane operations.
| godelski wrote:
| > It's not clear to me why we'd need a new debugger
|
| People build things for fun. Stop asking "why" and ask "why
| not?"
|
| No one can really predict what's needed and where we need to
| go, so let people just explore. Sometimes they won't find
| things, but sometimes they do. And if they don't, they still
| gain useful knowledge that pays dividends later on anyways.
|
| It's Hacker News, let people hack.
| bregma wrote:
| Well, you can start by tearing down all the fences and firing
| that Chesterton guy's sorry ass. After all, even a 32-bit ARMv7
| uses .eh_unwind sections to crawl the stack for a backtrace,
| right?
|
| Then, you can focus on resolving edge cases that can cause
| papercuts. Make sure the solutions are at the expense of the
| happy path because that's all been solved long ago so there's
| no need to pay attention to it.
| modeless wrote:
| GDB is awful and a replacement is sorely needed. It's buggy and
| slow and feature poor and has a terrible UI and a terrible API
| which makes all the frontends terrible in turn. I haven't
| looked at its code but I'm betting it's terrible too.
| gregthelaw wrote:
| I haven't tried UScope yet (I shall), but I don't agree with
| you about GDB. I don't find it especially buggy unless doing
| niche things like non-stop debugging -- I guess you may well
| have a different experience though.
|
| I think the UI is much maligned unfairly. It has a few
| quirks, but ever used git? For the most part it's fairly
| consistent and well thought through.
|
| By terrible API you mean the Python? I admit it can be a bit
| verbose, but gives me what I find I need.
|
| What features do you most miss? My experience is that most
| people use like 1% of the features, so not sure adding more
| will make a big difference to most people.
| feelamee wrote:
| > What features do you most miss?
|
| one time I wanted to write generic printers. E.g. printer
| of any type which support C++ iterators. But gdb can't call
| C++ functions from python api (excepting weird hacks like
| evaluating `print c.begin()` and catching it output).
| Although this is not very useful because most of types we
| use changes very rarely, that's why writing printers is
| only matter of time.
|
| Another feature is breakpoints which sleep next N seconds.
| We have breakpoints which can skip next N triggering, but
| similar with time will be useful to me to debug mouse
| events in gui apps, etc.
|
| Also the most new gdb still have problems with tab-tab
| completion (and even Ctrl-C don't return control
| immediately).
|
| Also lately I often meet problem _cannot insert breakpoint
| 0_. Probably this is a bug, because answers from
| stackoverflow isn 't relevant for me
| quotemstr wrote:
| > excepting weird hacks like evaluating `print c.begin()`
| and catching it output)
|
| Why do you consider that a weird hack instead of
| legitimate programming technique?
| feelamee wrote:
| If this is not weird hack, why gdb provide api for
| getting C++ variables values instead of using this
| "legitimate programming technique"?
| leni536 wrote:
| > one time I wanted to write generic printers. E.g.
| printer of any type which support C++ iterators.
|
| How would that work for types where the required
| functions are not instantiated, or not instantiated as a
| standalone function? Most iterators' operator++ are
| inlined and probably never instantiated as a distinct
| function.
| feelamee wrote:
| > How would that work for types where the required
| functions are not instantiated
|
| Obviously, it will not. But why not to try?)
|
| > Most iterators' operator++ are inlined
|
| Sure, it's sad.
|
| But I'm still think that such feature - calling C++
| functions from Python API - can be useful.
| modeless wrote:
| It's been a while since I bothered to try to use it because
| my experience has been so bad. So I don't remember all my
| specific complaints about bugs and features. I do remember
| multi process debugging was a big hole last time I looked.
| In contrast, I was able to get multi process debugging
| working really well in Visual Studio.
|
| By terrible API I mean GDB/MI that frontends use. I'm sure
| people will come try to defend it but the proof is in the
| pudding and I don't think it's a coincidence that every GDB
| frontend sucks.
| LaLaLand122 wrote:
| > a terrible API which makes all the frontends terrible in
| turn
|
| I don't know the details. But nowadays gdb supports DAP, as
| any other debugger: https://www.sourceware.org/gdb/current/on
| linedocs/gdb.html/D...
|
| Are you talking about this, or the old https://www.sourceware
| .org/gdb/current/onlinedocs/gdb.html/G... ?
| MaximilianEmel wrote:
| How does it compare to gf?
|
| https://github.com/nakst/gf
| oguz-ismail wrote:
| gf is a frontend to gdb. This is supposed to be a brand new
| debugger
| Brian_K_White wrote:
| orthogonal to the question
| rickydroll wrote:
| Make it debug systemd config problems and I'd be thrilled.
| godelski wrote:
| > Build as a library so other people can build other interesting
| things as well
|
| I LOVE this!
|
| 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_ wrote:
| 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?
| dooglius wrote:
| No, GDB has a pretty good Python extension framework
| debatem1 wrote:
| 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.
| godelski wrote:
| gdb is a bit old and my comment is really more about building
| things in general.
|
| You should always make things hackable, not just for others,
| but for you. One truth to coding is that the final thing will
| never end up where you think it will. So if you don't make
| your code flexible (i.e. hackable) then you're going to keep
| breaking it while fixing it. Things will continue to be
| patches and quick fixes. Nothing is more permanent than a
| temporary fix that works.
|
| Truthfully, this is part of the unix philosophy. Make your
| programs small and integratable. The strategy is not to be
| finished, because there is no end, the strategy is to be
| adaptable, because there is no end.
| koek67 wrote:
| Nice work! I remember meeting you at Systems Distributed in NYC
| where you mentioned this project, so cool to see the progress.
| Well done!
| meitham wrote:
| Very happy to see the increasing momentum in the zig community
| ribs wrote:
| TotalView (which I rep), Linaro DDT - thoughts? (Yes, they're
| both proprietary)
| cintellis wrote:
| how much do those cost approx? for an individual hobbyist
| developer
| feelamee wrote:
| > 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/
| AlotOfReading wrote:
| 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 wrote:
| 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)
| mark_undoio wrote:
| For what it's worth we do offer a more printf-y interface
| for people who don't like a debugger -
| https://docs.undo.io/PostFailureLogging.html
|
| And CLion / VS Code for people who prefer an IDE interface.
|
| But a lot of people do _really_ want to stick with their
| printf debugging.
|
| If your boss won't buy you an Undo you can still use
| https://rr-project.org/ - or on Windows the built in time
| travel debug of WinDbg.
| khuey wrote:
| rr should work on any remotely modern Intel system, and
| generally on AMD's Zen CPUs too. Unless you're in a virtualized
| environment (some of which _are_ supported) or a more esoteric
| architecture rr probably works on your silicon.
| feelamee wrote:
| I have AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8) @
| 2.100GHz.
|
| As I remember - it is should work according to documentation,
| but I couldn't launch it. Probably I'm not spend enough time
| to solve errors
| imron wrote:
| Which visual studio are you using?
|
| It's been a number of years since I've used it but Visual
| Studio PRO could do all these things - at least as long as I
| was using it (since visual c++ 5).
|
| VS Code on the other hand is no where near as featured or
| powerful.
| feelamee wrote:
| I use VS2022 Enterprise
|
| If you know solutions, I will be very thankful for any info.
|
| P.S.
|
| Note, though I meet all of this problems, probably I don't
| spent enough time to find a solution (maybe tried first links
| at google and so on). E.g. tried `strcmp` for breakpoints,
| tried to write .natstepfilter.
|
| So, if VS really can do all of this, I'm sorry for my hurry.
| mplemay wrote:
| 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.
| renox wrote:
| Zig isn't 1.0 so..
| whytevuhuni wrote:
| 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 wrote:
| Rust also has runtime panics (e.g. indexing outside the
| bounds of a slice) - how does kernel Rust handle that?
| nine_k wrote:
| Static checks remove _many_ more potential sources of
| panic. I suspect that with certain restraint one can write
| Rust code that is statically guaranteed to not panic.
|
| Also, Rust's panics may be recoverable, it's not
| necessarily fatal.
| whytevuhuni wrote:
| It does not, for slice indexing Rust is just as bad. My
| best guess is that this will likely blow up into such a big
| issue that the Rust devs are going to be forced to
| implement a feature to disable indexing (and leave just the
| safe .get()), or the kernel devs will fork the core
| library.
|
| But Rust prevents a myriad of other things that would be
| panics in Zig or undefined behavior in C. It has a really
| strong type system, capable of reducing a large amount of
| invalid states and keeping many invariants throughout very
| large codebases.
| AndyKelley wrote:
| > Zig's answer to safety is mostly based on runtime panics
|
| This statement is nonsensical.
|
| Zig's answer to safety is based on a precise type system and
| a simple language that helps the programmer in their quest to
| write perfect code. If a kernel panics, that is either a bug
| or hardware failure.
| saagarjha wrote:
| I actually find that their comment makes a lot more sense
| than yours.
| jcranmer wrote:
| 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.
| breatheoften wrote:
| 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.
| mark_undoio wrote:
| We've got a prototype of debugging in python and C/C++ in GDB -
| https://undo.io/resources/how-i-debug-python-code-with-a-tim...
|
| If you'd like to try it please get in touch, feedback is always
| useful.
| titzer wrote:
| 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 wrote:
| Have it use the WebKit debugger protocol and we can use browser
| dev tools as the UI.
|
| :p
| mindcrime wrote:
| Speaking as a Java guy, remote debugging is SO useful (at times
| anyway). Thankfully the JVM has built in support for a remote
| debugging protocol[1] and there are good debuggers that can
| connect to a running Java system (if it was started with the
| correct command line flags) and do symbolic debugging over the
| network.
|
| There can be certain situations where the network latency can
| make things difficult, but generally speaking I find it an
| incredibly useful facility to have.
|
| [1]:
| https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/...
| gregthelaw wrote:
| 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.
| IAmLiterallyAB wrote:
| 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)
| drewg123 wrote:
| How entwined is it with Linux specific APIs? Eg, how hard would
| it be to port to FreeBSD?
| bieganski wrote:
| > 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"?
| omnicognate wrote:
| I'd rather the time taken enumerating the deficiencies of
| existing debuggers be spent building something better instead.
| I doubt many people that have used gdb/lldb need convincing
| that that's possible. If it is needed, Microsoft's windbg (far
| from what's possible but light years ahead of gdb/lldb) is a
| proof by construction.
| ethin wrote:
| Bit of a possibly unpopular take but I very much disagree.
| The syntax of windbg/cdb is just... Really bad. I feel like
| I'm writing assembly and the mnemonics don't actually align
| with what the command does. So it's difficult for me to get
| confident with it. At least the commands in gdb make sense
| (and I wish gdb supported windows executables, but alas...)
| dumah wrote:
| There are almost 4000 open issues on gdb reported more than
| five years ago.
|
| In this conversation are reports of an annoying bug that
| requires a user patch gdb and it's existed for almost twenty
| years.
|
| It was years before anyone was even assigned because of a bug
| in their bug tracking system, and they haven't addressed any
| further comments over the decades.
| zwieback wrote:
| 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.
| boricj wrote:
| I do use GDB straight up for native programs and
| microcontrollers, mostly out of laziness. I haven't set up VS
| Code debugging at my current day job yet and it's been 6
| months.
|
| Out of the box GDB is kinda awful, especially for C++
| codebases. I should probably look into scripting at some point,
| but meh. Even then, as far as I know I'm the best at using a
| debugger at work by a wide margin, but I attribute that more to
| my knowledge of low-level programming than my ability to use
| most of the basic GDB commands. Also, it tends to crash once a
| month or so.
|
| If I needed to debug a userland program on a small Linux
| embedded system, I'd probably whip out gdbserver and attach gdb
| to the target remotely. I haven't done that in a while though.
| jcelerier wrote:
| > 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.
|
| the issue is not with gdb's UX - you can build as many cool UI
| / UX on top of it as you want. The problem is that gdb will
| sometimes take 5 minutes to start debugging (and that's without
| debuginfod), straight up crash, be unable to resolve obvious
| symbols etc. which are all back-end bugs. For me developing a
| medium-sized C++ app, it's really hell to use and usually
| printf debugging is MUCH faster in the sense that I have the
| time to find and fix my problem through an iterative recompile
| cycle sometimes before gdb has even finished parsing my binary
| AndyKelley wrote:
| He's live on twitch right now demoing this on zig showtime:
| https://www.twitch.tv/kristoff_it
| tux1968 wrote:
| Author just did a podcast about Uscope a few minutes ago, where
| they mention this HN post:
|
| https://youtu.be/stWBTv6grBc
|
| Mentioned at : https://youtu.be/stWBTv6grBc?t=456
___________________________________________________________________
(page generated 2025-01-31 23:00 UTC)