[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 : 210 points
Date : 2025-01-31 17:07 UTC (14 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.
| mesbahamin wrote:
| They fully plan to support Linux.
| 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.
| dzaima wrote:
| I'll +1 GDB/MI being utter garbage. Bespoke format
| (ordered multimap as the only keyed data structure, why),
| weird quoting requirements (or sometimes requirement of
| lack thereof) on input, extremely incomplete, and in some
| cases nearly unusable even for what it does support.
| Feels more like carelessly shoehorning some of the
| existing gdb commands with a different syntax (but
| sometimes not different) than an actual API.
| 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... ?
| modeless wrote:
| Thanks, I hadn't seen that, seems like it was just released
| a year ago. Seems like a step forward. I was talking about
| GDB/MI, which was the main (only?) option for decades and
| could still be considered the "native" frontend API of GDB.
| 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.
| matu3ba wrote:
| Are you aware of solutions for multi-threaded and relative
| time-accurate recordings, for example by using user-selected
| synchronization points? Afaiu, rr and undo do simulation of
| threads on one CPU core, which rules out detecting timing
| issues.
| dzaima wrote:
| While the single-threaded execution means that issues from
| thread interleaving on the scale of nanoseconds will
| effectively not happen, multiple threads are still allowed
| and will be context-switched between. rr also has a chaos
| mode to intentionally make the context switching unfair.
| AlotOfReading wrote:
| Antithesis is the only general purpose system I've seen for
| that. It takes the same single threaded approach, but can
| scale to N separate systems and fault injecting possible
| orderings.
| Veserv wrote:
| Multiplexing onto a single thread is sufficient to observe
| and record concurrency errors. If that is not sufficient,
| then I am assuming you want to observe and record errors
| caused by true parallelism. If so, then you need a full
| memory trace. That restricts you to either hardware that
| supports full memory trace connected to a hardware trace
| probe or instrumented software full memory trace.
|
| The former basically only exists for embedded boards and
| the latter does not exist (at say less than a 10x slowdown)
| for Linux or any other common desktop operating system as
| far as I am aware.
| matu3ba wrote:
| So the only way to trace probe consumer desktop CPUs and
| possibly GPUs is by the hardware vendors them-self or
| specialized facilities/laboratories? For Intel I can find
| https://www.lauterbach.com/supported-
| platforms/architectures..., but nothing for trace probing
| AMD or later versions.
| Veserv wrote:
| You can trace consumer desktop CPUs using instrumented
| software full memory trace, but that requires OS +
| debugger + compiler support which is not available for
| Linux, Windows, Mac, etc.
|
| You can trace hardware that exposes trace functionality
| usually via a debug port of some kind. Many chips have
| trace functionality in their production design, but no
| debug connector is physically present in off-the-shelf
| boards (to reduce manufacturing cost). You can usually
| physically modify the board to get access to this
| functionality which is routinely done when porting
| software to a new chip/board.
|
| Trace functionality comes in two major flavors, control
| flow trace and memory trace. Control flow trace only
| records control flow, so the contents of memory are
| unknown which is not very useful for your desired use
| case. Memory trace records memory accesses, so the
| contents of memory are known. Unfortunately, memory trace
| is very resource intensive, so most systems that support
| trace only implement control flow trace. As far as I am
| aware, it is very unlikely that any desktop or server CPU
| has memory trace.
|
| The major manufacturers of trace probes and solutions
| that I know of are Green Hills Software, Lauterbach, and
| Segger.
| 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
| bean-weevil wrote:
| You probably need the fix from this page:
| https://github.com/rr-debugger/rr/wiki/Zen
| 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.
| Kuinox wrote:
| I don't know for c but for C# you can write a custom
| expression that get evaluated for the condition.
| alcover wrote:
| > gdb(..) smashing tui with app output
|
| this got me losing my mind. How/why propose this tempting TUI
| mode when the result looks like a broken arcade game ??
|
| How do you people comfortably debug C in Linux ? I know VSCode
| looks nice but by principle I can't accept to use such a beast
| to basically edit code..
| feelamee wrote:
| as I said - this easy to fix once and for ever
|
| Also not all apps write to stdout/stderr by default.
|
| > How do you people comfortably debug C in Linux ?
|
| It depends on what _comfortable_ is for you. Most of my pc
| experience is terminal and browser and this is comfortable
| for me. I just use gdb for debugging. Sometimes trying lldb
| marssaxman wrote:
| > How do you people comfortably debug C in Linux?
|
| same way I debug everything, everywhere: logging.
| debeloo wrote:
| That not very environmentally friendly.
| dima55 wrote:
| emacs. Worked great for decades and works great today. Learn
| it.
| imron wrote:
| > How do you people comfortably debug C in Linux ?
|
| I just got comfortable using gdb/lldb from the terminal. Once
| you get used to it, it's fine (albeit not pretty).
| billfruit wrote:
| Use Emacs to drive gdb (through the GUD mode) gives a much
| more ergonomic interface. It highlights the line of code
| being traced in the code window.
| n4r9 wrote:
| Out of interest what are your main use cases for needing
| conditional breakpoints?
| feelamee wrote:
| For example for debugging gui apps. Let's say we have
| function `on_event(event_type)` and you want to examine
| execution if `event_type == mouse_up`.
|
| In reality conditional breakpoint is the same as simple, but
| simple require support from code:
|
| ``` void on_event(event_type type) { if (type == mouse_up) {
| // set breakpoint here } } ```
|
| Also useful to break depending on call stack[0]
|
| [0] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Co
| nve...
| caspper69 wrote:
| Man, if you read my comments lately you would think I'm a
| Microsoft fanboy, sheesh.
|
| But honestly, in all my years, Visual Studio has been (by far)
| the best non-commercial (or should I say built-in?) debugger
| that I've used, and that includes gdb.
|
| I am not a huge c++ on Windows guy though, so YMMV.
|
| Here are a few guides that you may find helpful (and I am also
| going to include the beginner one, but please do not take that
| as an indictment of your skill level, I am including only for
| completeness).
|
| These are all for VS2022:
|
| C++ Debugging Tutorial: https://learn.microsoft.com/en-
| us/visualstudio/debugger/gett...
|
| C++ Breakpoint Debugging: https://learn.microsoft.com/en-
| us/visualstudio/debugger/usin...
|
| Breakpoint/Watch Expressions (pay attention to the debugger
| intrinsics): https://learn.microsoft.com/en-
| us/visualstudio/debugger/expr...
|
| High Level Debugger Tour: https://learn.microsoft.com/en-
| us/visualstudio/debugger/debu...
|
| VS2022 Debugging TOC: https://learn.microsoft.com/en-
| us/visualstudio/debugger/?vie...
|
| My apologies if you've already found these references and they
| don't do you any good, but your issues just don't sound like
| the types of issues I've ever experienced with the debugger,
| and sometimes MS' documentation is just disorganized and
| incomplete.
| 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.
| whytevuhuni wrote:
| > This statement is nonsensical.
|
| You're right, my bad. It is hard to be precise in a comment
| where I'm trying to be as concise as possible.
|
| I'm sure you know what I mean though, with regards to
| temporal memory safety (lifetimes), data races (Send/Sync
| traits), etc. Rust works by preventing many classes of bugs
| through compile errors, rather than panics.
|
| > If a kernel panics, that is either a bug or hardware
| failure.
|
| And this is where Rust differs; Rust will reduce the
| likelihood of bugs from happening in the first place. I'm
| not saying Zig doesn't also do that, Rust just does it
| more.
|
| The Rust compiler devs, in their quest to make a type
| system that is powerful enough to catch most memory
| corruption errors, somehow came up with something that can
| be used to catch far more issues than just that.
|
| The affine(ish) type system, coupled with lifetimes, makes
| modeling and maintaining correct states much easier than in
| Zig, for all sorts of objects and abstractions.
|
| From what I've read from Linus on LKML/lore along the
| years, a kernel oops/panic is seen as one of the worst
| things that could happen to it; there is generally nothing
| the user can do at that point to debug it (they likely
| won't even see the console), and makes the machine unusable
| for all other tasks. Sometimes you might be lucky and just
| kill and collect the thread that panicked, but oftentimes
| you get the nuclear OOPS option. With Zig you don't even
| get the option to catch it via something like catch_unwind.
| budro wrote:
| > And this is where Rust differs; Rust will reduce the
| likelihood of bugs from happening in the first place. I'm
| not saying Zig doesn't also do that, Rust just does it
| more.
|
| I'd argue that it does this a LOT more. When it comes to
| spatial safety, Rust and Zig are on par. However in terms
| of temporal safety I think Zig lags far behind Rust...
| along with basically every other compiled systems
| language.
|
| If you had to come up with a single good reason to use
| Rust over Zig, it would definitely be temporal safety. A
| majority of applications don't need this though, or can
| be designed such that they don't.
|
| One of my main issues with Rust is that it makes it easy
| to write spaghetti code that uses reference counting all
| over the place. I don't recommend people to use Rust
| until they become a "N+1 programmer" that Casey Muratori
| describes as "grouped element thinking" [1]. At this
| point, most of that programmers problems are solved and
| suddenly the Zig vs Rust debate becomes much more
| nuanced.
|
| [1] https://www.youtube.com/watch?v=xt1KNDmOYqA
| senkora wrote:
| > until they become a "N+1 programmer" that Casey
| Muratori describes as "grouped element thinking"
|
| Thank you for this great link.
| caspper69 wrote:
| I've done a couple of projects in Rust, and I can
| appreciate this sentiment.
|
| I don't think my code was pretty and I _know_ it wasn 't
| idiomatic. But I have some experience in writing
| concurrent code, so I have an understanding of the
| reasoning behind Rust's borrowing semantics, why
| lifetimes are important, and the difference between boxed
| values, rc, arc, and I additionally understand the
| semantics of semaphores, mutexes, spinlocks, and critical
| sections.
|
| (As an aside, I don't know if I'm an N+1 programmer. My
| code works, long term, requires very little maintenance,
| and generally stays out the way. Just the way I like it.)
|
| But- I see these recurring themes in posts from
| Rustaceans along the lines of "the compiler tells you
| what's wrong" and "if it compiles, it's correct!"
|
| These kinds of statements worry me. Not necessarily
| because I think their code is going to blow something up,
| but because I think a sizeable portion of the community
| does not really understand the guarantees Rust provides,
| and under what contexts they are valid. I mean, sure, you
| might not have a data race, but you sure as hell can code
| yourself into race condition or a deadlock, and from what
| I understand from HNers, these situations are not all
| that uncommon in Rust crates. I'm also led to believe
| that the panic handling situation in some crates isn't
| ideal.
|
| You shouldn't just haphazardly Arc<Mutex<T>> all the
| things just because that gives you the Send + Sync that
| you think you're looking for (or the compiler is looking
| for). You should understand what the hell you're doing,
| be able to tell if those things are necessary, and
| understand the ramifications of using those abstractions.
|
| I think there's a lot of good going on in the Rust
| ecosystem, and I wish I had more work in that area, but
| there's a lot of blind advocacy there that assumes the
| Rust approach is the best, but the language does have
| serious ergonomic limitations in certain low level
| scenarios. My whole career I've had to focus on scope and
| objects that outlive their scope, but now every other
| word I seem to hear from the Rust community is
| "Lifetimes" and "Ownership", like these concepts were
| completely unfamiliar to developers before and now the
| Rust Way(tm) is not only THE WAY, but THE ONLY RIGHT WAY.
|
| I don't want to go too far off the rails, because I find
| the ecosystem intriguing, and I see tremendous value
| there. Whether those approaches stand the test of time
| isn't a given (although let's face it, they probably will
| because they are sound and they are gaining developer
| mindshare, which is the most important factor).
|
| I just worry about ergonomics. Coding is not supposed to
| be _easy_ , so please don't misunderstand- but coding,
| especially for those that do it day in and day out for
| decades, should not be a _chore_. There are definitely
| some QOL improvements that could be realized in the near
| term, although I 'm not sure what those would look like.
| 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.
| HexDecOctBin wrote:
| Yup, Linux is nowhere the Unix successor we deserved. I have
| started multiple systems projects in Linux and gave always
| given up due to how shoddy the foundations are. It seems like
| the kernel just copies whatever cool feature they find in
| Solaris, BSD, Plan 9 or even NT without paying any attention to
| their composability, while the user space people are just a
| clique trying to force their way on everyone (why is the loader
| part of libc again?).
| jcranmer wrote:
| There are a few things where Linux has been the innovator
| (eBPF comes to mind).
|
| But process control is not one of them, and almost any other
| operating system manages to have a more sane interface.
| Personally, if I were writing a debugger, I think the OS with
| the sanest kernel interface is probably Fuchsia, partially
| because everything is handle-based and partially because
| pretty much every syscall takes in a handle to the process to
| operate on, so you can do things like manipulate memory maps
| of another process without driving yourself insane.
| 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/...
| peterfirefly wrote:
| > the experience from that is that DWARF is way too complicated
|
| The representation and the compression are far too intertwined
| :(
| peterfirefly wrote:
| Oh, and there needs to be some sort of declarative, rules-
| based DWARF checker. Preferably one that doesn't only work on
| complete files (or collections of files) but also handles
| snippets.
|
| If it's fast and can work on snippets before they are even
| written to disk, we can probably catch many compiler bugs.
| 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...)
| matu3ba wrote:
| windbg has no sane library api, which makes it by
| construction unsuitable for automation and inspection.
|
| I'd personally prefer, if we would have the options of
| multiple time-travel debugging sessions based on
| synchronization points (if needed) being overlapped to single
| out bugs in interesting areas (not covered by static or
| dynamic analysis). Debugger would be essentially a virtual
| program slicer being able to hide unnecessary program parts
| or reduce it. However, so far we neither have the options for
| piece-wise time-accurate multi-threading recording, nor
| slicing overlays nor in-memory reducers (ideally also
| reducing AST). I may be mistaken on "piece-wise time-accurate
| multi-threading", since I've not checked what is possible
| with hardware yet.
|
| Heck, we dont even have overview data for common bug classes
| and cost for verification or runtime-checking in academia
| etc.
| 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
| khuey wrote:
| > The problem is that gdb will sometimes take 5 minutes to
| start debugging
|
| If you run gdb-add-index on the relevant binaries ahead of
| time it should start up much faster.
| AndyKelley wrote:
| He's live on twitch right now demoing this on zig showtime:
| https://www.twitch.tv/kristoff_it
| AndyKelley wrote:
| recording: https://www.youtube.com/watch?v=stWBTv6grBc
| 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
| mamcx wrote:
| 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:
|
| https://github.com/okbob/pspg
|
| ---
|
| 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]???'
| armitron wrote:
| 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.
| s3graham wrote:
| Keep at it!
|
| raddbg is one worth watching too (currently only Windows x64)
| https://github.com/EpicGamesExt/raddebugger
___________________________________________________________________
(page generated 2025-02-01 08:00 UTC)