On Tue, Oct 7, 2014 at 11:32 AM, Leonid Yegoshin
<Leonid.Yegoshin@imgtec.com> wrote:
Well, I am not a subscriber to mail-list, so I read it the first time and
some notes:
3) The signal happened during execution of emulated instruction - signals
are under control of kernel and we can easily delay a signal during
execution of emulated instruction until return from do_dsemulret. It is not
a big deal - nor code, nor performance. Thank you for good point.
If you go down this particular rabbit hole, you will never come back out.
What happens if one of those out-of-line instructions causes a
synchronous trap? What if SIGSTOP arrives before ret? What if
another thread removes the magic ret sequence?
4) The voice for doing any instruction emulation in kernel - it is not a
MIPS business model to force customer to put details of all Coprocessor 2
instructions public. We provide an interface and the rest is a customer
business. Besides that it is really painful to make a differentiation
between Cavium Octeon and some another CPU instructions with the same
opcode. On other side, leaving emulation of their instructions to them is
not a wise after having some good way doing that multiple years.
IMO this is all backwards. If MIPS customers put proprietary
instructions into their ISA, they leave out the FPU, and they put a
proprietary insn in a branch delay slot, then I think that they
deserve a fatal signal.
There's a really easy solution for new systems: fix the toolchain.
Teach the assembler to disallow any proprietary instructions in an FP
branch delay slot.