3 ms·

interesting, is the current situation one of the reason Go debugging experience is so poor? Delve debugger is constantly crashing for me, making step debugging

interesting, is the current situation one of the reason Go debugging experience is so poor? Delve debugger is constantly crashing for me, making step debugging extremely hard, especially when debugging tests. If there is one thing that is inferior to Java and C# with Go it's definitely the debugging experience.

arghwhat 9y ago
Not at all. Non-cooperative goroutines would make it much harder to implement a debugger. Delve crashing is just related to Delve being buggy. Single-stepping is done at the instruction level, and the task of a Go debugger mostly relates to mapping instructions to source code, and understanding the runtime. You can debug Go with gdb, but without Go runtime comprehension, all you will see is a bunch of worker threads executing Go runtime code, rather than the individual goroutines of your process.
anonacct37 9y ago
I've actually never run into a problem debugging go binaries with gdb. Which is weird because everyone's always told me it doesn't work. I'm sure there are edge cases but over the last 5 years or so my experience has been pretty good. emacs + gud mode is a great experience for go debugging. I've even used it to debug low-level issues like plugin loading and verification.
- isaachier 9y ago
  On Mac, I find lldb is terribly low level. IIRC Linux gcc isn't great either. Even delve will frequently seem to have missing/optimized variables that cannot be printed.
  - yorwba 9y ago
    I frequently hit the problem with variables that are <optimized out> when debugging C code using gdb, and it's especially infuriating when I can look at the disassembly and see that the variable is right there in the register file. Does anyone know whether dwarf simply doesn't support the necessary debug information or whether compilers just don't retain it through the optimization process?
    - twoodfin 9y ago
      The latter. With quality register allocation, the same register can be used for multiple variables (or unnamed intermediate results) within the span of a few instructions. The inverse is also true: the same variable could find its value in multiple registers. DWARF appears to support mapping symbol locations to registers, but I’ve never seen a language environment/debugger that takes advantage of it for optimized binaries.
- nostalgeek 9y ago
  > I've actually never run into a problem debugging go binaries with gdb. Are you able to step inside code running in a goroutine? with GDB? Because it's where GDB starts to become useless for debugging.

arghwhat 9y ago

Not at all. Non-cooperative goroutines would make it much harder to implement a debugger. Delve crashing is just related to Delve being buggy. Single-stepping is done at the instruction level, and the task of a Go debugger mostly relates to mapping instructions to source code, and understanding the runtime. You can debug Go with gdb, but without Go runtime comprehension, all you will see is a bunch of worker threads executing Go runtime code, rather than the individual goroutines of your process.

anonacct37 9y ago

I've actually never run into a problem debugging go binaries with gdb. Which is weird because everyone's always told me it doesn't work. I'm sure there are edge cases but over the last 5 years or so my experience has been pretty good. emacs + gud mode is a great experience for go debugging. I've even used it to debug low-level issues like plugin loading and verification.

isaachier 9y ago
On Mac, I find lldb is terribly low level. IIRC Linux gcc isn't great either. Even delve will frequently seem to have missing/optimized variables that cannot be printed.
- yorwba 9y ago
  I frequently hit the problem with variables that are <optimized out> when debugging C code using gdb, and it's especially infuriating when I can look at the disassembly and see that the variable is right there in the register file. Does anyone know whether dwarf simply doesn't support the necessary debug information or whether compilers just don't retain it through the optimization process?
  - twoodfin 9y ago
    The latter. With quality register allocation, the same register can be used for multiple variables (or unnamed intermediate results) within the span of a few instructions. The inverse is also true: the same variable could find its value in multiple registers. DWARF appears to support mapping symbol locations to registers, but I’ve never seen a language environment/debugger that takes advantage of it for optimized binaries.
nostalgeek 9y ago
> I've actually never run into a problem debugging go binaries with gdb. Are you able to step inside code running in a goroutine? with GDB? Because it's where GDB starts to become useless for debugging.