What can I access in return probe

What can I access in return probe

[Badari Pulavarty]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

Hi,

I am wondering if I can access arguments in my return probe ?
And also, how do I access return value ?
 
Whats wrong here ?

# stap -g pagecache.stp
ERROR: pointer dereference fault near identifier 'page_cache_pages' at
pagecache.stp:8:2


Thanks,
Badari





[-- Attachment #2: pagecache.stp --]
[-- Type: text/plain, Size: 509 bytes --]

#! stap

global page_cache_pages

function _(n) { return string(n) } 

probe kernel.function("add_to_page_cache").return {
	page_cache_pages[$mapping] = $mapping->nrpages
}

probe kernel.function("__remove_from_page_cache") {
	page_cache_pages[$page->mapping] = $page->mapping->nrpages
}

function report () {
  foreach (mapping in page_cache_pages) {
	print("mapping = " . hexstring(mapping) . 
		" nrpages = " . _(page_cache_pages[mapping]) . "\n")
  }
  delete page_cache_pages
}

probe end {
  report()
}

Re: What can I access in return probe

[Kevin Stafford]

Kevin Stafford wrote:

> Badari Pulavarty wrote:
>
>> Hi,
>>
>> I am wondering if I can access arguments in my return probe ?
>>  
>>
> No, by the time the return probe fires, the stack has been torn down 
> and thus
> have no reference to you arguments, which causes the deref fault. 
> There have
> been a couple of proposed solutions to this problem. See
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=1382
>
>> And also, how do I access return value ?
>>  
>>
> Tapset function retval() should do this for you.
> See /usr/local/share/systemtap/tapset/return.stp
>
>>
>> Whats wrong here ?
>>
>> # stap -g pagecache.stp
>> ERROR: pointer dereference fault near identifier 'page_cache_pages' at
>> pagecache.stp:8:2
>>
>>
>> Thanks,
>> Badari
>>  
>>


-- 
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com

Re: What can I access in return probe

[Frank Ch. Eigler]

Badari Pulavarty <pbadari@us.ibm.com> writes:

> [...]
> Whats wrong here ?
> # stap -g pagecache.stp
> ERROR: pointer dereference fault near identifier 'page_cache_pages' at
> pagecache.stp:8:2

First, you don't need "-g" - no guru mode code is present.  The fault
probably occurred in relation to the target variable $mapping or
$mapping->nrpages.  Maybe it was by this time a null value.  

The translator is probably mistaken in even allowing target variables
within .return probes, until we support them properly (as in the PR
kevinrs referred).

- FChE

Re: What can I access in return probe

[Marcelo Tosatti]

On Fri, Dec 02, 2005 at 04:07:21PM -0800, Badari Pulavarty wrote:
> Hi,
> 
> I am wondering if I can access arguments in my return probe ?
> And also, how do I access return value ?
>  
> Whats wrong here ?
> 
> # stap -g pagecache.stp
> ERROR: pointer dereference fault near identifier 'page_cache_pages' at
> pagecache.stp:8:2
> 
> 
> Thanks,
> Badari

Hi Badari,

I just tried your script and I wonder why I'm getting negative "nrpages":

mapping = 0xc1115280 nrpages = -1
mapping = 0xc12430c0 nrpages = -1
...

Another issue is that it would be more practical to have actual
bdev+inode number information (which can easily be retrieved from
address_space), to be converted later to real pathname using dcookies
(similar to what oprofile does).

I'm still wondering how to access the "current" task_struct pointer from
a .stp script.


> #! stap
> 
> global page_cache_pages
> 
> function _(n) { return string(n) } 
> 
> probe kernel.function("add_to_page_cache").return {
> 	page_cache_pages[$mapping] = $mapping->nrpages
> }
> 
> probe kernel.function("__remove_from_page_cache") {
> 	page_cache_pages[$page->mapping] = $page->mapping->nrpages
> }
> 
> function report () {
>   foreach (mapping in page_cache_pages) {
> 	print("mapping = " . hexstring(mapping) . 
> 		" nrpages = " . _(page_cache_pages[mapping]) . "\n")
>   }
>   delete page_cache_pages
> }
> 
> probe end {
>   report()
> }

Re: What can I access in return probe

[Badari Pulavarty]

On Sat, 2005-12-17 at 21:00 -0200, Marcelo Tosatti wrote:
> On Fri, Dec 02, 2005 at 04:07:21PM -0800, Badari Pulavarty wrote:
> > Hi,
> > 
> > I am wondering if I can access arguments in my return probe ?
> > And also, how do I access return value ?
> >  
> > Whats wrong here ?
> > 
> > # stap -g pagecache.stp
> > ERROR: pointer dereference fault near identifier 'page_cache_pages' at
> > pagecache.stp:8:2
> > 
> > 
> > Thanks,
> > Badari
> 
> Hi Badari,
> 
> I just tried your script and I wonder why I'm getting negative "nrpages":
> 
> mapping = 0xc1115280 nrpages = -1
> mapping = 0xc12430c0 nrpages = -1
> ...
> 

Hmm. Don't know why.

> Another issue is that it would be more practical to have actual
> bdev+inode number information (which can easily be retrieved from
> address_space), to be converted later to real pathname using dcookies
> (similar to what oprofile does).
> 

Yes. That would be good.

> I'm still wondering how to access the "current" task_struct pointer from
> a .stp script.

What information are you looking from "current". There are functions
that provide info from current (like pid(), ppid(), gid() etc..). 
I tried using "current" in the scripts and it failed. I guess one can
easily add new functions that access information from "current".

Look at  /usr/share/systemtap/tapset/context.stp

Thanks,
Badari