As explained in the README, it's still very early-days and it's not ready for use yet, but check back often because it's improving all the time!
Check out https://calabro.io/uscope for a more detailed explanation.
Thanks for taking a look!
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 crashing of course), but I dont know anything better. I am forced to use visual studio at work and its debugger really sucks - it can't even compare strings in conditional breakpoint, it cant even skip all std::function / std::bind garbage to let me step in callback, it can't watch evaluated expressions. Probably it can evaluate exprs (immediate window?), but there are very little guides about this.
So, gdb is winner for me now. rr (record-repeat)[0] also looks very nice, but it require hardware support(((
[0] https://undo.io/
> 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)
> gdb(..) smashing tui with app output
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..
same way I debug everything, everywhere: logging.
I just got comfortable using gdb/lldb from the terminal. Once you get used to it, it's fine (albeit not pretty).
Before I switched from emacs I had an equivalently good setup with dap-mode.
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
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
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.
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.
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.
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.
> 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
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...
> Build as a library so other people can build other interesting things as well
I firmly believe so much tech has gone to shit because things are no longer hackable. We say "move fast and break things" but we try so hard to prevent that that when we do break things we just create bigger messes and debt, so no one cleans it up. It seems slower to write hackable code but that's in the moment. In the long run it is much faster. Not to mention you get added benefits of others being able to contribute more easily with a lower likelihood of actually breaking shit.
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.
Mentioned at : https://youtu.be/stWBTv6grBc?t=456
https://www.os2museum.com/files/docs/periscope/periscope-man...
To be 100% clear, it's not using gdb/gdbserver under the hood right?
The bugs I linked above are over a decade old, and I have to patch them every time I compile GDB server. Ultimately (IIRC) GDB needs to rework how it handles signals (to their credit, ptrace is a horribly stupid API, especially before PTRACE_SEIZE, so I don't blame them for having issues)
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 bad it really is). And of course ptrace composes somewhat poorly with, well, anything else, so if you want to use perf_event or eBPF to help drive the low-level stuff, well, combining everything into a single event loop is just painful. (Oh, and the documentation for all of this stuff sucks.)
At the medium level, everything is hampered by the number of secret handshakes that go on between the compiler, the linker, the runtime loader, the debugger. And the chronic issue that, in the debugger, you have to be prepared for the possibility that everything is just catastrophically wrong: your stack might be garbage (or downright nonexistent), the thread-local storage register might be a garbage value, variables may have values that don't make sense. After all, you're resorting to a debugger when things don't work, and part of the reason why it might not be working is because you've accidentally corrupted everything.
And at the high level, there's the UI which, as someone who doesn't work on UI, I find terrifying in its own right.
Trying to solve not one of these issues, but all of them, at once, in a new project is ambitious. I'd personally prefer a lot more a project that only tried to tackle one slice of the stack, not all of it.
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.
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 many ways. I think DWARF draws the wrong dividing line here. Control of the machine and customizing the source-level support to the language is probably better.
There can be certain situations where the network latency can make things difficult, but generally speaking I find it an incredibly useful facility to have.
[1]: https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/...
The representation and the compression are far too intertwined :(
If it's fast and can work on snippets before they are even written to disk, we can probably catch many compiler bugs.
:p
raddbg is one worth watching too (currently only Windows x64) https://github.com/EpicGamesExt/raddebugger
the issue is not with gdb's UX - you can build as many cool UI / UX on top of it as you want. The problem is that gdb will sometimes take 5 minutes to start debugging (and that's without debuginfod), straight up crash, be unable to resolve obvious symbols etc. which are all back-end bugs. For me developing a medium-sized C++ app, it's really hell to use and usually printf debugging is MUCH faster in the sense that I have the time to find and fix my problem through an iterative recompile cycle sometimes before gdb has even finished parsing my binary
If you run gdb-add-index on the relevant binaries ahead of time it should start up much faster.
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.
- 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.1As 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 better security and fewer vulnerabilities is worth that much.
On the other hand, Zig is great for user-space applications. The stuff to replace GNU's coreutils with.
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.
How are we better off rewriting it, especially if the rewrite isn't memory safe?
I literally laughed outloud at this. Have you ever actually opened a GDB source file? It is, as a whole, extremely poor quality code. Almost all of it is doing C string manipulation and raw pointer arithmetic; almost none of it uses C++ smart pointers, nevermind the rest of "modern C++"; the vast majority is completely uncommented, and "literal decades of hard earned knowledge" can be better translated as "literal decades of historical baggage, cruft, and hacks". I regularly cause GDB to segfault in normal, mundane operations.
> It's not clear to me why we'd need a new debugger
No one can really predict what's needed and where we need to go, so let people just explore. Sometimes they won't find things, but sometimes they do. And if they don't, they still gain useful knowledge that pays dividends later on anyways.
It's Hacker News, let people hack.
>I've been building a debugger on my nights and weeks because it's fun
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.
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 be a bit verbose, but gives me what I find I need.
What features do you most miss? My experience is that most people use like 1% of the features, so not sure adding more will make a big difference to most people.
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... ?
Then, you can focus on resolving edge cases that can cause papercuts. Make sure the solutions are at the expense of the happy path because that's all been solved long ago so there's no need to pay attention to it.
> Similarly, the following features are non-goals of the project:
> Supporting non-native languages (i.e. Java, Python, etc.)
But I think that position is likely a mistake in terms of leaving killer features on the table and baking in architecture decisions that might continue to make these kinds of features impossible / very low-class experiences.
Properly integrating with the python interpreter to be able to debug python + c/cpp extensions running in the same process is a huge missing whole in the debugger market.
I don't know how other people do it but I 'solve' this problem by attaching either a python debugger or lldb to the python process -- meaning I can debug either python or the cpp but not both at the same time. The experience is very lacking. Even just seeing the python call-stack while paused at a cpp breakpoint would be huge.
If you'd like to try it please get in touch, feedback is always useful.
In general, if something is large (text, arrays, etc) all bets are off.
Basically, something like this:
---
The second thing that is very hard with debuggers, is to tell them what to skip.
In the normal sense of 'I don't wanna debug Rust std' but also 'What the heck, why is stepping into #[Debug]???'
It's a power tool and takes some time and effort to learn and master. Superficially dismissing it / wasting your time with something that in all likelihood will end up going nowhere while lacking most features that make GDB great, does not a good recommendation make.
At least you'll probably learn a thing or two while you implement it, but I'd rather not waste my time using it.
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, please report to the maintainers - i guarantee that you won't be ignored. You say that it's missing some data that you need? Fine, but be precise - what data?
Otherwise it sounds like a "yeah, let's make a project for fun and pretend that it's serious by finding sort-of-justification/use case" (i'm not telling that it is the case for you - i'm telling that it sounds like it, based on your own description).
Also, would you feel nice if i put in my project's README a note that the project of you, the one that you put your effort to, "sucks"?
In this conversation are reports of an annoying bug that requires a user patch gdb and it's existed for almost twenty years.
It was years before anyone was even assigned because of a bug in their bug tracking system, and they haven't addressed any further comments over the decades.
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.