Re: FPU Emulation and Signals - An Alternative Fix

So I submit the following for your consideration.
In the FP emulator, when we set up the trampoline, we set
up the following above  the user stack:

            Instruction-to-be-executed
            AdELOAD (unaligned load of r0 off of r0)
            Magic-cookie-that-is-an-unimplemented-instruction
            EPC-to-use-on-completion

Rather than use thread.desmul_epc as a flag to indicate
to the unaligned access handler that there is emulation
going on, the unaligned access handler would test to see
if the unaligned access instruction itself was the AdELOAD,
and that it is followed by the magic cookie, and if so, treat 
that as an indication to stuff the value following the sequence
(as indicated by EPC, modulo branch delays) into the EPC 
and return.   This way, one could nest an arbitrary number of 
emulation/signal/emulation sequences, and they should unroll 
correctly.  The further magic cookie is needed since, even though 
it's a completely useless instruction, the AdELOAD could be 
encountered for other reasons, as a misguided attempt
at cache prefetch, or by executing crashme. It's a useless instruction 
to emulate, having r0 as the destination, but the normal Linux semantics 
as I understand them would be to turn it  into a very expensive 
no-op and continue in what might otherwise be safe and sane 
execution.  With the addtional code word after the AdELOAD 
(and before the EPC) on  the dsemul stack that would be (more-or-less) 
guaranteed  to really be an illegal instruction, the only risk we would 
be taking would be to have a  program really containing the 
unaligned nonsense load followed by the  illegal instruction 
blow up, not on the illegal instruction, but by picking up a bogus 
EPC.  Not perfect.  But maybe the lesser of several evils.

One further embellishment and one further alternative to
consider:  The thread data field currently used to store the
post-trampoline EPC value can be renamed and used
instead as a counter of the "depth" of FP branch delay
slot emulation.  If the count is zero, the unaligned access
trap does not look for the magic sequence described 
above, and just emulates the AdELOAD instruction.
Unfortunately, a signal handler that invokes a longjmp
will not return to the trampoline, not invoke the associated
trap, and thus not decrement the counter, so a non-zero count 
cannot be taken as absolute proof that a branch emulation is
pending.  The hack would further reduce the probability
of a "naturally occurring" AdELOAD/MagicCookie
sequence being mishandled, not eliminate the possibility.

The scheme proposed above allows arbitrary recursion
(a Good Thing) but also misdiagnosis of a wildly improbable
but conceptually possible error condition (a Bad Thing).
An alternative - still in conjunction with the proposed
gap-between-user-stack-and-signal-stack technique - 
would be to replace the single EPC storage location
in the thread data with, say, three storage locations
and an additional variable that serves as a sort of
"stack pointer" for the EPCs.  In this model, the EPCs
are kept off the user stack and no magic cookies are
needed.  If nesting of FP branch emulation exceeds
three, the process gets nailed with a fatal error.
This would not allow arbitrary recursion and would
increase the static size of the thread data structure
(Bad Things), but would, within the constraints of the
allowed depth of recursion, create no ambiguous 
situations (a Good Thing).   Any comments or declarations
of preference?   I guess it boils down to the question of
what is more probable, a naturally occurring sequence
of AdELOAD/MagicCookie or a 4-way nesting of
signals delivered in the branch emulation delay trampoline
window.  Both strike me as unlikely, but I feel more
confident about my estimate of the former than of the later.

Sorry to bore 95% of you to tears with this stuff, but
it really does matter to some of us, and I don't presume
to know exactly who on the list could have valuable
input.

            Regards,

            Kevin K.