This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: $return in wildcarded void functions
- From: Vara Prasad <prasadav at us dot ibm dot com>
- To: Mike Mason <mmlnx at us dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Mon, 05 Mar 2007 18:21:27 -0800
- Subject: Re: $return in wildcarded void functions
- References: <45ECC45B.4080809@us.ibm.com>
Mike Mason wrote:
[snip]
probe module("uhci_hcd").function("*").return
{
printf ("%s <- %s: %s\n", thread_indent(-2), probefunc(),
errno_str($return))
}
My interpretation of the above statement is put a return probe in all
the functions that have return value in the "uhci_hcd" module, with that
interpretation we shouldn't even try to put return probes on the
functions with a return type of void.
If the user how ever specifically says put a probe in a function that
has return type of void i think we should give "no return value" error.
Looks like based on dwarf info we can detect void functions. I guess the
issue is how easy it is to carry forward the information from wild card
expansion stage to elaboration stage so we can differentiate between the
functions that were specified by user explicitly vs wild card expanded
ones. I have not spent enough time to figure that out, i will let Frank
comment on that.
The return probe attempts to access $return. For functions defined as
void, obviously there is no return value, which causes pass 2 to fail
with the following errors:
semantic error: function has no return value: identifier '$return' at
usb2:11:85
semantic error: function has no return value: identifier '$return' at
usb2:23:85
Is there any way around this problem short of writing a return probe
for each function? Is there any way to treat a variable as
conditional? That would be a useful feature, especially for
wildcarded return probes.
Mike