You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The naming convention that capslock uses for Go methods seems to be inconsistent with the conventions used by other tools (for example, debuggers, profilers, and so on).
This program makes a series of calls into the text/template program from Go's standard library, at runtime most of the time is spent in that package. If I run this program through capslock, the convention used for reporting pointer Go methods is
Examples of other tools that use the latter convention: pprof (profiler), delve (debugger). Specifics:
Profiler:
$ go run hotmeth.go
$ ls *.p
prof.p
$ pprof prof.p
File: hotmeth
Type: cpu
Time: May 6, 2024 at 1:50pm (UTC)
Duration: 1.41s, Total samples = 1.40s (99.57%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
Showing nodes accounting for 520ms, 37.14% of 1400ms total
Showing top 10 nodes out of 210
flat flat% sum% cum cum%
120ms 8.57% 8.57% 340ms 24.29% runtime.mallocgc
80ms 5.71% 14.29% 280ms 20.00% text/template/parse.(*lexer).nextItem
50ms 3.57% 17.86% 560ms 40.00% text/template/parse.(*Tree).textOrAction
40ms 2.86% 20.71% 60ms 4.29% reflect.(*structType).FieldByName
40ms 2.86% 23.57% 120ms 8.57% text/template.(*state).evalField
40ms 2.86% 26.43% 300ms 21.43% text/template.(*state).walk
40ms 2.86% 29.29% 250ms 17.86% text/template/parse.(*Tree).nextNonSpace
40ms 2.86% 32.14% 740ms 52.86% text/template/parse.(*Tree).parse
40ms 2.86% 35.00% 130ms 9.29% text/template/parse.(*Tree).peek
30ms 2.14% 37.14% 50ms 3.57% runtime.deductAssistCredit
(pprof)
Debugger:
$ go build hotmeth.go
$ dlv debug .
Type 'help' for list of commands.
(dlv) b text/template.(*state).walk
Breakpoint 1 set at 0x586336 for text/template.(*state).walk() /w/ygo/src/text/template/exec.go:261
(dlv) c
> text/template.(*state).walk() /w/ygo/src/text/template/exec.go:261 (hits goroutine(1):1 total:1) (PC: 0x586336)
256: walkContinue = errors.New("continue")
257: )
258:
259: // Walk functions step through the major pieces of the template structure,
260: // generating output as they go.
=> 261: func (s *state) walk(dot reflect.Value, node parse.Node) {
262: s.at(node)
263: switch node := node.(type) {
264: case *parse.ActionNode:
265: // Do not pop variables so they persist until next end.
266: // Also, if the action declares variables, don't print the result.
(dlv) b (*text/template.state).walk
Command failed: location "(*text/template.state).walk" not found
(dlv)
It would be nice if capslock could work the same way. Thanks.
The text was updated successfully, but these errors were encountered:
So as background for the thread (I know you know this already :)) -- there's one set of logic in the compiler for producing symbols and DWARF information for the executable, and another set of logic in golang.org/x/tools and go/types. The names produced by the former are seen by tools like pprof, delve, and objdump that work with executables, and the latter is used by analysis tools like x/tools/cmd/{callgraph,ssadump} and by capslock. Capslock is calling the String method on the x/tools/go/ssa.Function object to get the name.
There are many cases where the generated names and even the set of actual functions are different between the two (synthetic functions, anonymous functions, nested anonymous functions, coalescing of instantiations, method expressions, defer, init, etc.) so getting these to match exactly is not simple, but we should be able to match the compiler for common cases.
Perhaps that should be done upstream in x/tools too, but that might be too disruptive, even though the strings are documented as being subject to change.
The naming convention that capslock uses for Go methods seems to be inconsistent with the conventions used by other tools (for example, debuggers, profilers, and so on).
Here is a toy program to demonstrate: playground link.
This program makes a series of calls into the
text/template
program from Go's standard library, at runtime most of the time is spent in that package. If I run this program through capslock, the convention used for reportingpointer
Go methods is(*<packagepath>.<type>).<methodname>
instead of the more commonly used
<packagepath>.(*<type>).<methodname>
Here is what I see from capslock:
Examples of other tools that use the latter convention: pprof (profiler), delve (debugger). Specifics:
Profiler:
Debugger:
It would be nice if capslock could work the same way. Thanks.
The text was updated successfully, but these errors were encountered: