Skip to content

Support for Go Build IDs in buildid command #27

@linrl3

Description

@linrl3

Problem Description

The current parca-debuginfo buildid command only recognizes GNU build IDs stored in the .note.gnu.build-id ELF section. However, Go binaries store their build IDs in a different section called .note.go.buildid, which causes the tool to report "no build ID" even when a valid Go build ID is present.

Current Behavior

$ ./dist/parca-debuginfo buildid ./dist/parca-debuginfo
get Build ID for "./dist/parca-debuginfo": no build ID

However, the Go build ID is clearly present:

$ file ./dist/parca-debuginfo
./dist/parca-debuginfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ... Go BuildID=evv_okEzTtx4_0g2pG2aj/9GRgoRTKMyH5iavG2Hnz/FFkCniZ_jhbHSO9rY_9q/TFnE3V1_jFBYBfy-V8Xm ...

$ go tool buildid ./dist/parca-debuginfo
evv_okEzTtx4_0g2pG2aj/9GRgoRTKMyH5iavG2Hnz/FFkCniZ_jhbHSO9rY_9q/TFnE3V1_jFBYBfy-V8Xm

Root Cause

The GetBuildID() function in cmd/parca-debuginfo/main.go:518-528 only looks for build IDs in:

  1. .note.gnu.build-id section (GNU build ID)
  2. .notes section (fallback)

But Go binaries store their build IDs in .note.go.buildid section instead.

Proposed Solution

I would like to enhance the GetBuildID() function to also check for Go build IDs when GNU build IDs are not found. This would involve:

  1. Adding support to read from .note.go.buildid section
  2. Parsing the Go build ID format (which is different from GNU format)
  3. Maintaining backward compatibility with existing GNU build ID support

Benefits

  • Better support for Go binaries in the Parca ecosystem
  • More comprehensive build ID detection
  • No breaking changes to existing functionality
  • Improved user experience for Go developers using parca-debuginfo

Would you be open to accepting a pull request that adds Go build ID support to the buildid

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions