From owner-freebsd-dtrace@FreeBSD.ORG Thu Oct 17 17:27:51 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 59A975D6; Thu, 17 Oct 2013 17:27:51 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3AE9D238F; Thu, 17 Oct 2013 17:27:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9HHRi13076452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 10:27:44 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9HHRiSf076451; Thu, 17 Oct 2013 10:27:44 -0700 (PDT) (envelope-from jmg) Date: Thu, 17 Oct 2013 10:27:44 -0700 From: John-Mark Gurney To: Mark Johnston Subject: Re: dtrace -c doesn't work? Message-ID: <20131017172744.GF56872@funkthat.com> References: <20131015233219.GZ56872@funkthat.com> <20131017033400.GA31544@charmander> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131017033400.GA31544@charmander> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 17 Oct 2013 10:27:45 -0700 (PDT) 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 17:27:51 -0000 Mark Johnston wrote this message on Wed, Oct 16, 2013 at 23:34 -0400: > 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. We might want to document this somewhere since by default FreeBSD doesn't install debug binaries (maybe when it fails?), so by default dtrace won't be very useful for people... > 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. Wow, that is anoying to fix... Good luck.. > > 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. Ahh, yep, see that it works on my head machine, nice.. :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."