Date: Thu, 5 Mar 2015 03:22:27 +0000 From: Mark Johnston <markj@FreeBSD.org> To: Navdeep Parhar <np@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: ddb breakpoints and dtraceall.ko Message-ID: <20150305032046.GA66171@muskytusk> In-Reply-To: <54F7B053.7060004@FreeBSD.org> References: <54F7B053.7060004@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 04, 2015 at 05:24:35PM -0800, Navdeep Parhar wrote: > Breakpoints in ddb don't seem to work if dtraceall.ko is loaded. I'm > able to set a breakpoint but the kernel doesn't enter the debugger when > it should. Note that this is with dtraceall.ko loaded only, there are > no active DTrace probes. Unloading dtraceall.ko fixes the problem. > > Anyone else see this too? Hi Navdeep, Looks like this is an artifact of the way that DTrace hooks into the breakpoint handler. When the DTrace hooks are installed, a breakpoint results in a call to dtrace_invop(), which in turn calls fbt_invop(), which looks for a matching DTrace probe based on the trap address. If you place a breakpoint on the beginning of a function and a corresponding fbt probe exists, fbt_invop() will find a match and handle it, so DDB never sees the trap. My immediate thought was to add a "probe enabled" flag to struct fbt_probe, but I don't see a good way to avoid races: if a probe fires but is disabled before the thread gets to fbt_invop(), we'll wind up in kdb_trap(). We could try using an IPI to ensure synchronization, which I think would work on amd64 since breakpoint traps are handled with interrupts disabled, but I'm not sure whether that could be easily made to work on all arches. Then again, I'm not sure whether arches (arm, powerpc) have this problem in the first place, since they may use an illegal instruction rather than a breakpoint to trigger a DTrace probe.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150305032046.GA66171>