Re: Adding(?) XI support to MIPS-Linux?

[Brian Foster <brian.foster@innova-card.com>]

On Wednesday 11 June 2008 15:16:56 Brian Foster wrote:
>[ ... ]
>  It's [ ... ] the trampoline that has “something to do with
>  FPU emulation”, which has me concerned ATM.  [ ... ]
> 
>  The quick summary [ ... ] is the FP trampoline, which is pushed
>  on the user-land stack is, unlike sigreturn, not fixed code.
>  It varies on a per-instance per-thread basis.  Hence the
>  simple ‘vsyscall’ mechanism ((to be?) used for sigreturn)
>  is inappropriate.
> 
>  The trampoline is only used to execute a non-FP instruction
>  (<instr>) in the delay slot of an FP-instruction:
> 
      [ point A "before" <instr> ]
>      <instr>  # Non-FP instruction to execute in user-land
      [ point B "after" <instr> "before" BADINST ]
>      BADINST  # Bad instruction forcing return to FP emulator
>      COOKIE   # Bad instruction (not executed) for verification
>      <epc>    # Where to resume execution after <instr>
      [ user-land stack-pointer points here(-ish) ]

 Whilst thinking about the problem and possible solutions,
 it occurred to me there could be a defect in the current
 trampoline:  Suppose there is a signal, either at point A,
 due to <instr> itself, or at point B, which is caught on
 this stack, and the user-land signal-handler ‘return’s.

 Doesn't the signal-handler/sigreturn stack-frame overwrite
 the FP trampoline?   In which case, when the signal-hander
 returns, more-or-less anything could happen.  (And very
 unlikely to be what's wanted!)

cheers!
        -blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com