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

51–60 of 133 posts

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

#51

Post by sroussey »

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…

Have it use the WebKit debugger protocol and we can use browser dev tools as the UI.

:p

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

#52

Post by boricj »

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.

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.

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

#53

Post by quotemstr »

feelamee wrote: post #42
gregthelaw wrote: post #23

Earlier quoted context omitted.

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…

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

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

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

#54

Post by khuey »

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…

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.

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

#55

Post by nine_k »

defen wrote: post #44
whytevuhuni wrote: post #35

Earlier quoted context omitted.

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…

Rust also has runtime panics (e.g. indexing outside the bounds of a slice) - how does kernel Rust handle that?

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.

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

#56

Post by ethin »

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.

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

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

#57

Post by malkia »

zwieback wrote: post #45
malkia wrote: post #9

Earlier quoted context omitted.

Somehow this brought the memory of Numega's awesome SoftICE!

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.

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)

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

#58

Post by whytevuhuni »

defen wrote: post #44
whytevuhuni wrote: post #35

Earlier quoted context omitted.

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…

Rust also has runtime panics (e.g. indexing outside the bounds of a slice) - how does kernel Rust handle that?

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.

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

#59

Post by marssaxman »

dima55 wrote: post #11
ziddoap wrote: post #8

Earlier quoted context omitted.

Consider this part of the post: > I've been building a debugger on my nights and weeks because it's fun

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.

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?

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

#60

Post by AndyKelley »

whytevuhuni wrote: post #35
mplemay wrote: post #30

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.

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…

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

Post reply on HN