dtrace discuss - Sep 2006 - query re application profiling

Hi
I am trying to profile, the time spent in functions in pkginstall, i.e. 
functions that are part of pkginstall binary
So I have a debug pkginstall on my system

# file /usr/sadm/install/bin/pkginstall
/usr/sadm/install/bin/pkginstall:       ELF 32-bit MSB executable SPARC 
Version 1, dynamically linked, not stripped
#

Now pkginstall gets called by patchadd, which calls pkgadd, which calls 
pkginstall eventually.


So I did the following
#cat patchadd.d
#!/usr/sbin/dtrace -qs

#pragma D option quiet

:::entry
{
/execname == "pkginstall"/
   self->t[probefunc] = timestamp;
}

:::return
/self->t[probefunc] && execname == "pkginstall"/
{
  this->elapsed = timestamp -self->t[probefunc];
  @[probefunc] = quantize(this->elapsed);
  self->t[probefunc]=0;
}

END
{
   printf("Tracing has completed.\n");
}

I ran ./patchadd.d > file.out
then ran patchadd 119254-29 in another window.

Now while this did generate stats on system/library calls, it did not 
generate any info on actual functions in pkginstall.

Normally I''d use pid$1 or pid$target  but how do I get this to work for
a binary that is called a couple of levels down from the patchadd itself?


Enda

Enda o''Connor - Sun Microsystems Ireland - Software Engineer
writes:
> :::entry
I think you want a probe type here -- something like:

  syscall::exec:entry

... though it''s not clear to me what you''re trying to probe
here.
> {
> /execname == "pkginstall"/
That''s mangled syntax; the conditions go _before_ the curly braces for
the probe.
> :::return
> /self->t[probefunc] && execname == "pkginstall"/
Probably no need to test execname again.

-- 
James Carlson, KISS Network                    <james.d.carlson at
sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On 9/20/06, Enda o''Connor - Sun Microsystems Ireland - Software
Engineer <Enda.Oconnor at sun.com> wrote:
...
> Normally I''d use pid$1 or pid$target  but how do I get this to
work for
> a binary that is called a couple of levels down from the patchadd itself?
:::entry will not work because the target process is not running when
your DTrace begins.  What you need to do is to have your dscript watch
for the exec-success of the target process and launch a secondary
dscript that does the actual tracing...

e.g.

dtrace -w -n ''exec-success/pid != progenyof($target) &&
execname ="pkginstall"/{ stop(); system("dtrace -ws apptrace.d -p
%d", pid)}'' -c
''patchadd ...''

apptrace.d:
BEGIN { system("prun %d", $target); }
pid$target:::entry { @[probefunc] = count(); }

btw, is there any RFE for dtrace(1M) to do this?


-- 
Just me,
Wire ...

Wee Yeh Tan wrote:
> On 9/20/06, Enda o''Connor - Sun Microsystems Ireland - Software
> Engineer <Enda.Oconnor at sun.com> wrote:
> ...
> 
>> Normally I''d use pid$1 or pid$target  but how do I get this to
work for
>> a binary that is called a couple of levels down from the patchadd
itself?
> 
> 
> :::entry will not work because the target process is not running when
> your DTrace begins.  What you need to do is to have your dscript watch
> for the exec-success of the target process and launch a secondary
> dscript that does the actual tracing...
> 
> e.g.
> 
> dtrace -w -n ''exec-success/pid != progenyof($target) &&
execname => "pkginstall"/{ stop(); system("dtrace -ws
apptrace.d -p %d", pid)}'' -c
> ''patchadd ...''
> 
> apptrace.d:
> BEGIN { system("prun %d", $target); }
> pid$target:::entry { @[probefunc] = count(); }
> 
> btw, is there any RFE for dtrace(1M) to do this?
> 
> 
Hi
Cheers, this works ok, the stop() .. prun  appear to cause the app to 
exit on error, but as the function is well down the call stack i do not 
need to stop.

Thanks
Enda