ddb breakpoints and dtraceall.ko
Mark Johnston
markj at FreeBSD.org
Thu Mar 5 03:23:07 UTC 2015
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.
More information about the freebsd-hackers
mailing list