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

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.

eh, thanks

> How can I persuade my boss to pay for Undo?

fun quote.. but my boss will never pay for it because I am the only one who use gdb in our company, unfortunately)

> How do you people comfortably debug C in Linux?

same way I debug everything, everywhere: logging.

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

The advantage for text based interfaces is that they work over ssh/tmate over trans atlantic connections whereas the GUI tools would suffer greatly. It just works everywhere and if you learn it, it will be just as good as a gui debugger. Potentially even more ergonomic without hunting for options with a mouse.

I‘m using cgdb, which is a minimal ncurses wrapper around gdb. It‘s a lot better than the TUI of gdb.

Termdebug works great with gdb, and I get my usual editor features as well as the full functionality of gdb. Seems fine to me.

Before I switched from emacs I had an equivalently good setup with dap-mode.

Use Emacs to drive gdb (through the GUD mode) gives a much more ergonomic interface. It highlights the line of code being traced in the code window.

as I said - this easy to fix once and for ever

Also not all apps write to stdout/stderr by default.

> How do you people comfortably debug C in Linux ?

It depends on what comfortable is for you. Most of my pc experience is terminal and browser and this is comfortable for me. I just use gdb for debugging. Sometimes trying lldb

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

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

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

very thanks, this will be useful to simplify my debugging!

> and I am also going to include the beginner one, but please do not take that as an indictment of your skill level

Don't worry, I am really feel myself as newbie in windows

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

I don't know if it was deliberate, but writing code that interfaces with GDB is unpleasant enough that I opted to build our debugger-like tooling in eBPF + pyelftools instead.

No, GDB has a pretty good Python extension framework

gdb is a bit old and my comment is really more about building things in general.

You should always make things hackable, not just for others, but for you. One truth to coding is that the final thing will never end up where you think it will. So if you don't make your code flexible (i.e. hackable) then you're going to keep breaking it while fixing it. Things will continue to be patches and quick fixes. Nothing is more permanent than a temporary fix that works.

Truthfully, this is part of the unix philosophy. Make your programs small and integratable. The strategy is not to be finished, because there is no end, the strategy is to be adaptable, because there is no end.

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.

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.

Which debuggers do you like the most?

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.