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/link: build golang.org/x/vuln/osv.test fails when -gcflags=all='-N -l' is provided #50200

Closed
hyangah opened this issue Dec 15, 2021 · 10 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker vulncheck or vulndb Issues for the x/vuln or x/vulndb repo
Milestone

Comments

@hyangah
Copy link
Contributor

hyangah commented Dec 15, 2021

Not sure if the problem is the compile command or the link command as it appears while running link.

What version of Go are you using (go version)?

$ go version
go version go1.18beta1 darwin/amd64

Does this issue reproduce with the latest release?

Reproducible only with go1.18beta1
Not observed with go1.17.X

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hakim/Library/Caches/go-build"
GOENV="/Users/hakim/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/hakim/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/hakim/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/hakim/sdk/go1.18beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/hakim/sdk/go1.18beta1/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18beta1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/hakim/vultest/vuln/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bw/6r6k9d113sv1_vvzk_1kfxbm001py5/T/go-build399585180=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Checkout golang.org/x/vuln @ 5e054cb

$ cd osv
$ go test
PASS
ok      golang.org/x/vuln/osv   0.254s
$ go test -gcflags=all='-N -l'
# golang.org/x/vuln/osv.test
2021/12/15 16:40:01 go.opencensus.io/internal: reference to nonexistent package go.opencensus.io
FAIL    golang.org/x/vuln/osv [build failed]

What did you expect to see?

Test passes in both cases.

What did you see instead?

Test fails due to build failure if the -gcflags value is supplied.
(And cannot run dlv test)

go test -gcflags=all='-N -l' -x output
I think the bug appears with -l.

@cherrymui cherrymui changed the title cmd/compile: build fails when -gcflags=all='-N -l' is provided cmd/link: build golang.org/x/vuln/osv.test fails when -gcflags=all='-N -l' is provided Dec 15, 2021
@cherrymui
Copy link
Member

cherrymui commented Dec 15, 2021

Yeah, it seems from the linker. I'll take a look. It might be related to that the package name starts with "go." and doesn't contain a slash. "go." has been a magic name that the compiler uses for its own synthetic symbols.

@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 15, 2021
@cherrymui cherrymui added this to the Go1.18 milestone Dec 15, 2021
@danscales
Copy link
Contributor

danscales commented Dec 15, 2021

This is problem again with our special case in types.NewPkg for packages with the "go." prefix. If I disable that special treatment in NewPkg for packages beginning with "go.", then everything works.

@randall77 , should we make the check directly specific to "go.shape" and the other builtin packages? I feel like we don't have set rules about what can appear in a package path, so an unspecific check may never be quite right.

In particular, I see in go.opencensus.io/internal/check/version.go, you can have an import with no path separator (slash):

import (
       ...

        opencensus "go.opencensus.io"
)

@cherrymui
Copy link
Member

cherrymui commented Dec 15, 2021

I'm a little surprised that it worked before.

@danscales
Copy link
Contributor

danscales commented Dec 15, 2021

The current builtin package names/paths that start with "go." seem to be: go.builtin, go.runtime, go.itab, and now go.shapes. We have special code in NewPkg not to escape package paths beginning with "go.", because we don't want all the shape type names with the period being escaped, as in go%2eshape.int_0

@danscales
Copy link
Contributor

danscales commented Dec 15, 2021

Is the import above

import (
  opencensus "go.opencensus.io"
)

supposed to be illegal? I'm not sure we have set rules.

@cherrymui
Copy link
Member

cherrymui commented Dec 15, 2021

No. I think it is technically legal. "go." has been a magic name for a long time. I'm just surprised that it didn't tripped anything until 1.18.

@danscales
Copy link
Contributor

danscales commented Dec 15, 2021

Then I think we probably need to make the check specific to "go.shape" only. We could do it for all builtin packages, but the paths for the other builtin packages don't show up in the debugger like "go.shape" shows up in the names for shape types.

We only added this special check for 1.18 (to make the shape type names nicer).

@randall77
Copy link
Contributor

randall77 commented Dec 16, 2021

Could we do what this comment suggests?

@danscales
Copy link
Contributor

danscales commented Dec 16, 2021

I think we probably want to focus specifically on "go.shape", which is the only one we care about. Using printfs, I see that

go.builtin has a path of "go.builtin", name ""
go.runtime has a path of "go.runtime", name "runtime"
go.itab has a path of "go.itab", name "go.itab",
go.shape has a path of "go.shape", name of "go.shape"

So, if we check for a dot in the name, we wouldn't be getting all the built-in packages, we would be just getting go.itab and go.shape. So, to me, it seems like we should just check for "go.shape" directly.

@gopherbot
Copy link

gopherbot commented Dec 16, 2021

Change https://golang.org/cl/372934 mentions this issue: cmd/compile: only avoid escaping package paths for "go.shape"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker vulncheck or vulndb Issues for the x/vuln or x/vulndb repo
Projects
Status: No status
Development

No branches or pull requests

6 participants