Request debug info for SEH (finally/except) to prevent regression when win32 switches to SEH
Original Reporter info from Mantis: Martin @martin_frb
-
Reporter name: Martin Friebe
Original Reporter info from Mantis: Martin @martin_frb
- Reporter name: Martin Friebe
Description:
This issue is about:
- current Win64 SEH debug info. (to enable fixing some features of the debugger)
- upcoming Win32 SEH debug info. (to prevent regressions to the debugger)
- any other future changes to exception handling on any platform.
The debugger (in the Lazarus IDE) has several features regarding exception handling:
-
Single step over an ignored exception:
- Either steps normally to the next line (if except handler is inside the stepped-over code)
- Or steps to the except (or finally) handler. Similar to "step out", regarding the except handler as the next statement to which the current function returns. -
If stopped at an exception (stopped at raise / fpc_raiseexception), then step-over/out will go to the next except/finally handler.
-
deal with fpc_reraise during stepping in the same manner as 1 (step to next handler).
----------
For this the debugger needs to be able to set a breakpoint that will stop when any except or finally handler is entered.
Without SEH this can be done by intercepting fpc_popaddrstack. (and then step out once)
With SEH this is not called.
On Win64 the debugger can get the address of the next "except" (but not "finally") handler by intercepting calls to the kernels RtlUnwindEx.
Fpc code passes the except handler address as argument, so the debugger can set a breakpoint on the correct except handler(s).
However an Win64 for a "finally" handler the OS calls __FPC_specific_handler.
And somewhere within it, this function will call the finally handler. The debugger has no way, where in that function the call to "finally" is made. It has therefore no way to intercept it. (It would need to set a breakpoint in the middle of __FPC_specific_handler, but there is no debug info to find the line that calls "finally")
In the Win32 SEH branch, there is even less information.
I did some testing with SEH, and IIRC (but not sure its a while ago) I could not catch except nor finally.
There are 2 Handlers that are being called:
__FPC_default_handler
__FPC_finally_handler
Both call the except/finally handler directly. (So again would need a breakpoint in the middle of it)
Any idea how to add/use debug info, so a debugger can deal with the above?
For anything GDB can not handle on its own, the IDE must be able to extract this info with the help of GDB and then set breakpoints to deal with it.
----------
Furthermore entering a finally handler (without an exception) is now a call to a function.
Stepping with F8 will step-over it (tested with GDB).
It needs to be explored if information can be added, to prevent this.
Also if there is no such info for GDB/LLDB, it should still be explored how this information can be embedded for the upcoming FpDebug (worst case is to guess from the function name)
Mantis conversion info:
- Mantis ID: 34881
- OS: win
- OS Build: -
- Platform: win32 / 64 / any SEH
- Version: 3.2.0
- Monitored by: » @martin_frb (Martin Friebe), » Cyrax (Cyrax)