111–120 of 133 posts
Earlier quoted context omitted.
Is gdb another thing like gcc where the un-hackability and un-extendability was a deliberate choice by rms to ensure nobody would ever build proprietary toolchains on top of it?
No, GDB has a pretty good Python extension framework
> 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..
Earlier quoted context omitted.
Out of interest what are your main use cases for needing conditional breakpoints?
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/curre…
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.
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.
Sure, there will always be some races/timing issues that just won't repro under recording (Heisenberg principal and all that), but in fact most races are _more likely_ to occur under recording. Part of this is because you slow down the process being recorded, which is equivalent to speeding up the outside world.
And of course, when you do have your gnarly timing issue captured in a recording, it's usually trivial to root-cause exactly what happened. Our customers tell us that races and timing issues are a major use-case.
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.
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.
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…
It's been a while since I bothered to try to use it because my experience has been so bad. So I don't remember all my specific complaints about bugs and features. I do remember multi process debugging was a big hole last time I looked. In contrast, I was able to get multi process debugging working really well in Visual Studio. By terrible API I mean GDB/MI that frontends use. I'm sure people will come try to defend i…
e.g. it now has decent multi-process support.
I agree MI is kinda horrid, but no need for it these days, you can do everything via the Python API, and the modern equivalent is Debug Adapter Protocol which GDB claims to support now (although I haven't tried).
There a million frontends, including both Visual Studio (via ssh) and VSCode, if you like those.
The perfect developer tool does not exist, but I believe that if you're debugging native code on Linux more than a few times per year then you should really know how to drive GDB. It won't always be the best tool for the job, but it often will be.
> 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…
> 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
> 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..
Before I switched from emacs I had an equivalently good setup with dap-mode.
Earlier quoted context omitted.
> 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. the issue is not with gdb's UX - you can build as many cool UI / UX on top of it as you wa…
> The problem is that gdb will sometimes take 5 minutes to start debugging If you run gdb-add-index on the relevant binaries ahead of time it should start up much faster.