[fpc-pascal]TRY EXCEPT Bug

[Thomas Schatzl]

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
>program).
>
>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.
>
>Jonas

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....

Regards,
    Thomas