SYSTEM Cited by 1 source

whydeadcode

whydeadcode (github.com/aarzilli/whydeadcode) is an OSS tool that consumes the Go linker's -dumpdep output, determines whether method dead-code elimination is disabled, and — if so — prints the call chain that killed it.

Invocation

go build -ldflags=-dumpdep |& whydeadcode

The linker's -dumpdep flag prints why each symbol is reachable; whydeadcode scans for the telltale reflect-MethodByName pessimism signature and names the first culprit.

Example

From the 2026-02-18 Datadog post, a two-line program using text/template:

tmpl, _ := template.New("tmpl").Parse("{{.Error}}\n")
tmpl.Execute(os.Stdout, errors.New("some error"))

whydeadcode output:

text/template.(*state).evalField reachable from:
   text/template.(*state).evalFieldChain
   text/template.(*state).evalCommand
   text/template.(*state).evalPipeline
   text/template.(*state).walk
   text/template.(*Template).execute

Operational caveat

"Only the first displayed call stack is guaranteed to be a true positive" — so the safe pattern is an iterative fix loop:

1. Run whydeadcode.
2. Fix the top call-chain offender (remove the dynamic reflect.MethodByName path, or isolate it behind a build tag / package split).
3. Re-run whydeadcode.
4. Repeat until output is empty → method DCE is enabled.

Seen in

• sources/2026-02-18-datadog-how-we-reduced-agent-go-binaries-up-to-77-percent — tool used across ~a dozen dependency patches to iteratively re-enable method DCE; also localised the plugin-mode regression by showing an unexported method reachable on amd64 but not arm64.