Messages in this thread | | | Date | Tue, 7 Oct 2014 12:13:37 -0700 | From | Leonid Yegoshin <> | Subject | Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area. |
| |
(repeat it because of some e-mail failure, sorry)
On 10/07/2014 11:43 AM, David Daney wrote:
>> Five lines per instruction. > But you must be able to emulate them, so you need an emulator, not XOL.
I feel I didn't say clear - emulation of ADDIUPC (after second look it is the only instruction requires a special handling) is A FIVE LINE OF CODE. At least in MIPS R2 it would require 5 lines. In MIPS R2 emulator I have some routine (50 lines) which checks BD-slot instruction for some popular opcodes and emulates that and leave other opcodes to dsemul().
The same can be done for FPU emulator.
> The problem is what to do with synchronous signals (SIGSEGV) Those > cannot be held off, and you really want the EPC value saved in the > register state to be correct.
Any synchronous exception is not a problem, we know that emulation in VDSO (read today - stack) is running and should take care of it. We can easily change EPC before we start doing signal and pretend that problem happened in correct place.
The async signals seem to be some problem... yet... until I finish look into common Linux kernel code, I think.
On 10/07/2014 11:44 AM, Andy Lutomirski wrote:
> What happens if one of those out-of-line instructions causes a synchronous trap?
If we need to return that as signal then we change EPC to proper value from emulframe->epc. If we do a nested emulation - continue.
> What if SIGSTOP arrives before ret?
I am looking into way to delay asynchronous signals until an emulated instruction is finished. Signals are not time accurate and never been, so it is not a big deal to delay it.
> What if another thread removes the magic ret sequence?
It can't do it in my approach, emulation is done in write protected area and it is done in per-thread memory space.
- Leonid.
| |