From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org, David Daney <ddaney@caviumnetworks.com>
Subject: Break instructions, debuggers, FPU emu & tracing.
Date: Wed, 9 Oct 2013 13:20:34 +0200 [thread overview]
Message-ID: <20131009112034.GM1615@linux-mips.org> (raw)
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
reply other threads:[~2013-10-09 11:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131009112034.GM1615@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=ddaney@caviumnetworks.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox