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