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

greetings

DirkVerwiebe

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

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.

But how can i now catch such exceptions ?

Dirk

Dirk Verwiebe wrote

> 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. But how can i now catch such exceptions ?

a) don't use the crt unit
b) edit the dpmiexcp.pp unit and remove the call to "ResetDefaultHandlers" in the unit initialization section (note that it looks a bit weird, because the dpmiexcp unit is both used as an include file for the system unit and as a separate unit)

Jonas

Hello,

it's a(nother) problem in dpmiexcp.pp.

Here's the fix:

Replace line 194 in that file:

  djgpp_hwint_flags : longint;external name '___djgpp_hwint_flags';

with

  djgpp_hwint_flags : Word;external name '___djgpp_hwint_flags';

and

Replace line 1362

    ResetDefaultHandlers;

with

    {$IFNDEF EXCEPTIONS_IN_SYSTEM}ResetDefaultHandlers;{$ENDIF}

This _should_ fix this problem. Could some of the developers change that asap ? Hopefully it's the correct define to be used, there are a whole lot of them floating around ;)

Regards,
Thomas

Subject: Re: [fpc-pascal]TRY EXCEPT Bug

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

I think that this is the only solution. The system unit should handle such stuff.

Michael.

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.

?

>Because this would either mean that the go32v2 target won't get that

support

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.

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

Regards,
Thomas

Then we should add them before :

EXCEPTION_ENTRY $18
EXCEPTION_ENTRY $19
EXCEPTION_ENTRY $0

this will require some changes in the
djgpp_exception_setup function
but its not that difficult !