From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24246 invoked by alias); 16 Jun 2017 19:33:51 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 24238 invoked by uid 89); 16 Jun 2017 19:33:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=our X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Jun 2017 19:33:49 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 02A81369CB; Fri, 16 Jun 2017 19:33:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 02A81369CB 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@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 02A81369CB Received: from redhat.com (ovpn-120-95.rdu2.redhat.com [10.10.120.95]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CED729F994; Fri, 16 Jun 2017 19:33:52 +0000 (UTC) Received: from localhost.mad.redhat.com ([127.0.0.1] helo=vm-rhel7) by redhat.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dLx0B-0001JI-II; Fri, 16 Jun 2017 15:33:51 -0400 From: fche@redhat.com (Frank Ch. Eigler) To: Serhei Makarov Cc: systemtap@sourceware.org Subject: Re: Using stapdyn to probe child processes of the target? References: Date: Fri, 16 Jun 2017 19:33:00 -0000 In-Reply-To: (Serhei Makarov's message of "Thu, 15 Jun 2017 17:47:12 -0400") Message-ID: <878tkr917m.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-q2/txt/msg00123.txt.bz2 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