runtime: result of (*runtime.Func).Name is malformed in go1.24

[ShoshinNikita]

go version: go version go1.24.0 linux/amd64

Consider the following code:

package main

import (
	"fmt"
	"runtime"
)

func main() {
	foo()
}

func foo() {
	fmt.Println("0  ", caller())

	func() {
		fmt.Println("1  ", caller())

		func() {
			fmt.Println("2  ", caller())

			func() {
				fmt.Println("3.1", caller())
			}()

			func() {
				fmt.Println("3.2", caller())
			}()
		}()
	}()
}

func caller() string {
	pc, _, _, ok := runtime.Caller(1)
	if !ok {
		return ""
	}

	return runtime.FuncForPC(pc).Name()
}

With go1.23 (https://go.dev/play/p/ZfX43aWfcTe?v=goprev) I get this output:

0   main.foo
1   main.foo.func1
2   main.foo.func1.1
3.1 main.foo.func1.1.1
3.2 main.foo.func1.1.2

With go1.24 (https://go.dev/play/p/ZfX43aWfcTe):

0   main.foo
1   main.foo.func1
2   main.foo.foo.func1.func2
3.1 main.foo.foo.func1.foo.foo.func1.func2.func3
3.2 main.foo.foo.func1.foo.foo.func1.func2.func4

Note the following changes:

1. foo is repeated twice: main.foo.foo.func1.func2
2. Func counter is now bound to top-level function - see func3 and func4

[gabyhelp]

Related Issues

• cmd/compile: runtime `init` chain behaviour is changed after upgraded to 1.12.1 release #31175 (closed)
• runtime: change in Caller prevents detecting program name #23128 (closed)
• go1.16 runtime.Callers，the pc[1] is point at Callers itself, but go other version is point at the caller of Callers. #49941 (closed)
• runtime.Callers does not include all callers. #29526 (closed)
• runtime: runtime.Caller returns invalid zero frame #24108 (closed)
• runtime: caller returns different result after we upgrade go1.11.6 to go1.12.1 #31185 (closed)
• runtime: mid-stack inlining vs. FuncForPC #29582 (closed)
• runtime.Caller() return wrong number of line #663 (closed)

Related Code Changes

• runtime: allow calling Func.Name on nil pointer

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

[mknyszek]

This is a runtime API but the names come from the compiler. CC @golang/compiler

[mknyszek]

@dr2chase In triage, we think that this might be related to more aggressive inlining of once-called closures?

[mknyszek]

Possibly related to various long symbol name issues:

• cmd/compile: long symbol names for instantiated generics => large object files (though not executables) #50438
• cmd/compile: very long names for simple generic usage #71535
• cmd/compile: closure func name changes when inlining #60324

[mknyszek]

Possibly helped by CL 639515?

[ShoshinNikita]

we think that this might be related to more aggressive inlining of once-called closures

I checked the output before and after cmd/compile: use very high budget for once-called closures (https://go.dev/cl/630696), and I believe you are right:

• Before d524c95:

  # go version devel go1.24-8b97607280 Fri Nov 22 01:58:53 2024 +0000 linux/amd64
  
  0   main.foo
  1   main.foo.func1
  2   main.foo.func1.1
  3.1 main.foo.func1.1.1
  3.2 main.foo.func1.1.2
  

• On d524c95:

  # go version devel go1.24-d524c954b1 Fri Nov 22 02:04:41 2024 +0000 linux/amd64
  
  0   main.foo
  1   main.foo.func1
  2   main.foo.foo.func1.func2
  3.1 main.foo.foo.func1.foo.foo.func1.func2.func3
  3.2 main.foo.foo.func1.foo.foo.func1.func2.func4
  

For reference, output with mentioned https://go.dev/cl/639515:

# go version devel go1.24-d1c903cb21 Tue Jan 14 16:59:34 2025 +0100 linux/amd64

0   main.foo
1   main.foo.func1
2   main.foo.func2
3.1 main.foo.func3
3.2 main.foo.func4

I think this issue can be closed in favor of #60324