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

91–100 of 133 posts

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

#91

Post by AlotOfReading »

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.

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.

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

#92

Post by imron »

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

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

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

#93

Post by jcranmer »

HexDecOctBin wrote: post #88
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…

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.

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

#94

Post by debeloo »

marssaxman wrote: post #80
alcover wrote: post #75

Earlier quoted context omitted.

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

> How do you people comfortably debug C in Linux? same way I debug everything, everywhere: logging.

That not very environmentally friendly.

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

#95

Post by caspper69 »

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…

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.

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

#96

Post by Veserv »

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.

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.

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

#98

Post by matu3ba »

Veserv wrote: post #96
matu3ba wrote: post #78

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

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…

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.

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

#99

Post by peterfirefly »

titzer wrote: post #38

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…

> the experience from that is that DWARF is way too complicated

The representation and the compression are far too intertwined :(

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

#100

Post by peterfirefly »

peterfirefly wrote: post #99
titzer wrote: post #38

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…

> the experience from that is that DWARF is way too complicated The representation and the compression are far too intertwined :(

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.

Post reply on HN