[fpc-pascal]TRY EXCEPT Bug

[Pierre Muller]

At 23:51 30/09/00 +0200, you wrote:
>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....
I strongly object to this!!!!!!!!!!!!!!!!!!!!!!!!

 This will break signal support for GDB and a spent a lot of time to
getting this to work !!!

  Why do you need to change this anyway ??
Why can't you simply add some more signal handling routines!



  Removing dpmiexcp completely will create a big problem:
we will not be able to link to C code anymore :(

 The reason is that dpmiexcp.pp is very uggly mainly because
it has to define all assembler global symbols that are
defined in dpmiexcp.c source in order to avoid
loading of the corresponding object file which would code
duplicate assembler identifier errors in linking.