[fpc-pascal]TRY EXCEPT Bug

[Thomas Schatzl]

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

That's why I was asking.

>  Why do you need to change this anyway ??

To add hardware exception #18 and #19 introduced by Pentium(!!!!)/PIII+
processors.

Not doing this will break all go32v2 programs using/detecting SSE
instructions (#19) running in an environment not supporting them (e.g. Win95
< OSR 2(.1 ?), MSDOS, etc.)
There are still quite a lot 'old' Win95 systems around running on PIIIs.

>Why can't you simply add some more signal handling routines!

Because hardware exceptions don't map to signals with go32v2 unlike with a
Unix environment. 'Signals' are simply a sort of software exceptions here
(the dpmiexcp unit does some mapping btw).
Simply updating the exception_count constants (and the corresponding arrays)
doesn't work, worse it will cause even more trouble since the the exception
handler addresses for above mentioned exceptions point inside the
exception_handler code in exceptn.as then - resulting in _really_ weird
crashes then.

Do you have another idea ?

Btw, I already implemented this stuff - it works fine.

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

Oh, sorry I didn't know. A striking reason though =)

Regards,
    Thomas