I analyze FreePascal exceptions handling. Instead use of try-excpt-finally statement I rather use fpc_LongJmp,fpc_PushExceptAddr etc. It works fine for software exceptions (fpc_RaiseException) but not handle hardware exceptions. I use install_exception_handlers at start program. This call SetUnhandledExceptionFilter(@syswin32_i386_exception_handler) but is problem:
in syswin32_i386_exception_handler is comparing "if excep^.ContextRecord^.SegSs = _SS then" - _SS is correct stack segment but excep^.ContextRecord^.SegSs - no, it is a different value, why? I can attach my files

best,
Andrzej Borucki

Andrzej Borucki wrote

I analyze FreePascal exceptions handling. Instead use of try-excpt-finally statement I rather use fpc_LongJmp,fpc_PushExceptAddr etc. It works fine for software exceptions (fpc_RaiseException) but not handle hardware exceptions.

FPC relies on the hardware exception support provided by the operating system. For Windows this is accomplished by using
SetUnhandledExceptionFilter (or using SEH on Windows 64 if the compiler is compiled with the correct define) while on Unix this means that signals like SIGSEGV or SIGFPE are hooked.

It is not recommended to use "fpc_LongJmp", "fpc_PushExceptAddr" etc. manually as FPC's code generation could interfere with your intentions here (note: the correct way of using longjmp would be by using the function LongJmp instead of fpc_LongJmp (and likewise SetJmp instead of fpc_SetJmp).

So: why are you doing this?

Why are you doing this? install_exception_handlers is called during process entry of Win32/Win64 programs already, so calling this twice can be considered a bad(TM) idea.

Regards,
Sven

2012/12/16 Sven Barth

Maybe hence problems. I want to create own compiler for simplified language with exceptions. I analyze exceptions handling by copying fpc_NNN and setJmp routines to Delphi.

Regards,Andrzej