Date: Wed, 16 Oct 2013 23:34:00 -0400 From: Mark Johnston <markj@freebsd.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-dtrace@FreeBSD.org Subject: Re: dtrace -c doesn't work? Message-ID: <20131017033400.GA31544@charmander> In-Reply-To: <20131015233219.GZ56872@funkthat.com> References: <20131015233219.GZ56872@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131017033400.GA31544>