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.
Show HN: Uscope, a new Linux debugger written from scratch
121–130 of 133 posts
Re: Show HN: Uscope, a new Linux debugger written from scratch
#122> 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 crash…
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…
I'm a UNIX guy through and through, literally everything I ever do is writing code on Linux or macOS which targets Linux and/or macOS. I loathe almost everything about the whole Windows ecosystem, from Microsoft as a company to the way they build their UIs to the technical foundations of Windows.
However I have to give them one thing: their developer tooling with Visual Studio and other first-party tools seem vastly superior than anything on macOS/Linux when it comes to debugging. I would never use it as a code editor, but it's clear that a lot of effort has been invested into the debugging experience.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#123Earlier quoted context omitted.
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?
No, GDB has a pretty good Python extension framework
That's not comparable. That lets you extend GDB with your own additions. Having the debugger work as a library means being able to incorporate the debugger's functionality into other systems.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#124Yay 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) GD…
Interesting, LLDB also has a serious bug related to ^c! In LLDB, if you run 'lldb -o run /path/to/executable', it won't pause on SIGINT. As a result, you can't have an ergonomic setup where you have e.g a make target to run your software under LLDB, you always need to manually type 'run' for ^c to work.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#125Earlier quoted context omitted.
> 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. 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 co…
> When it comes to spatial safety
Only at the cost of runtime checks and/or misusable allocator passing.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#126Nice 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…
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 sp…
Which debuggers do you like the most?
Re: Show HN: Uscope, a new Linux debugger written from scratch
#127Earlier quoted context omitted.
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.
Co-founder of Undo here. This is a common misunderstanding, and just not true -- neither for Undo nor rr. Most races will reproduce at least as easily in Undo, especially if you use our "thread fuzzing" feature (rr has something similar, called chaos mode). Sure, there will always be some races/timing issues that just won't repro under recording (Heisenberg principal and all that), but in fact most races are _more li…
Thanks for clarification.
I have not been aware of thread fuzzing and chaos mode before.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#128Earlier quoted context omitted.
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.
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 r…
Thanks for your write-up, this is very helpful for understanding.
Re: Show HN: Uscope, a new Linux debugger written from scratch
#129Earlier quoted context omitted.
> 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 co…
> When it comes to spatial safety Only at the cost of runtime checks and/or misusable allocator passing.
> Only at the cost of runtime checks
And those checks are well worth paying for, enough that Rust also has them! I'm sure Rust would have even worse ergonomics if it insisted on no runtime bounds/unwrap checks. The performance cost is low enough that every systems programming language should have spatial safety. To illustrate, Google found that hardening libc++ by adding bounds checks only led to a 0.30% performance impact on their services [1]. It's not hard to imagine that a similar run-time cost affects Zig and Rust. Both languages make attempts to optimize the checks away if the operation is known-safe. Although, maybe Rust is more successful due to the borrow checker.
> and/or misusable allocator passing.
Could you clarify how allocator misuse might lead to a spatial safety violation?
[1] https://security.googleblog.com/2024/11/retrofitting-spatial...
Re: Show HN: Uscope, a new Linux debugger written from scratch
#130Earlier quoted context omitted.
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.
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.
What kind/class of issues are caused by "thread interleaving on the scale of nanoseconds"?
Faulty CPU bit flips due to radiation/quantum effects or what are you referring to? Just curious.