From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119607 invoked by alias); 16 Jun 2017 04:23: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 118639 invoked by uid 89); 16 Jun 2017 04:22:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Jun 2017 04:22:33 +0000 Received: by mail-wm0-f50.google.com with SMTP id x70so15228162wme.0 for ; Thu, 15 Jun 2017 21:22:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7iE+9uMh0OffUXQZ4otcFoYdUjLoJiYdSLzXliu713o=; b=YNs8mTHaGk9/OQJO5OT/yJF10U3U6rM/m/JZJY+gA2z0DUzDlrpmMIATUPNyaiSrCB Vf0S+G65ZMm9T72Es7LSTrnL0Q+iDXUvpY8+7bSwD5key7g6iCcbA/jrgCZjAQ6qT9Nm 6OkIfmBpxXLPqbC7tPoppgeA95bRyxSM5twbwyk5H4QR+G+mWFXz6y+rWvYjHSXW/DWU S7OloyNXI/GtJQe3kgyAcEMjm9vqj24MBPzY3a3ipJFjOofdChF7SNbcoSmMN+aN8qoV kN1mhiTEEPp3gi2+H3QQmxnxCsoUyycIUcompo8oN3pu0Pa95I7tsYJ8X3kpKeLaIRBD tBAw== X-Gm-Message-State: AKS2vOw9gKdpy8UqRcGYX1MjIH8mxM85nl1SD8PX3sWs+AfPA6ayQ6un Rij8SK3dx6khMytCk+PrLqoMRLX6AQ== X-Received: by 10.80.213.157 with SMTP id v29mr5762520edi.149.1497586956190; Thu, 15 Jun 2017 21:22:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.132.228 with HTTP; Thu, 15 Jun 2017 21:22:15 -0700 (PDT) In-Reply-To: References: From: Arkady Date: Fri, 16 Jun 2017 04:23:00 -0000 Message-ID: Subject: Re: Using stapdyn to probe child processes of the target? To: Serhei Makarov Cc: systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00121.txt.bz2 I see that there is pre-fork and post-fork hooks in the Dyninst code. On Fri, Jun 16, 2017 at 7:17 AM, Arkady wrote: > If the timing is important you can add some code to the script. For > example you can call to processAttach() in the script when a certain > function in the GCC starts a new process. > > On Fri, Jun 16, 2017 at 7:05 AM, Arkady wrote: >> I have never tried user space hooking. My immediate idea is to run gcc >> under strace, filter all fork-exec pairs (a Python script here?) and >> attach stap to all child PIDs >> >> On Fri, Jun 16, 2017 at 12:47 AM, Serhei Makarov wrote: >>> Hello all, >>> >>> I've been trying to observe gcc's execution using Stapdyn. Most of the >>> actual work is done by a child process (cc1) forked from gcc. (Below >>> I've attached a script, proctree.stp, for listing processes forked by >>> a target command.) 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" >>> >>> Instrumenting using kernel uprobes introduces quite a large >>> performance overhead, so I would prefer Dyninst for this. But the same >>> script doesn't work with --dyninst option, because the target process >>> selected using -c is not cc1. >>> >>> As far as I can tell, my only options for observing cc1 with Stapdyn are: >>> >>> (a) use -c option : invoke cc1 directly. Feasible in this case, may >>> not be feasible in other software where the parent/child processes >>> coordinate using more complex IPC. This also doesn't give a profile of >>> the full GCC execution (unlike, say, "valgrind --trace-children=yes"). >>> (b) use -x option : attach to cc1 by PID after it starts running. Not >>> feasible in this case since cc1 is a batch program, not a long-running >>> daemon. >>> >>> Am I missing any possibilities? Is it currently possible to use >>> Stapdyn to attach to processes other than a single target? >>> >>> All the best, >>> Serhei Makarov >>> >>> PS Here's the proctree.stp script: >>> >>> global pids >>> >>> probe begin { >>> pids[target()] = 0 >>> } >>> >>> probe process.begin { >>> child = pid(); parent = ppid() >>> if (parent in pids) { >>> printf("fork %s(%d) -> %s(%d)\n", pexecname(), parent, execname(), child) >>> pids[child] = parent >>> } >>> } >>> >>> This outputs things like: >>> >>> [serhei@beatrice e-tracer]$ stap proctree.stp -c "gcc test/widget3.c" >>> Missing separate debuginfos, use: debuginfo-install >>> kernel-core-4.10.10-200.fc25.x86_64 >>> fork gcc(2725) -> gcc(2728) >>> fork gcc(2725) -> cc1(2728) >>> fork gcc(2725) -> gcc(2729) >>> fork gcc(2725) -> as(2729) >>> fork gcc(2725) -> gcc(2730) >>> fork gcc(2725) -> collect2(2730) >>> fork collect2(2730) -> collect2(2731) >>> fork collect2(2730) -> ld(2731) >>> >>> Or, here's a Firefox browsing session: >>> >>> [serhei@beatrice e-tracer]$ stap proctree.stp -c "firefox --new-instance" >>> fork firefox(3179) -> firefox(3182) >>> fork firefox(3179) -> basename(3182) >>> fork firefox(3179) -> firefox(3183) >>> fork firefox(3179) -> uname(3183) >>> fork firefox(3179) -> firefox(3184) >>> fork firefox(3179) -> pidof(3184) >>> fork firefox(3179) -> firefox(3185) >>> fork firefox(3179) -> mkdir(3185) >>> fork firefox(3179) -> firefox(3186) >>> fork firefox(3186) -> firefox(3187) >>> fork firefox(3186) -> firefox(3188) >>> fork firefox(3186) -> sed(3188) >>> fork firefox(3179) -> firefox(3189) >>> fork firefox(3189) -> firefox(3190) >>> fork firefox(3189) -> firefox(3191) >>> fork firefox(3189) -> sed(3191) >>> fork firefox(3179) -> firefox(3192) >>> fork firefox(3179) -> expr(3192) >>> fork run-mozilla.sh(3179) -> run-mozilla.sh(3193) >>> fork run-mozilla.sh(3179) -> basename(3193) >>> fork run-mozilla.sh(3179) -> run-mozilla.sh(3194) >>> fork run-mozilla.sh(3179) -> dirname(3194) >>> fork run-mozilla.sh(3179) -> run-mozilla.sh(3195) >>> fork run-mozilla.sh(3179) -> uname(3195) >>> fork firefox(3179) -> firefox(3196) >>> fork firefox(3179) -> firefox(3198) >>> fork Gecko_IOThread(3179) -> Gecko_IOThread(3266) >>> fork Gecko_IOThread(3179) -> firefox(3266)