[fpc-pascal]TRY EXCEPT Bug
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:
>> 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:
/* ;WARNING WARNING WARNING
;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