Sender: bill AT delorie DOT com Message-ID: <387EF75A.C883B18B@taniwha.org> Date: Fri, 14 Jan 2000 23:15:54 +1300 From: Bill Currie X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: MWDPMI exception handling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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. 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. 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. eg 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. Basicly, whats needed is two (4 if pl 1 and 2 supported) extra descriptors: one that is a pl3 alias of the dpmi server segment (you might be able to get away with this using conformant segments), and one that is a call gate pointing to the return location within the server. Hmm, I suspect conforming segments were designed for this reason. HTH Bill -- Leave others their otherness. -- Aratak