README
¶
bldr callpath
bldr callpath prints the static call paths from the functions matching
--from to the functions matching --to. Use it to answer "can this entry
point reach that call?" across a package tree, for example whether any World
operation can take a lock or read the database it is applying to. The same
command is spacewave-dev callpath in an app built on spacewave.
Usage
bldr callpath --from <regexp> --to <regexp> [flags] <package-pattern>...
--frommatches the functions paths start from.--tomatches the functions paths end at. A target may lie in any package.--withinmatches the package paths a path may pass through. By default a path stays inside the modules of the loaded packages.--testsalso loads the packages' test files.--fullprints full package paths. By default the loaded modules' paths are trimmed.
Names are SSA names: pkg.Func, (*pkg.T).Method, (pkg.T).Method, and
pkg.Func$1 for the first closure in Func.
Examples
Every World operation that can take a mutex:
bldr callpath --from '\)\.ApplyWorldOp$' \
--to '^\(\*sync\.(RW)?Mutex\)\.R?Lock$' ./core/...
Every path from an operation to a read of the store:
bldr callpath --from '\)\.ApplyWorldOp$' --to '\.sqlDatabase\)\.read$' ./core/worldgraph
Reading the output
Each block is the shortest path from one root to one target:
(*db/world/vlogger.WorldState).ApplyWorldOp
-> (*db/world/block/tx.WorldState).ApplyWorldOp
-> (*sync.Mutex).Lock
The call graph is a class hierarchy analysis: an interface call reaches every method of every loaded type that satisfies the interface. A path may therefore never run, so confirm it in the source. A path that is missing does not exist in the loaded code, which makes an empty result the useful answer for a "can never happen" question. A call through a function value reaches every function of the same signature whose address the loaded code takes.
Documentation
¶
Overview ¶
Package callpath finds static call paths between Go functions.
It builds a class hierarchy analysis call graph, which counts every method of a matching type as a possible callee of an interface call. The paths are therefore a superset of the real ones: a path found may never run, but a call path missing from the output does not exist in the loaded code.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Options ¶
type Options struct {
// Dir is the directory the package patterns resolve from.
Dir string
// Patterns are the package patterns to load, as for go build.
Patterns []string
// Tests also loads the test files of the matched packages.
Tests bool
// From matches the full SSA names of the functions the paths start from.
From *regexp.Regexp
// To matches the full SSA names of the functions the paths end at.
To *regexp.Regexp
// Within matches the package paths a path may pass through. A target may
// lie outside them. Nil keeps a path inside the modules of the loaded
// packages.
Within *regexp.Regexp
}
Options configures a call path search.
type Path ¶
type Path []string
Path is one call path, from its root to its target, as full SSA names.
type Result ¶
type Result struct {
// Modules are the module paths of the loaded packages.
Modules []string
// Roots is the number of functions From matched.
Roots int
// Paths are the shortest path from each root to each target it reaches,
// sorted.
Paths []Path
}
Result is the outcome of a search.
Source Files