Open thanm opened 4 months ago
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.