proc: support debugging stripped non-Go binaries#4263
proc: support debugging stripped non-Go binaries#4263derekparker wants to merge 3 commits intogo-delve:masterfrom
Conversation
Add support for debugging non-Go stub binaries that dynamically load Go shared libraries via dlopen or other dynamic linkage modes. When the initial binary has no Go runtime symbols or DWARF info, Delve now marks it as non-Go and defers Go-specific initialization. A breakpoint on the dynamic linker's _dl_debug_state function detects shared library loads, allowing Delve to pick up Go debug info when a Go .so is loaded at runtime.
|
@Pawloland are you able to confirm if this enables your use case? |
|
The test failures look real. |
- Deduplicate auxv parsing by extracting searchAuxv helper - Rename IsNonGo to IsGo (positive flag is easier to reason about) - Move Go image detection into loadDebugInfoMaps to avoid reparsing debug_info; uses DW_AT_language == DW_LANG_Go which is already checked there for cu.isgo - Remove hasGoProducer function (no longer needed) - Remove pkg/proc import from pkg/terminal/command.go; use string literal for stop reason comparison instead - Update CLAUDE.md with DWARF parsing and layer boundary guidance Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
With non-Go binary debugging support, attaching to PID 1 can succeed in privileged environments (e.g. CI Docker containers running as root) since the binary is now treated as a non-Go process that may load a Go shared library later. Remove this OS-dependent sub-case; the remaining sub-tests cover DAP attach config validation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Ended up removing the failing DAP test as I don't think it's relevant. In the container we can attach to PID 1 and with this change it won't fail if it's non-Go. Locally it passes because when not in container the user typically won't have privileges to attach to PID 1. Used claude code for review feedback, so updated the CLAUDE.md as well with a hint. |
I am positive, that the behavior changed from the previous one as the dlv in server mode now waits for the dlv in client mode for connections instead of closing immediately. As for debugging, it is still not working. I will explain more in golang/go#77484. |
3 participants
Add support for debugging non-Go stub binaries that dynamically load Go shared libraries via dlopen or other dynamic linkage modes. When the initial binary has no Go runtime symbols or DWARF info, Delve now marks it as non-Go and defers Go-specific initialization instead of exiting. A breakpoint on the dynamic linker's _dl_debug_state function detects shared library loads, allowing Delve to pick up Go debug info when a Go .so is loaded at runtime.
Should allow for use cases such as golang/go#77484.