cmd/go: -gcflags and cached packages

[aarzilli]

Delve builds its binaries using -gcflags='-N -l' to disable inlining and optimizations. This works well until the user separately does a go install or a go build -i at which point any subsequent build will pick up the cached version of all unchanged dependencies, built with optimizations turned on, leading to surprising behavior.

Attempting to circumvent this problem by passing -a to build fail because of #18774.

Considering that #18774 has existed for a while (the first reference I found is #12055) would it be possible to make build pick up cached packages only when compiler flags match, making an exception for runtime?

[ALTree]

make build pick up cached packages only when compiler flags match

This looks related to the discussion in issue #14319, in particular this comment about making -N part of the build signature:

There's also the question of what should happen if you mix packages compiled with and without -N and whether -N should be part of the build signature. I think it's safe to mix packages as long as there are no "go:nosplit" functions in the user packages (auto-nosplit should be fine, since their bound is small and fixed) and user code can't directly call nosplit runtime functions with large frames (which I think is true). That's a lot of "if"s, and it's also strange that the same build command can result in different binaries depending on which packages are clean. To me, this indicates -N should be part of the build signature. I'm not sure if we do that for other flags.

Looks like the discussion in the old thread stalled, though. (And that issue is in the unplanned milestone)

[aarzilli]

That comment wouldn't fully solve the problem however, even if build didn't mix packages built with and without -N it still couldn't build runtime with -N.

[josharian]

Related (possible dup?): #18369

[rsc]

Work on better caching will fix this. I have a prototype. Not for Go 1.9 but probably for Go 1.10.