Alexander Kolbasov wrote: > Solaris (*) has a dynamic instrumentation tool called DTrace. It allows to > *dynamically* instrument any running application and get useful information > about its behavior with zero (or almost zero) impact on the application when > it > is not instrumented. > > This works fine with normal applications, but not so good with interpteded > languages since C function names and data types have little to do with the > structure of the interpreted language. I am playing with the idea of adding > some > hooks to Perl5 that will allow DTrace to be used for Perl programs (**). As an
Maybe are you aware of http://blogs.sun.com/roller/page/alanbur?entry=dtrace_and_perl already ? > initial experiment I changed Perl_runops_standard() function a bit and was > able > to use DTrace to trace start and end of each Perl OP evaluation. This is not You can also plug in your own runloop at compile time. See for example my module Runops::Switch on CPAN. > very cool since there is no correlation between that and the Perl line > numbers. > So the first question I have is > > - Is it possible to get information about Perl script line number that the op > belongs to? I need this information from the call to > Perl_runops_standard(pTHX). In general, what is the good way (if any) to > access line number information? The line number isn't stored in all ops, but only in COPs. You then get it with the CopLINE macro, see cop.h. > A much more interesting thing is being able to trace Perl function calls. > Seems > like pp_entersub() is the right place to look at. This seems like a rather > complex function that I don't quite understand. I hacked it a bit to get the > name of the called function by using GvNAME(CvGV(cv)) which is, probably, not > quite safe since I have not checked whether CvGV(cv) returns something > non-NULL. > > So I have the second question: > > - What is the safe and efficient way (and place in pp_entersub()) to get the > string representing the function name? I can't completely answer this off hand, but consider a few cases : - exported functions. maybe use EGV instead of GV - test with XSUBs - some functions are autoloaded - generally, I look at how the warnings and error display such things as function names and infer from that > - Can I get the function name from pp_leavesub()? IIRC the CV is on the stack (popped by POPSUB). > - Can I get line number information for the caller in pp_entersub()? You can use PL_curcop to get the current COP. HTH. Your project looks very interesting.
