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

Jump to bottom

cmd/link: bad decoding of R_USEGENERICIFACEMETHOD relocation #54346

Closed
mdempsky opened this issue Aug 9, 2022 · 6 comments
Closed

cmd/link: bad decoding of R_USEGENERICIFACEMETHOD relocation #54346

mdempsky opened this issue Aug 9, 2022 · 6 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.20

Comments

@mdempsky
Copy link
Member

mdempsky commented Aug 9, 2022

At commit 228f891, running the test program below with go run fails with "fatal error: unreachable method called. linker bug?".

I think there's something wrong with parsing the R_USEGENERICIFACEMETHOD relocation:

$ go build -ldflags=-v=2 bug.go |& grep --text reached.generic | cat -v
reached generic iface method: x^@^@^@^@^@^@^@

Presumably the trailing zero bytes then causes it to fail to preserve the x method in the itabs.

Note the trailing zero bytes in the method name, which presumably go onto causing the x method to get trimmed.

Renaming the method seems to avoid the issue. Though notably, I initially ran into the issue with GOEXPERIMENT=unified and a method named g, and assumed it was an issue on my end. So it's not specific to just x.

Trimming down the imports also seems to break the failure.

package main

import (
	_ "os"
)

func main() {
	foo := Foo[int]{}
	foo.f4()
}

type Foo[T int] struct{}

func (l *Foo[T]) f4() {
	var h G[T] = l
	h.x()
}

func (l *Foo[T]) x() {}

type G[T int] interface {
	x()
}

/cc @golang/compiler
@mdempsky mdempsky added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 9, 2022
@mdempsky mdempsky added this to the Go1.20 milestone Aug 9, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 9, 2022
@cherrymui
Copy link
Member

I'll take a look.

@cherrymui
Copy link
Member

Is this specific to commit 228f891 ? I cannot reproduce on tip (9c5cae0). Maybe something changed? Or you checked in a CL that works around it? Thanks.

@cherrymui
Copy link
Member

cherrymui commented Aug 9, 2022 •
edited

It also doesn't fail with Go 1.19. It fails at 0d9ed06, and doesn't fail at e1a8e0e (immediate following commit).
Maybe it is not a linker bug?

@cuonglm
Copy link
Member

cuonglm commented Aug 9, 2022 •
edited

The commit introduces the bug is c3833a5, then it was reverted by commit e1a8e0e

cc @randall77

@mdempsky
Copy link
Member Author

mdempsky commented Aug 9, 2022

Is this specific to commit 228f891 ?

I think it's an issue that's very narrowly reproducible.

Note that at patchset 5 of https://go-review.googlesource.com/c/go/+/421821 (commit 845060b20c5888b7b1c5de1dace845058bff2028, which includes e1a8e0e and ad0287f), test/typeparam/issue48042.go is still failing on the trybots. So I don't think it's related to the heap bitmaps changes.

I have a meeting in a second, but I can give fuller repro notes shortly.

@gopherbot
Copy link

Change https://go.dev/cl/422300 mentions this issue: cmd/compile: do not use content addressable symbol for generic iface method names

@golang golang locked and limited conversation to collaborators Aug 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.20
Development

No branches or pull requests
4 participants
@mdempsky @cuonglm @gopherbot @cherrymui