Date:	Tue, 19 Jun 2001 11:31:34 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: [PATCH] avoid problems with higher exception handlers
In-Reply-To:	<4.2.0.58.20010618131819.01766f10@ics.u-strasbg.fr>
Message-ID:	<Pine.SUN.3.91.1010619113114.7390C-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 18 Jun 2001, Pierre Muller wrote:

>    The assembler function change_exception_handler
> write the value of the exception to an array app_handler
> and calls the real int 0x31 interrupt (that it hooks) with
> the values of its own handlers.
> 
>    But there is a missing check for the exception number.
> This led to a bug when I added handlers for exception 18 and 19

Indeed.  Thanks for the patch.

> Below is a patch that both
> increases the array size to 20 (19 is the highest exception I am aware of 
> until now,
> and adds a check to avoid writing if the exception number is greater.

Why is it a good idea to enlarge the exception count to 20?  exceptn.S
doesn't support anything beyond exception 17, so I'm afraid this could
break debug support.

For that matter, is it really possible for a DJGPP program to receive
exceptions 18 or 19?  AFAICS from the Intel documentation, these
exceptions require special setup of the processor.  For example,
exception 18 needs a special bit be set in CR0 and a trap gate be put
into the IDT.  Do we have any reason to believe that any popular DPMI
host out there actually enables these goodies for protected-mode DOS
programs?

> As I told you, I have added support for these two (18 and 19) exceptions
> in my dpmiexcp.c equivalent, but I think that it is probably much safer to
> postpone this integration to after next release, in order to avoid having 
> people using the old GDB with new executable that would crash the debugger.

It's a double compatibility problem: not only will a modified
dpmiexcp.c crash old debuggers, but it will also require tricky
changes in dbgcom.c where it looks for the `forced' variable in the
debuggee.  That's because (as I understand) support for 2 more
exceptions requires changes in exceptn.S, to set up a handler for
those exceptions.  That would change the code sequence on which the
test for `forced' is based.  We will then need to arrange for being
able to find `forced' both in old and new DJGPP executables.

Is this really worth the hassle?  What do we lose by not supporting
exceptions 18 and 19?

- Raw text -