From:	alaric AT abwillms DOT demon DOT co DOT uk (Alaric B. Williams)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Problem raising exceptions in tight loops
Date:	Sun, 01 Dec 1996 19:23:08 GMT
Lines:	30
Message-ID:	<849468187.25048.0@abwillms.demon.co.uk>
References:	<849360845 DOT 357 DOT 2 AT abwillms DOT demon DOT co DOT uk> <32a07964 DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host:	abwillms.demon.co.uk
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote:

>This causes an exception INSIDE the DPMI provider itself when it tries to 
>transfer control back to your application, so it doesn't work.  That was
>the first thing I tried.  All real GCC programs touch memory at some point
>(either the stack, or a memory reference) so this is only a problem for
>nonsense programs.  The only example I could come up with this case could
>not handle was polling an I/O port for a change - and if you do this and
>want to interrupt it, touch some memory in the tight loop. 

How about having a spare CS selector created. To raise a signal, set
the limit of it to the return EIP plus a couple of bytes, then execute
a far return, reloading the new CS?

That way, the return code segment is at least valid, only the next
instruction can't be fetched without throwing an exception.

ABW
--

"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."

(Windows for Early Warning and Defence User's manual P385)

Alaric B. Williams Internet : alaric AT abwillms DOT demon DOT co DOT uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>

- Raw text -