backendbinary: linux/amd64 check false-negatives non-Go backends (GraalVM/Java, Rust, C++)

[adamyeats]

Summary

The backendbinary linux/amd64 check added in v0.45.0 (#642) determines a binary's architecture from Go build info (debug/buildinfo). Backend plugins whose executable is not a Go binary (e.g. a GraalVM native image compiled from Java) carry no Go build info, so the check skips them and reports Missing linux/amd64 backend binary even when a valid linux/amd64 binary is present.

Affected version

v0.45.0 (latest). Not present in v0.44.x.

Root cause

In pkg/analysis/passes/backendbinary/backendbinary.go, hasLinuxAmd64Binary classifies arch via buildinfo.ReadFile:

info, err := buildinfo.ReadFile(binaryPath)
if err != nil { continue }   // non-Go binary → skipped
// ... GOOS == "linux" && GOARCH == "amd64"

debug/buildinfo only reads Go build metadata. For a non-Go binary it returns an error, the loop continues, and the function returns false, so the analyzer concludes no amd64 binary exists.

Impact

False-positive failures for every backend plugin built with a non-Go toolchain (GraalVM/Java native images, Rust, C++). Because GCOM runs these analyzers at publish time, it blocks both CI (for repos that run the validator) and publishing.

Reproduction

1. Build a backend plugin whose executable is a GraalVM native image (a genuine linux/amd64 ELF), named gpx_<id>_linux_amd64, with "backend": true in plugin.json.
2. Run the backendbinary analyzer over the package.
3. Observed: Missing linux/amd64 backend binary. Expected: pass, since a valid linux/amd64 binary is present.

Suggested fix

When buildinfo.ReadFile fails, fall back to classifying the binary by its executable-format header rather than Go metadata: read the ELF header e_machine (EM_X86_64 → amd64, EM_AARCH64 → arm64) via debug/elf, with debug/macho and debug/pe equivalents for darwin/windows. That classifies any binary by format instead of assuming a Go toolchain.