Running 'stap -vp1' (verbose pass 1, with any provided script) outputs a dump of all tapset contents; however, tapset functions and their parameters are printed without their types. It is possible to infer function & parameter types with pass 2, but that only examines the functions which are called by a provided script. I acknowledge that inferring the types of all functions & parameters of all included tapsets may be processor-intensive, but it may be a useful optional feature to have available. For instance, SystemTap IDE for Eclipse (which I contribute to) features a visual list of all tapset functions & their parameters, with icons next to each entry to signify return & parameter types. At the moment, the only way to obtain the types is to directly examine each function's definition in its host tapset file (if it provides type information at all). In a case such as this, being able to dump all tapset contents with types inferred would be useful.
We shouldn't add type resolution to -vp1, but I think we could provide a specialized option like --dump-functions that reports them all. This could run through a few passes of type resolution too, but that still might not resolve everything. I expect most types will be inferable by the function body, but there could be some that depend on how the user calls it. Leaving those listed ambiguously is probably correct.
Commit eb9ea96 added the --dump-functions switch. Sample output: user_ushort_warn:long (addr:long) /* myproc-unprivileged */ usrdev2kerndev:long (dev:long) ustack:long (n:long) usymdata:string (addr:long) /* myproc-unprivileged */ usymname:string (addr:long) /* myproc-unprivileged */ vers_from_clnt:long (clnt:long) vers_from_prog:long (program:long, vers:long) vm_fault_contains:long (value:long, test:long) warn:unknown (msg:string) /* unprivileged */ xid_from_clnt:long (clnt:long) As Josh mentioned, there is a risk that some types remain unresolved as they depend on how the user script uses them. For example, if we had the following tapset function: function my_func(x) { println(x) } it would show up in --dump-functions as: my_func:unknown (x:unknown) Thankfully, none of the current tapset functions have unresolved argument types according to the output of --dump-functions. Note that functions starting with '_' are hidden by default, use -v to show them.
A related RFE was to add a --dump-probe-aliases switch. This was done in commit 7d66cd7. Sample output: vfs.read = kernel.function("vfs_read") vfs.read.return = kernel.function("vfs_read").return vfs.readv = kernel.function("vfs_readv") vfs.readv.return = kernel.function("vfs_readv").return ... Here too, aliases starting with '_' are hidden behind a -v.