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

131–133 of 133 posts

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

#131

Post by dzaima »

matu3ba wrote: post #130
dzaima wrote: post #90

Earlier quoted context omitted.

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.

Not doing things atomically when they should be (incl. missing locks around tiny ops) would be a pretty large class.

With native multithreading data can pass from thread to thread millions of times per second, and you're much less likely to hit obscure interactions when limited instead to maybe a couple hundred context switches per second.

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

#132

Post by hitekker »

saagarjha wrote: post #73
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.

I actually find that their comment makes a lot more sense than yours.

Andy Kelley's comment corrected unintentional flamebait. I don't see how his comment was confusing.

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

#133

Post by jcelerier »

zwieback wrote: post #47

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.

example from today, timed with a stopwatch, on a 5950X 5GHz CPU: from the moment I click on "debug" in my IDE,

- lldb takes 40 seconds to reach "main"

- 2 minutes 36 total to reach the GUI and start being able to reproduce things

- gdb coredumps as soon as I want to put a breakpoint so it's unuseable

    $ lldb --version
    lldb version 19.1.7
    $ gdb  --version
    GNU gdb (GDB) 16.1
Post reply on HN