This is the mail archive of the systemtap@sources.redhat.com 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: [Fwd: Re: [PATCH] Return probe]


Hi Jim, Hien,

Now this patch looks much better.  Please note that this patch requires to call
kprobe_flush_task() at every do_exit()/do_execv() which adds to some amount of
performance overhead. Also this method could not use multiple handlers feature 
in a cleaner way. 

Just a thought if a probe inside the tampoline can be avoided, since we change
 the return address on stack to tampoline and now within the tampoline we can 
call the handlers. Then the return from tampoline can be changed to actual 
return address.  We may need to get the pt_regs structure and avoid preemption 
during the handler execution .

Do you feel that there are some performance benefits by avoiding int3 
in a tampoline?
Can we make this patch still cleaner by using multiple handlers feature?
Should we proceed wth this patch now?

Also from discussions followed on the mailing lists that this method does not 
handle the case where the return address stored on the stack is corrupted. This
can be avoided by reistering a watchpoint at the place where the return 
address is stored. There are other issue such as watchpoint register depletion
etc, which might add some amount of complexity.

Should we proceed with this limitation? 
If this limitation is not acceptable should we prototype the above approach?

Just a thought if we can implement the exit probe feature in much cleaner and 
simpler way.
One of the alternative methods mentioned in your design document that 
"inserting a probepoint every time a probed function is entered, and the 
removal of the probepoint after the function returns" seems to be much simpler.
Also the problem mentioned in your design document about this method that "the 
instruction at the RA may be executed even if the probed function isn't called"
can be solved by tracking the current task associated with probe.
Ofcourse the problem of return address corruption will exist here also.

How about prototyping this alternative approach just to see how this looks ?
Is there a simpler way of implementing the exit probe feature ?

Your suggestions are welcome.

Thanks
Prasanna

-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>


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