[prev in list] [next in list] [prev in thread] [next in thread]
List: opensolaris-dtrace-discuss
Subject: Re: [dtrace-discuss] tracing recursive functions
From: "Hillel (Sabba) Markowitz" <sabbahillel () gmail ! com>
Date: 2009-12-24 16:35:04
Message-ID: f25877ac0912240835t51fb3819y6fbd405ef231a4a2 () mail ! gmail ! com
[Download RAW message or body]
An interesting case occurred because of recursion.
for (i = 1; i<strlen(printarg); i++)
{
printone(printarg[i]);
}
became optimised with strict recursion so that it never actually
returned to the calling function. As a result, ustackdepth never got
incremented and I needed to check the timestamp of the calling routine
to ensure that it was not 0 before setting trying to sum the time
spent in the calling routine. I also had to not reset the time
entering into the new function. Note that this has to be done in the
proper order or the count will be off.
pid$target:myapp::entry
/ self->mydepth[probemod, ustackdepth-1] && !self-ts[probemod, ustackdepth-1]/
{
/* Just count the entry into the new function */
@syscalls[probemod, probefunc] = count();
}
pid$target:myapp::entry
/ self->mydepth[probemod, ustackdepth-1] && self-ts[probemod, ustackdepth-1] /
{
/* Close the timing for the calling routine */
@total[probemod, ustackdepth-1] = sum(timestamp-self->ts[probemod,
ustackdepth-1]);
ts[probemod, ustackdepth-1] = 0;
/* Set up to start timing the current function */
......
}
If the return of the recursive function gets called in the for loop,
then the normal processing will handle matters.
--
Sabba - סבא הלל - Hillel
Hillel (Sabba) Markowitz | Said the fox to the fish, "Join me ashore"
SabbaHillel@gmail.com | The fish are the Jews, Torah is our water
http://photos1.blogger.com/blogger/7637/544/640/SabbaHillel.jpg
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic