8 ms·

I think there are a few sides to this problem: 1. Debuggers are in some sense anti-unix. They only work well when they are thoroughly integrated with the rest

I think there are a few sides to this problem: 1. Debuggers are in some sense anti-unix. They only work well when they are thoroughly integrated with the rest of your environment. Trying to have some debugger program like gdb and then talking to it from emacs or a terminal or something will be a big pain. Emacs is also anti-unix but seems to have enough mass that it doesn’t matter so much (or maybe the debugger and emacs fighting for importance is problematics) 2. Getting a debugger to work well is hard. Apart from needing information to work out what bit of code is executing (and passing all that information through weird compilation steps or linking), the debugger needs to understand the memory layout of objects and interpret some subset of the language so that people can enter eg watch expressions. This is hard when the compiler and debugger are quite separate and just agree on the format for possible debug information. Lack of integration hurts again 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? I guess Java too? Lots of people end up debugging with prints and that just isn’t so effective. I think I’ve barely used a debugger for more than trivial websites in the last 10 years. 4. The problem of debugging has become harder: there are now more threads in programs and it is more common for languages to have some kind of async mechanism. If you naively debug that, you’ll see crap stacktraces (a few frames sat atop a scheduler) and execution may move randomly between threads in a pool. I feel like most debuggers can’t cope. (I guess website debuggers do understand async better and there are also new inventions like reversible debugging with rr, but the problem with integrating a debugger with a language or an editor remains.)

jcelerier 6y ago
> 1. Debuggers are in some sense anti-unix. it's not a problem when you accept that the unix philosophy is extremely far from the holy grail of software design. "things that do one thing well" certainly has good sides for specific problems, mainly quick'n'dirty linear text processing dataflows, but is atrocious for other problems (anything that need integration and discoverability: art software, web browsers, or revolves more around user interaction than computing something) > 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? if debuggers took less time to start than a full "add print -> recompile -> relaunch app" cycle as is my experience with C++, they would certainly get more use. Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow.
- DoofusOfDeath 6y ago
  > Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow. I'm really surprised. In my experience it's really rare for either of those debuggers to crash, let alone for both to crash on the same target. A bit of a tangent, but would you mind sharing some details about your compiler / OS / debugger / target-hardware versions?
  - tkinom 6y ago
    Same here. CLI version of gdb has worked extremely reliable for me across multiple projects and architectures (x86, arm, arm64, etc). I have yet to encounter a bug can't be debug with gdb with some test automation + gdb script with conditional breakpoints / hw breakpoints. As long as I can reproduce the issue with test automation, I can debug it with gdb. Most complex bugs are I have to debug was multiple threads (20+) memory leak shows up after days of testing. I don't use GUI gdb. cli + gdb script is the best and most reliable debugging environment. I don't add printf to my code anymore, a new gdb breakpoint script + with proper debug build can replace the printf anywhere and anytime.
    - TwoBit 6y ago
      No offense but I'm guessing your debugging needs aren't as complicated as some others' needs.
  - jcelerier 6y ago
    amd64 arch linux, so latest version of clang++ and gdb/lldb. Project built against c++20. Here's what I'm getting from gdb: https://twitter.com/jcelerie/status/1348259387127824387/photo/1 https://twitter.com/jcelerie/status/1348259387127824387/phot... (lldb does not give me an error message, just segfault)
    - DoofusOfDeath 6y ago
      Interesting. I just took a look at the line of gdb code that's crashing on you. I'm only slightly familiar with gdb's internals, but I can imagine a bunch of different sources for this bug: - gdb has a misconception about which c++ ABI was used when compiling the target program, or - your program is stomping on an object's vtable pointer, leading gdb to follow invalid pointers when trying to parse the object's RTTI, or - there's a bug in clang++, or - there's a mix of abi versions in your program's code, perhaps because of unexpected linking issues (static or dynamic), or perhaps because of inconsistent compiler flags when building your code I'm curious what happens if you build your program with g++ instead of clang++.
greggman3 6y ago
> Getting a debugger to work well is hard And yet somehow Microsoft made theirs work well since the early 90s
alexhutcheson 6y ago
> Trying to have some debugger program like gdb and then talking to it from emacs or a terminal or something will be a big pain. If you're already familiar with Emacs commands, then the M-x gdb interface is as good as any debugger interface in an IDE. If you're not already an Emacs user, then the TUI[1] (gdb -tui) is surprisingly good - much better than the "old school" approach I was taught in college of just interacting via the gdb prompt. > Debuggers work well for what, windows and websites? I spend most of my time on a large C++ project that does neither of these things, and I still use gdb a lot. In my experience, it's most useful for unit tests - you identify a bug, write a unit test that triggers the bug, and run the unit test under gdb to poke around and understand what's going on. gdb and lldb don't work great when run on the whole program, mainly because it's hard to specify the actual behavior you want when debugging a system where multiple threads are executing concurrently. Almost all of our unit tests are single-threaded, so this isn't a problem when debugging unit tests. If you're working on a C or C++ program and using a supported processor, I also highly recommend trying out rr[2], the record and replay debugger, which you mentioned in your comment. Unlike gdb, it's reasonably easy to use and understand even if your program has lots of concurrency, and it pretty much eliminates the need to do "printf" debugging, since you can print variables from any line in your program without recompiling and re-running. You can still use the Emacs or TUI gdb interfaces when using "rr replay". [1] https://sourceware.org/gdb/current/onlinedocs/gdb/TUI.html#TUI https://sourceware.org/gdb/current/onlinedocs/gdb/TUI.html#T... [2] https://rr-project.org/ https://rr-project.org/
- yakubin 6y ago
  >> Debuggers work well for what, windows and websites? > I spend most of my time on a large C++ project that does neither of these things, and I still use gdb a lot. I think that, when GP wrote "windows", they meant the operating system. And when they wrote "debuggers work well", they meant the quality of debuggers, not whether using a debugger is a good idea. Quality of Windows debuggers is generally on a whole other level than on Linux. Chromium DevTools also has a nice debugger. I don't know about Java.
  - dan-robertson 6y ago
touisteur 6y ago
About composability since I've taken to fuzzing I've been improving my gdb chops and now I mostly write gdb scripts if the program is not too long to run, or I just use a simple bisect script with with core dump checkpointing and detecting changes of whatever I'm interested in. With a large tmpfs it's quite fast and modular. If I'm doing real-time, Intel PT is great, especially if you can afford the signal-shit happening when dumping core (you get Intel PT trace in core dumps now and gdb supports them if compiled with...)
majormajor 6y ago
> 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? I guess Java too? Lots of people end up debugging with prints and that just isn’t so effective. I think I’ve barely used a debugger for more than trivial websites in the last 10 years. They're extremely useful for dynamic languages (Python, Ruby, etc) since you can step through call chains and see the full objects being passed around. Wonderful way to learn a new codebase where you have a bunch of functions passing stuff around with no type information in the code. The debugger is the main reason you're not gonna pull me away from IntelliJ for JVM or dynamic language stuff... it could be even better - like how CLion is discussed - but I'm not seeing a better debugger-less alternative. Hooking into async callback stuff and losing useful stacktraces isn't great, but it's not like print statements are gonna do any better there either...

jcelerier 6y ago

> 1. Debuggers are in some sense anti-unix. it's not a problem when you accept that the unix philosophy is extremely far from the holy grail of software design. "things that do one thing well" certainly has good sides for specific problems, mainly quick'n'dirty linear text processing dataflows, but is atrocious for other problems (anything that need integration and discoverability: art software, web browsers, or revolves more around user interaction than computing something) > 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? if debuggers took less time to start than a full "add print -> recompile -> relaunch app" cycle as is my experience with C++, they would certainly get more use. Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow.

DoofusOfDeath 6y ago
> Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow. I'm really surprised. In my experience it's really rare for either of those debuggers to crash, let alone for both to crash on the same target. A bit of a tangent, but would you mind sharing some details about your compiler / OS / debugger / target-hardware versions?
- tkinom 6y ago
  Same here. CLI version of gdb has worked extremely reliable for me across multiple projects and architectures (x86, arm, arm64, etc). I have yet to encounter a bug can't be debug with gdb with some test automation + gdb script with conditional breakpoints / hw breakpoints. As long as I can reproduce the issue with test automation, I can debug it with gdb. Most complex bugs are I have to debug was multiple threads (20+) memory leak shows up after days of testing. I don't use GUI gdb. cli + gdb script is the best and most reliable debugging environment. I don't add printf to my code anymore, a new gdb breakpoint script + with proper debug build can replace the printf anywhere and anytime.
  - TwoBit 6y ago
    No offense but I'm guessing your debugging needs aren't as complicated as some others' needs.
- jcelerier 6y ago
  amd64 arch linux, so latest version of clang++ and gdb/lldb. Project built against c++20. Here's what I'm getting from gdb: https://twitter.com/jcelerie/status/1348259387127824387/photo/1 https://twitter.com/jcelerie/status/1348259387127824387/phot... (lldb does not give me an error message, just segfault)
  - DoofusOfDeath 6y ago
    Interesting. I just took a look at the line of gdb code that's crashing on you. I'm only slightly familiar with gdb's internals, but I can imagine a bunch of different sources for this bug: - gdb has a misconception about which c++ ABI was used when compiling the target program, or - your program is stomping on an object's vtable pointer, leading gdb to follow invalid pointers when trying to parse the object's RTTI, or - there's a bug in clang++, or - there's a mix of abi versions in your program's code, perhaps because of unexpected linking issues (static or dynamic), or perhaps because of inconsistent compiler flags when building your code I'm curious what happens if you build your program with g++ instead of clang++.

greggman3 6y ago

> Getting a debugger to work well is hard And yet somehow Microsoft made theirs work well since the early 90s

alexhutcheson 6y ago

> Trying to have some debugger program like gdb and then talking to it from emacs or a terminal or something will be a big pain. If you're already familiar with Emacs commands, then the M-x gdb interface is as good as any debugger interface in an IDE. If you're not already an Emacs user, then the TUI[1] (gdb -tui) is surprisingly good - much better than the "old school" approach I was taught in college of just interacting via the gdb prompt. > Debuggers work well for what, windows and websites? I spend most of my time on a large C++ project that does neither of these things, and I still use gdb a lot. In my experience, it's most useful for unit tests - you identify a bug, write a unit test that triggers the bug, and run the unit test under gdb to poke around and understand what's going on. gdb and lldb don't work great when run on the whole program, mainly because it's hard to specify the actual behavior you want when debugging a system where multiple threads are executing concurrently. Almost all of our unit tests are single-threaded, so this isn't a problem when debugging unit tests. If you're working on a C or C++ program and using a supported processor, I also highly recommend trying out rr[2], the record and replay debugger, which you mentioned in your comment. Unlike gdb, it's reasonably easy to use and understand even if your program has lots of concurrency, and it pretty much eliminates the need to do "printf" debugging, since you can print variables from any line in your program without recompiling and re-running. You can still use the Emacs or TUI gdb interfaces when using "rr replay". [1] https://sourceware.org/gdb/current/onlinedocs/gdb/TUI.html#TUI https://sourceware.org/gdb/current/onlinedocs/gdb/TUI.html#T... [2] https://rr-project.org/ https://rr-project.org/

yakubin 6y ago
>> Debuggers work well for what, windows and websites? > I spend most of my time on a large C++ project that does neither of these things, and I still use gdb a lot. I think that, when GP wrote "windows", they meant the operating system. And when they wrote "debuggers work well", they meant the quality of debuggers, not whether using a debugger is a good idea. Quality of Windows debuggers is generally on a whole other level than on Linux. Chromium DevTools also has a nice debugger. I don't know about Java.
- dan-robertson 6y ago

touisteur 6y ago

About composability since I've taken to fuzzing I've been improving my gdb chops and now I mostly write gdb scripts if the program is not too long to run, or I just use a simple bisect script with with core dump checkpointing and detecting changes of whatever I'm interested in. With a large tmpfs it's quite fast and modular. If I'm doing real-time, Intel PT is great, especially if you can afford the signal-shit happening when dumping core (you get Intel PT trace in core dumps now and gdb supports them if compiled with...)

majormajor 6y ago

> 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? I guess Java too? Lots of people end up debugging with prints and that just isn’t so effective. I think I’ve barely used a debugger for more than trivial websites in the last 10 years. They're extremely useful for dynamic languages (Python, Ruby, etc) since you can step through call chains and see the full objects being passed around. Wonderful way to learn a new codebase where you have a bunch of functions passing stuff around with no type information in the code. The debugger is the main reason you're not gonna pull me away from IntelliJ for JVM or dynamic language stuff... it could be even better - like how CLion is discussed - but I'm not seeing a better debugger-less alternative. Hooking into async callback stuff and losing useful stacktraces isn't great, but it's not like print statements are gonna do any better there either...