From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98947 invoked by alias); 16 Jun 2017 04:07:39 -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 97406 invoked by uid 89); 16 Jun 2017 04:06:02 -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=Hx-languages-length:3756, sk:serhei., serhei.etc@gmail.com, Instrumenting X-HELO: mail-wm0-f45.google.com Received: from mail-wm0-f45.google.com (HELO mail-wm0-f45.google.com) (74.125.82.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Jun 2017 04:05:58 +0000 Received: by mail-wm0-f45.google.com with SMTP id x70so15051298wme.0 for ; Thu, 15 Jun 2017 21:06:02 -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=iUsbLbyto/yGqoZXl1c8gKSTlySAQr4T/WBd88Ai9rk=; b=IkzlO0B7gIoJqQvr6F+IFN2ANlvLnvdAz9p/0fNQu+fQIJyVqFoaPU9NnCkoijBJxW FMun/Baf9tClfK5g/RqfiUES4JFpLZp0fGIhJqZ50+fDvvJJTaOs2wBsOoRIiCyaW0fL Xy2HzpQlZ0egrjVv3NFYViQduTFFc3mfTRLKwSkaFv2m1rGbPQGfrNL2S5unK6nHqwFg IKKZArlfJj5C5+tTheBHK4qLgO/l5+wX4WG5D6LxY+qnw+PVj57s/65jdOp2m8w3QM5Y DtiRBKx7ykdmznKZwcZxiKvO9P+mP3HDa0KOGCBcxvpuUZdbzetv+DQxVHqfhLmrCTyV mRyA== X-Gm-Message-State: AKS2vOyfBWDL9gNKpSHWridyit7Rb+Hef9D11kihOEBwzmBwbqWHoWSh Fbj5+wowR96KjVd8+kfLEvw4f9nfMA== X-Received: by 10.80.183.146 with SMTP id h18mr5852512ede.39.1497585960566; Thu, 15 Jun 2017 21:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.132.228 with HTTP; Thu, 15 Jun 2017 21:05:40 -0700 (PDT) In-Reply-To: References: From: Arkady Date: Fri, 16 Jun 2017 04:07: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/msg00119.txt.bz2 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)