[fpc-devel] -dTEST_WIN32_SEH

[Sergei Gorelkin]

13.04.2014 18:20, Martin Frb пишет:
> Just been looking at this, and trying to thing of how to catch in the debugger.
>
>  From a very brief look at the sources (please correct me, if I got it wrong, or missed anything)
>
> An error handler is installed to the OS, the handler is
> function syswin32_i386_exception_handler(excep : PExceptionPointers) : Longint;stdcall;
>
> This handler returns instructions (ignore, or alternative instruction pointer) to the OS ?
> If this exception is handled it goes to JumpToHandleErrorFrame ?
>
> Then in there the "longjmp" is triggered, and presumingly goes to the "except" block ?
>
With TEST_WIN32_SEH defined, syswin32_i386_exception_hander, longjmp, JumpToHandleErrorFrame and all 
other stuff from system.pp is no longer used. Instead, code from seh32.inc is used.
For every try..except or try..finally block, an individual handler is installed on stack, 
consisiting of pointer to one of __FPC_finally_handler, __FPC_except_handler, __FPC_on_handler or 
__FPC_except_safecall routines, and an "argument", which points to "except" block, "finally" code or 
an array of TFilterRec records preceded by 4-byte count, depending on the handler kind.

> If so, how can the debugger get notified (before the longjmp), in a way, that it can get the address
> where the problem occurred?
>
> with raise exception the debugger can set a breakpoint, because raise exception is defined [public
> alias ...] so the debugger can read the address by knowing the name.
> But the new code does not have that....

The new fpc_raiseexception procedure has the same public alias as before. Each of the handler 
routines mentioned above also has a public alias.

Regards,
Sergei