This is the mail archive of the 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]

RE: $return in wildcarded void functions

Sorry guys. I am new to this mailinglist. Could you please
tell me which email address I should use to send an email
to if I want to ask a question. 

I really appreciate your help. 

John Liang 

-----Original Message-----
From: []
On Behalf Of Jim Keniston
Sent: Tuesday, March 06, 2007 12:06 PM
To: Vara Prasad
Cc: Mike Mason;
Subject: Re: $return in wildcarded void functions

On Mon, 2007-03-05 at 18:21 -0800, Vara Prasad wrote:
> 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.

Sounds like you're saying SystemTap should refuse to do return probes
for void functions.  This is plainly not the case.  E.g., in the example
shown, the user wants to know when the function returns (to match up
calls and returns), even if it's a void function.

> 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.

Yeah, that'd be nice.

Other possibilities:
1) Redefine $return to evaluate to 0 for void functions.
2) Define a new variable $vreturn (or some such) that does (1).
3) Change the error to a warning, perhaps considering wildcarding as
Vara proposed.

Seems like all these would be easier than a whole new $?var language
construct (though $?var would certainly help us smooth over the
occasional deficiency in the dawrf info).


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