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

gccgo: confusing closure names #29690

Open
cherrymui opened this issue Jan 11, 2019 · 1 comment
Open

gccgo: confusing closure names #29690

cherrymui opened this issue Jan 11, 2019 · 1 comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@cherrymui
Copy link
Member

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

gccgo2 (GCC) 9.0.0 20190108 (experimental)

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

Linux/AMD64

What did you do?

package main

type T struct {
	closure1, closure2 func()
}

func (t *T) M1()  { t.closure1 = func() { t.closure2() } }
func (t *T) M2()  { t.closure2 = func() { panic("XXX") } }

func main() {
	var t T
	t.M1()
	t.M2()
	t.closure1()
}

Built with gccgo, this program prints

panic: XXX

goroutine 1 [running]:
panic
	/tmp/src/gccgo/libgo/go/runtime/panic.go:588
main.func1
	/tmp/c.go:8
main.func1
	/tmp/c.go:7
main.main
	/tmp/c.go:14

The closures on line 7 and 8 are different functions, yet have the same name, which is confusing. It is ok that closures have somewhat artificial names, but it is super confusing if different closures have the name.

It appears to me (without checking the source code) that if the closures are defined in global scope or inside a function (NOT method), they are properly named as package_name.funcN or package_name.function_name.funcN with proper N. However, if they are defined in methods, they are all named package_name.funcN with N starting from 1 in each method. In this case, the two closures are defined in two different methods, and both named main.func1.

cc @ianlancetaylor @thanm

@gopherbot gopherbot added this to the Gccgo milestone Jan 11, 2019
@ianlancetaylor
Copy link
Contributor

The symbols do have different names in the object file: main..1main.T.M1..func1 and main..1main.T.M2..func1. (These names are set by Gogo::nested_function_name in names.cc). But the names in the debug info are indeed both main.func1. I think the confusion is happening in Named_object::get_id; I think that does an unfortunate munging of the full names.

@julieqiu julieqiu added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 28, 2019
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.
Projects
None yet
Development

No branches or pull requests

4 participants