Hacker News Reader

Comment by anonacct37 | Hacker News Reader

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.

View on HN

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

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.

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?

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.

Reply on news.ycombinator.com