Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: -gcflags and cached packages #19340

Closed
aarzilli opened this issue Mar 1, 2017 · 6 comments
Closed

cmd/go: -gcflags and cached packages #19340

aarzilli opened this issue Mar 1, 2017 · 6 comments

Comments

@aarzilli
Copy link
Contributor

@aarzilli aarzilli commented Mar 1, 2017

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

This comment has been minimized.

Copy link
Member

@ALTree ALTree commented Mar 1, 2017

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

This comment has been minimized.

Copy link
Contributor Author

@aarzilli aarzilli commented Mar 1, 2017

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

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Mar 1, 2017

Related (possible dup?): #18369

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Jun 5, 2017

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

@rsc rsc added NeedsFix and removed NeedsInvestigation labels Jun 5, 2017
@aarzilli

This comment has been minimized.

Copy link
Contributor Author

@aarzilli aarzilli commented Jun 5, 2017

Great, thank you. I should mention that last week I've discovered that on tip now I can build with both -a and -gcflags="-N -l" together, which provides a workaround for this problem.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Oct 25, 2017

Change https://golang.org/cl/73212 mentions this issue: cmd/go: switch to entirely content-based staleness determination

@gopherbot gopherbot closed this in 7dea509 Oct 31, 2017
@golang golang locked and limited conversation to collaborators Oct 31, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
6 participants
You can’t perform that action at this time.