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/compile: incorrect/confusing pkg prefix on unexported fields of anonymous struct #70963

Open
ajwerner opened this issue Dec 22, 2024 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@ajwerner
Copy link

Go version

go 1.23

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/ajwerner/.cache/go-build'
GOENV='/home/ajwerner/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/ajwerner/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/ajwerner/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/ajwerner/sdk/go1.23.2'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/ajwerner/sdk/go1.23.2/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.2'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/ajwerner/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/ajwerner/src/github.com/DataExMachina-dev/side-eye/play/go.mod'
GOWORK='off'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1402138110=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I observed that in DWARF, anonymous struct type names carry unexported field names with package path prefixes. See the below program:

https://go.dev/play/p/96lCdrfHAh3

The type is:

struct { baz int32; Qux int }

But in DWARF, the type is:

struct { play.ground/foo.baz int32; Qux int }

What did you see happen?

In dwarf, the fields in anonymous struct have a package path prefix.

What did you expect to see?

I expected in dwarf for the type to have the same name as it has in pclntab and upon runtime reflection. Maybe there's a good reason for this, but it's not obvious what that might be.

This has caused confusion for users of delve (go-delve/delve#1521).

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Dec 22, 2024
@gabyhelp
Copy link

Related Issues

Related Code Changes

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

@ajwerner
Copy link
Author

ajwerner commented Dec 22, 2024

The relevant change that introduced this behavior is https://go-review.googlesource.com/c/go/+/27791, and it makes sense for the compiler internals. This issue is just asking that the name that gets formatted into DWARF match that that gets used internally at reflection-time etc for consistency. In that context, there's no risk of ambiguity in that the type references are by debug info offsets. It will lead to a situation whereby multiple structure types will have the same name -- something I don't think is currently possible.

Perhaps ultimately the resolution here is "Won't Fix", but I hope this issue can serve as documentation for future folks who end up confused by the existing behavior.

@prattmic
Copy link
Member

cc @mknyszek as you were just noticing this in viewcore.

@cherrymui cherrymui added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Debugging labels Dec 23, 2024
@cherrymui cherrymui added this to the Backlog milestone Dec 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants