[fpc-pascal]TRY EXCEPT Bug

Thomas Schatzl tom_at_work at yline.com
Sat Sep 30 23:51:10 CEST 2000

Subject: Re: [fpc-pascal]TRY EXCEPT Bug

On Sat, 30 Sep 2000, Dirk Verwiebe wrote:

>> Hello,
>> i found out that the try except stuff doesn´t work if the unit crt is
>> compiled in the program where try.. except is used.
>> Is it a bug ???
>I don't know. The problem is that the crt unit now uses the dpmiexcp unit
>(to be able to have ctrl-c as input instead of having it abort the
>The dpmiexcp installs default signal handlers for most signals, so they
>are then caught by the dpmiexcp unit instead of by the system unit. Since
>the sysutils unit simply converts runtime errors (which also can be
>exceptions caught by the system unit and then converted into a runtime
>error) into exceptions, it won't work anymore.
>We can solve this by not hooking any exceptions anymore by default in the
>dpmiexcp unit, but I don't know if that's a good solution.

My suggestion is to move the basic exception stuff by default into the
system unit and remove the dpmiexcp unit.

Btw, I am currently working on updating the 'fully working exception
handling' :] to allow catching of the missing hardware exceptions. I've
stumbled upon the following remark in excptn.as:

   ;The mechanism for passing signals between the debugger
   ;and the debuggee relies on the *exact* instructions between
   ;EXCEPTION_ENTRY($13) above and "cmpb $0, forced" instruction
   ;below!  These instructions are stored in forced_test[] buffer
   ;in src/debug/common/dbgcom.c.  Do NOT change anything between
   ;these two instructions, or you will break signal support in
   ;the debuggers!!  */

Well, the problem is that to support those there is (well, I think so)
_need_ of breaking this warning. My question is whether this still applies ?
Because this would either mean that the go32v2 target won't get that support
anymore or breaking debugging support of all these programs....


More information about the fpc-pascal mailing list