/ go Public
cmd/link: generate external DWARF debuginfo archives directly #51692
Issues related to the Go compiler and/or runtime.
TL;DR: Add an
-external-debuginfocommand line argument to
go tool linkthat causes the
linkcommand to write a
.debugarchive containing symbol tables and DWARF debuginfo for the executable being linked.
-swill continue to have their current effects on the output executable. These flags will have no effect on the archive produced by
-external-debuginfo, which will always include the full symbol table and DWARF debuginfo.
This could be implemented by using the functionality of elfutils
For Windows targets a
.pdbfile could be produced, or external debuginfo support for Windows targets could be initially omitted if it's too hard to do at the same time.
Kubernetes project binaries and container images are currently built and distributed with the
-w -slinker flags, so DWARF debuginfo is omitted then the executable is stripped of all symbols.
This saves disk space by producing smaller binaries and container images, though it has no memory consumption or performance benefit at executable runtime.
The cost is that debugging such executables is extremely difficult - only numeric addresses are available, with no symbols for functions, variables, etc. If a problem only occurs in a production or near-production system and you want to inspect the running component, you will see backtraces like:
In traditional gcc or llvm based C/C++ build tool chains a balance between executable size and debuggability is maintained using external debuginfo archives. These are supported by
lldband anything using
libgdbfor symbol loading. Delve supports loading of external symbols from
gdband other tools.
ld.lldprovide a command line argument for writing external debuginfo archives. Instead the release process for most binaries includes a separate pass to split the original executable with debuginfo into separate stripped executable and debuginfo archive files using
The golang toolchain tries to be an integrated single-stop shop without external linker dependencies etc, so golang projects including the official k8s distribution don't tend to use this workflow. They're release-size conscious so they just don't provide any debuginfo. They just build stripped binaries for release. This is convenient but makes it much more difficult to diagnose problems.
go/linkshould instead support directly generating an external debuginfo archive ready for upload to a debuginfod symbol server, inclusion in a container image's
/usr/lib/debug/.build_idtrees, and/or distribution in release tarballs.
delvealready supports debuginfod. If
go/linkprovided an easy way to generate external symbol archives, the k8s project or an interested 3rd party could host a public debuginfod with debuginfo for all future release binaries for use in
For example in gdb, one might add
set debuginfod enabledto
.gdbinit, and have symbols automatically downloaded on demand when debugging k8s release binaries. Even over a remote
gdbserver. A similar approach is possible with Delve.
Symbols can also be downloaded on-demand from a debuginfod with
eu-unstripthen used as normal local detached symbol archives, and
eu-make-debug-archivecan be used to make a full archive of a system or container's libraries and debuginfo for remote debugging use. But the symbols must be available for that to be possible.
Golang binaries can be built with debuginfo and symbols (neither
LDFLAGSshould be used) then split into separate debuginfo with
eu-stripfor linux targets.
This requires each build script to implement features that require dependencies that aren't part of the main go toolchain. So it's unlikely to see wide adoption until and unless the golang toolchain itself provides a standard way to do it like it has with
-sfor stripped executables.
But it's not overly complicated:
will yield a stripped
mybinwith embedded external debuginfo link and a detached debuginfo
mybin.debugis placed in the appropriate location in
/usr/lib/debug/.build_id, and/or on a debuginfod server, tools like
gdbwill automatically find its symbols when attaching to it.
The text was updated successfully, but these errors were encountered: