Unused unexported methods kept by DCE when using plugins

[Pierre Gimalac]

Hello,

I noticed that when importing the std "plugin" package then (some ?) unexported methods are kept in the binary.

Disclaimer it's something I only observed on a complex binary, I could not make a minimal reproducible example, so I'm probably misunderstanding something.

When using `-ldflags=-dumpdep` on my complex binary I was seeing something like `type:*text/template.Template -> text/template.(*Template).execute`, so just having the type `Template` makes the unexported method reachable. It disappeared when removing the "plugin" import.

I believe the associated code in the linker is https://github.com/golang/go/blob/go1.23.6/src/cmd/link/internal/ld/deadcode.go#L455.

We can see that if we have reflect and the binary is dynamically linked (with plugin or shared build modes), then unexported methods are also kept. Note that when `dynlink` is true then `reflectSeen` is also set to true, so I think you actually don't even need to use reflect for that to happen.

I'm curious why ? The documentation of `Plugin.Lookup` says the symbol must be exported https://pkg.go.dev/plugin#Plugin.Lookup .

I would have expected the first part of the condition to be `m.isExported() && (d.reflectSeen || d.dynlink)` instead.

This makes binaries importing "plugin" (and probably plugins and shared builds too) significantly bigger, in my case removing the "plugin" import reduced the size of various binaries by around 30%.

See https://github.com/containerd/containerd/issues/11202 and https://github.com/DataDog/datadog-agent/pull/32538 for details.

Thanks !

Pierre.

[Ian Lance Taylor]

As the comment in the linker code says, the linker is ensuring that
all methods of any reachable interface are kept. An interface can have
unexported methods, and in the general case we must keep any method
that may satisfy that interface.

Ian

[Pierre Gimalac]

But in that case why would that only happen for dynamic builds ?

Shouldn't all unexported methods also be kept for the "normal" build ?

Pierre.

[Ian Lance Taylor]

On Tue, Feb 11, 2025 at 1:57 AM Pierre Gimalac
<pierre....@datadoghq.com> wrote:
>
> But in that case why would that only happen for dynamic builds ?
> Shouldn't all unexported methods also be kept for the "normal" build ?

In a normal build the linker can see all the code in the program, so
it knows whether something is possible. In a dynamic build it doesn't
know.

Ian

[Pierre Gimalac]

I stumbled on https://go-review.googlesource.com/c/go/+/393365 which explains why plugins need to keep unexported methods.

Thanks for taking the time to answer my questions, have a good day !