This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tapsets/16726] RFE: provide a way to retrieve tapset function types


https://sourceware.org/bugzilla/show_bug.cgi?id=16726

--- Comment #2 from Jonathan Lebon <jlebon at redhat dot com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]