Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Uscope, a new Linux debugger written from scratch

github.com

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Show HN: Uscope, a new Linux debugger written from scratch

#81

Post by budro »

whytevuhuni wrote: post #76
AndyKelley wrote: post #60

Earlier quoted context omitted.

> 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.

> 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 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

Re: Show HN: Uscope, a new Linux debugger written from scratch

#82

Post by modeless »

LaLaLand122 wrote: post #63
modeless wrote: post #22

Earlier quoted context omitted.

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.

> 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/onlinedocs/gdb.html/D... Are you talking about this, or the old https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/G... ?

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.

Re: Show HN: Uscope, a new Linux debugger written from scratch

#83

Post by dima55 »

alcover wrote: post #75
feelamee wrote: post #27

> 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…

> 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..

emacs. Worked great for decades and works great today. Learn it.

Re: Show HN: Uscope, a new Linux debugger written from scratch

#84

Post by matu3ba »

omnicognate wrote: post #49
bieganski wrote: post #43

> 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,…

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.

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.

Re: Show HN: Uscope, a new Linux debugger written from scratch

#85

Post by Kuinox »

feelamee wrote: post #65
imron wrote: post #62

Earlier quoted context omitted.

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.

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.

I don't know for c but for C# you can write a custom expression that get evaluated for the condition.

Re: Show HN: Uscope, a new Linux debugger written from scratch

#86

Post by n4r9 »

feelamee wrote: post #27

> 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…

Out of interest what are your main use cases for needing conditional breakpoints?

Re: Show HN: Uscope, a new Linux debugger written from scratch

#87

Post by feelamee »

n4r9 wrote: post #86
feelamee wrote: post #27

> 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…

Out of interest what are your main use cases for needing conditional breakpoints?

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/Conve...

Re: Show HN: Uscope, a new Linux debugger written from scratch

#88

Post by HexDecOctBin »

jcranmer wrote: post #31

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 b…

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?).

Re: Show HN: Uscope, a new Linux debugger written from scratch

#89

Post by bean-weevil »

feelamee wrote: post #67
khuey wrote: post #54

Earlier quoted context omitted.

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.

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

You probably need the fix from this page: https://github.com/rr-debugger/rr/wiki/Zen

Re: Show HN: Uscope, a new Linux debugger written from scratch

#90

Post by dzaima »

matu3ba wrote: post #78
AlotOfReading wrote: post #34

Earlier quoted context omitted.

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/

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.
Post reply on HN