[fpc-pascal]TRY EXCEPT Bug
tom_at_work at yline.com
Mon Oct 2 18:42:54 CEST 2000
>>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
>>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+
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
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 =)
More information about the fpc-pascal