Break instructions, debuggers, FPU emu & tracing.

Break instructions, debuggers, FPU emu & tracing.

[Ralf Baechle]

do_bp() is running notify_die() for certain break codes, then invokes
do_trap_or_bp() which is going to run notify_die() yet again.  So it
is possible that notify_die() gets invoked twice.

This has caused some issues for my current project me but I'm wondering
especially about the existing code base, what is the intent here, what
notifiers do debuggers or tracers actually expect to be run, in what order?

Another observation is that the die notifier can be a relativly busy
place because the kernel FP software is running it for every instruction
emulated in a branch delay slot which is bad in particular when a
distribution built for hard floating point is running on FPU-less hardware,
as in my case Debian on an Octeon.  The increasing number of die notifier
functions has been silently slowing down the kernel fp software over the
years.  Which nobody has looked at because the FPU emulator has been so
reliable that nobody ever looked at it.  I'm wondering, should we create
a fast path for the FPU emulator only by skipping the die notifier?

  Ralf