Date: Thu, 17 Oct 2013 10:14:44 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mark Johnston <markj@FreeBSD.org>, John-Mark Gurney <jmg@funkthat.com> Cc: Konstantin Belousov <kib@FreeBSD.org>, freebsd-dtrace@FreeBSD.org Subject: Re: dtrace -c doesn't work? Message-ID: <525F8E64.4020105@FreeBSD.org> 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
on 17/10/2013 06:34 Mark Johnston said the following: > 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). That's exactly what happened. My idea of fixing that was to move r_debug_state call to after preinit_main. But Kostik told me that that was a terrible idea. Unfortunately I can't recall right now why. I've been meaning to restore my knowledge and memory of the code and discuss the issue again. > 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. Kostik also suggested this. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?525F8E64.4020105>