Date: Tue, 19 Jun 2001 11:31:34 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Pierre Muller 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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?