Skip to content

proposal: debug/buildinfo: export errNotGoExe #67845

@hdonnay

Description

@hdonnay

Go version

go1.23-9b43bfbc51

Output of go env in your module/workspace:

N/A

What did you do?

Resorted to //go:linkname tricks to get at this value. (link)

What did you see happen?

N/A

What did you expect to see?

Without exporting buildinfo.errNotGoExe, a user must effectively re-implement the debug/buildinfo package to determine if an executable is a Go executable and if so, read data to hand to runtime/debug.ParseBuildInfo. If the user doesn't want to copy the logic that decodes the .go.buildinfo (or equivalent) section, the executable ends up needing to be parsed twice to check for the section and magic string.1 Additionally, a user would be unable to use the internal/saferio helper.

Returning an exported error (or an error that evaluates correctly to a sentinel error with errors.Is) allows a caller to distinguish between a file that should have valid build info (!errors.Is(err, buildinfo.errNotGoExe)) and a file that's not expected to (errors.Is(err, buildinfo.errNotGoExe)) when the process can't "know" that a-priori.

Footnotes

  1. Because sections may be compressed, something like a bitstring search over the file isn't a reliable rule-in/rule-out criteria. To look for a Go-specific section (like .go.buildinfo or .note.go.buildid in the case of ELF) requires parsing the binary and throwing that work away to have debug/buildinfo parse it again.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FeatureRequestIssues asking for a new feature that does not need a proposal.GoCommandcmd/goNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Proposal

    Type

    No type

    Projects

    Status

    Incoming

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions