www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/02/18/05:17:33

Date: Tue, 18 Feb 1997 12:00:13 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: a DOT vignani AT crf DOT it
cc: djgpp AT delorie DOT com
Subject: Re: For DOSEMU users - djgpp and ^C troubles
In-Reply-To: <01IFJ51UV6J6APTK95@CRF.IT>
Message-ID: <Pine.SUN.3.91.970218115938.20000E-100000@is>
MIME-Version: 1.0

On Mon, 17 Feb 1997 a DOT vignani AT crf DOT it wrote:

> >	3) when your program accesses any of its data, the invalid DS
> >causes an exception;
> >
> This is what I see. There is a SetSegmentLimit(0xcf,0xfff) as soon as
> ^C is written in the BIOS keyboard buffer, and since ds=es=ss=0xcf this
> is the cause of the stack fault.

That would suggest that the DOSEmu DPMI host doesn't switch to a
separate stack when an exception hits.  You could probably see if
that's the case by looking at the Linux sources.

> 1st exception there is now another SetSegmentLimit (0xcf,0x5ffff);
> after that, my handler is called. It then calls _exit, and all works
> fine.

This seems like the DJGPP exception processor at work: when the
exception happens, it makes DS selector valid again, then calls your
handler.

> Maybe the client code is killed before it gets a chance to change the
> segment limits again; as a result, in the 'normal' case, _exit doesn't
> get called.

That's what it looks like, yes.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019