Sender: nate AT cartsys DOT com
Message-ID: <36E86BBA.B88F8D3E@cartsys.com>
Date: Thu, 11 Mar 1999 17:19:54 -0800
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.1 i586)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: Getting cr2 in exception handler
References: <36E1D56E DOT ABB127DE AT cartsys DOT com> <36e3eacd DOT sandmann AT clio DOT rice DOT edu> <36E47DA4 DOT D9E2374B AT cartsys DOT com> <36e6eb89 DOT sandmann AT clio DOT rice DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Charles Sandmann wrote:
> 
> > Actually, I realized another problem with such an approach.  If I get it
> > from anywhere besides the exception handler stack (as not supported by
> > CWSDPMI), another page fault may have occurred since then, i.e. in
> > swapping in my signal handler.
> 
> Correct, and I'm not sure that CWSDPMI itself doesn't clear CR2. 

It does, actually, as I found out a little while ago.

> But
> I have thought about this problem before many years ago, and I think a
> path was left to get there.  For example, you might have to replace the
> DJGPP exception handler for page faults with one of your own (which was
> already ring 0), and lock that handler - which would probably be good enough.
> 
> > It shouldn't be all that dangerous to run in ring 0 anyway.
> 
> Some features like timers and CTRL-C/break don't work, and actually
> generate some ugly behavior - so be careful :-)

Oh fun.  I'm getting a little out of my depth here, and all this is WAY
beyond the scope of my project.  At this point I think I may just let
the program crash with the standard traceback, and let the user use the
usual debuggers to sort out the mess.  I'll surely get inspired later to
make it work.
-- 

Nate Eldredge
nate AT cartsys DOT com