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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
