Dave Mitchell wrote:
If you're talking about producing a special perl binary that does this, it
would be trivial - just a quick mod to pp_entersub. - wouldn't even need
to call find_runcv, since entersub knws the CV its calling.
And a corresponding mod to pp_leavesub I guess and pp_leavesubv?
if you want to record leaving too, then you also need pp_return, pp_goto,
*and* you need to handle all the cases of a non-normal exit from a sub,
eg die trapped by eval, next LABEL where LABEL is outside the sub etc.
This would be quite hard.
Bah, there's always a catch. However 'hard' != 'impossible'. How easy
is it to get the same info on the sub name, file and line at the various
exit points?
Any suggestions for the best place to insert the trace call into
pp_entersub? Somewhere around the 'now we have permission to enter the
sub' comment?
You're looking at 5.8.x code: in particular that comment is within a
5.005threads section that has been excised from bleed!
Yeah, I figured that out pretty soon after my last post ;-)
In bleedperl, I'd suggest just before the
RETURNOP(CvSTART(cv));
line.
Done, thanks.
You'll also need to decide what to do when pp_enterusb is calling an XS
sub; in this case there's no CvSTART(cv) op and so no way to deternine
filename and line number (which makes sense, as there isn't a line
number!). You also need to allow for perl -d, which causes pp_entersub to
call DB::sub() each time rather than the real sub (it expects DB::Sub to
call the real sub on your behalf)
Hmm, I think the sub name and <XSUB> as the filename, 0 as the number
would be OK. As for running under the debugger, I'm not *too* worried
about that, the purpose of dtrace is to let you trace whilst running
normally, and the debugger isn't normal usage. I don't know exactly how
the debugger works - does it eventually call back into pp_entersub to
dispatch the sub 'for real'?
Thanks for all your help BTW :-)
--
Alan Burlison
--
