From owner-freebsd-dtrace@FreeBSD.ORG Thu Oct 17 03:34:07 2013 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 582232DF for ; Thu, 17 Oct 2013 03:34:07 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 276692E06 for ; Thu, 17 Oct 2013 03:34:07 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id at1so3071247iec.29 for ; Wed, 16 Oct 2013 20:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=xwslVZl4H5MpqhO7ynyYmpVt1+HEEBL2R6uaMqViLpg=; b=JlVbdgn2W6bf7lz41jCPR2GRSCT4KKousYGBU/+UZ/7YexGq9l0v3wB822dkFqSwZV n0Pc6ehjljxFvNEaNaMn1e+C1nhrlDa2PWY9xrniPtZKckttvnUtUHIxw16BL2ThF8p4 IVgwdNoCXAqzKjlosWB57nZ/MSVC8pCUTaXnnq/xq7nlRTIqpehU+LIeeXNRXhH0KAcV hRso8ZtE7sTkYdOHPlt4czbp7SvE7Wd78ngUmJaGl0Z/Yo9xhWrhlQHRNb3jHGxHglQV 9LTXvr5AujAmBL+LjTWfRpsZBUd5NeD/tmwL0ahX3Rk2DRHFdd4bZU/HO0Yu9D5s+LoC Su5Q== X-Received: by 10.50.126.74 with SMTP id mw10mr24766860igb.24.1381980845815; Wed, 16 Oct 2013 20:34:05 -0700 (PDT) Received: from charmander (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id ft2sm6420108igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Oct 2013 20:34:05 -0700 (PDT) Sender: Mark Johnston Date: Wed, 16 Oct 2013 23:34:00 -0400 From: Mark Johnston To: John-Mark Gurney Subject: Re: dtrace -c doesn't work? Message-ID: <20131017033400.GA31544@charmander> References: <20131015233219.GZ56872@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131015233219.GZ56872@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-dtrace@FreeBSD.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 03:34:07 -0000 On Tue, Oct 15, 2013 at 04:32:19PM -0700, John-Mark Gurney wrote: > Well, I've decided to try to learn dtrace to do some benchmarking, and > so I tried to use -c to measure what the command does... except it seems > to fail... > > even the simple: > dtrace -n 'syscall:::entry { @num[execname] = count(); }' -c 'echo foo' > > doesn't work... it gives me: > # dtrace -n 'syscall:::entry { @num[execname] = count(); }' -c 'echo foo' > foo > dtrace: failed to control pid 3766: process exited with status 0 > > ktrace shows it execing /bin/echo and it running fine, but for some > reason dtrace can't handle it... My guess is that the /bin/echo on your system is stripped. dtrace(1) on FreeBSD will set a breakpoint on main() in the victim process and register the script with the kernel when that breakpoint fires. If libproc can't find the address of main(), the breakpoint won't fire, and your script won't run. If /bin/echo isn't stripped, your example works properly on my laptop. Adding '-x evaltime=postinit' to the dtrace(1) flags should also allow the script to run properly. avg@ tried to fix this a little while ago by changing dtrace to instead put a breakpoint on r_debug_state in rtld (r248644). This works for your example, but breaks USDT since that breakpoint apparently fires before ELF ctors run, and thus before dtrace_dof_init() can run (which is needed for USDT to work). I'm not sure what the best way to fix this is. Perhaps we could add a second breakpoint to rtld for use by dtrace, or maybe there's some way to set a breakpoint on the DOF init code. It would also be nice if libproc could learn to follow .gnu_debuglink sections when performing symbol lookup. I use WITH_DEBUG_FILES on my laptop to keep debug info in separate files, but I still have the same problem as you with the above example. I'll work on fixing this too. > > P.S. Why are dtrace and dtraceall seperate? dtrace.ko contains the "core" DTrace kernel code. Most of the actual providers and support code (e.g. fasttrap, sdt) are implemented in their own modules. dtraceall depends on all the DTrace-related modules, so it's almost always better to kldload dtraceall instead of kldloading dtrace. In fact, dtrace(1) was recently changed to automatically kldload dtraceall if needed, so there's no reason to manually kldload anything now. -Mark