Mail Archives: djgpp-workers/2000/01/19/06:20:12
On Fri, 14 Jan 2000, Bill Currie wrote:
> Esa A E Peuha wrote:
> > /* Pass exception to client */
> > addl %ebp, %ebp /* Item size now 8 */
> > cs
> > addl _current_exception_table, %ebp
> > pushl $except_return_point /* Return EIP */
> > cs
> > pushl 4(%ebp) /* Handler CS */
> > cs
> > pushl (%ebp) /* Handler EIP */
> > movl $gdt_code32_sel, %ebp
> > xchgl %ebp, 12(%esp) /* Return CS */
> > lret
> If you can, check the CPL at this point and the DPL of the handler (as
> on the stack). If DPL < CPL (numericly), you will get a GPF. Note, I
> can't see why this would be the case.
Neither do I, since the interrupt passing code works (it would also be
affected by this, wouldn't it?).
> Hmm, are you sure the GPF is happenning at the lret? It may be happening
> at the lret (iret? been too long) of the handler. It is illegal to lret
> (or iret) from (eg) cpl=3 to cpl=0.
Well, the server exception handler prints the CS:EIP, and that does point
to this particular lret (which is currently pointed to by the global label
faulter in the actual sources, to make it easier to locate). Is there
any possibility that this might be wrong?
> What needs to happen is the dpmi server needs to lret into the correct
> cpl, call the handler, then ljmp through a gate to the rest of the dpmi
> server.
> pushl $handler_stub_cs /* alias for dpmi seg, but has correct PL */
> oushl $handler_stub
> lret
> handler_stub:
> lcall (handler)
> ljmp dpmi_handler_gate:junk
> dpmi_handler_gate_dest:
> ...
> Note, this is highly simplified (you need to handle the stack changes,
> etc), but it should give you an idea.
Thanks, I'll implement that.
--
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/
- Raw text -