This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Using stapdyn to probe child processes of the target?
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Serhei Makarov <serhei dot etc at gmail dot com>
- Cc: systemtap at sourceware dot org
- Date: Fri, 16 Jun 2017 15:33:49 -0400
- Subject: Re: Using stapdyn to probe child processes of the target?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fche at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 02A81369CB
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 02A81369CB
- References: <CALZRDwYJktLToLsBeiw_Nqj8a5i8aCGGUDu=FSnZDq2_XH_+rg@mail.gmail.com>
serhei.etc wrote:
> [...] If I'm using kernel systemtap, I can just target
> cc1 directly, for example:
>
> stap -ve 'probe
> process("/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/cc1").insn {
> counter<<<1 } global counter probe end { printf("%d calls\n",
> @count(counter)) }' -c "gcc test/widget3.c"
> [...]
As you noticed, this is a terribly inefficient way of counting
instructions. You could try instead perfcounters to estimate. It
samples an instruction perfcounter for a target process (thread) at
every function-return, and since this number only gets larger, it will
eventually get close to the overall count as the process exits.
(We should be able to sample that counter at a process.end type event
too, but our implementation is limited.)
% cat > countem.stp << 'END'
@define cc1 %( "/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/cc1" %)
global insns
probe perf.hw.instructions.process(@cc1).counter("foo") {}
probe process(@cc1).function("*").return {
insns[execname(),tid()] = @perf("foo") // implicit max()
}
END
% sudo stap countem.stp -c "gcc ...."
insns["cc1",2102]=0x367fb494
%
- FChE