Hi,
That would indeed vastly complicate matters. Are you sure the unreliable
bug isn't due to the page in question having been mapped in nonetheless?
No. Would the kernel map 16 or 17 pages following a mmap? Maybe glibc is
causing them to be paged in too early?
16 or 17 pages - maybe not. OTOH, if we get the F-line trap before the page
fault, all is well.
But this is a secondary problem anyway.
No idea what to do about (1). Since I don't understand the
implications of "overlapped execution", I can't hazard a guess as to
whether this kind of fix is even theoretically feasible.
What this means is that one instruction is in the process of being
executed while another one is being loaded and decoded at the same time.
That's what I thought.
Loading it would trigger the page fault while executing of the previous
one had triggered the unimplemented instruction exception just
previously. Only guessing here...
Thing is, we have to know exactly what the saved PC will be when either,
a. ATC fault at unimplemented fpu op and bug may or may not take effect
Bug takes effect - the PC is what we need.
Bug does not take effect - the PC is that of the instruction causing the page
fault, i.e. identical to the fault address (ISTR instruction execution always
completes before trap or page fault in the normal case, and the trap must've
completed otherwise we'd see the PC point to the FPU opcode)
b. ATC fault with no unimplemented fpu op
PC is equal to fault address.
The point I was trying to make is that only for (a) is the saved PC
determined (that's what the docs I quoted tell me, anyway). Which means,
the fault handler can't tell (a) and (b) apart.
It all hinges on the behavior in the case where the bug isn't properly
triggered. If the PC points to the same page as the fault address in that case,
we're fine, i.e.
if (page_of(PC) < page_of(fault_addr) && is_fpu_op(PC)
need_fixup;
would be possible.
Your test kernel would be the ideal candidate to test whether there ever is a
case where the F-line trap was taken correctly, yet the PC still reported on
the wrong page afterwards.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
