[fpc-devel] 034881: Request debug info for SEH (finally/except) to prevent regression when win32 switches to SEH
pascaldragon at googlemail.com
Tue Oct 29 23:16:08 CET 2019
Martin Frb <lazarus at mfriebe.de> schrieb am Di., 29. Okt. 2019, 20:08:
> About https://bugs.freepascal.org/view.php?id=34881
> First of all, big thanks to Sven for the patch.
> I had a look at it, I also looked through the alternatives again.
> First of all the patch would need some tweaking (but that is to be
> expected), but I am not sure it is the best way to go.
> Under gdb the issue is that there seems no way to access the data (added
> by the patch). And gdb itself does not seem to use it either (it does
> read the entries, but does not seem to further access them).
> Gdb actually does the same as the IDE does in none seh code. gdb sets
> breakpoints at "__cxa_begin_catch".
When implementing the patch I saw a bug report on GDB regarding the
exception blocks (that's how I learned that ICC generates them), so it
seems that it does handle them in some case... (at least to get the C++
exception variable that has been caught).
*** Other OS ??
> Are there any plans for such exception handling?
FPC trunk now supports PSABIEH on i386 and x86_64 linux. You need to
recompile the compiler with -dPSABIEH as well as the library path set to
wherever libgcc.a resides (of course RTL and packages need to be recompiled
> About the patch. ...
> The need to address the issues below, depends on the outcome of the
> program Project1;
> project1.lpr(2,6) Error: Internal error 2019102101
Yes, I didn't test nested blocks, because I wasn't yet sure whether there
debug information should be siblings or nested as well.
> The tag for a finally block point to the code in the function containing
> the try/finally. That is the asm instruction " call fin$1"
> However, in case of an exception this code is not executed. fin$1 is
> called from __FPC_specific_handler. So those addresses do not actually
> The dwarf spec is not too specific, but I am not sure how good an idea
> it is to have the "catch" address range in a different function.
Yeah, I noticed that as well, but at least it could be used to set a
breakpoint at the called function inside that range...
> Something else / Stepping
> Because finally is a subroutine, "step over / F8" does not enter it.
> That is not what the user expects.
> In FpDebug that can be solved.
> With GDB, that would require a lot of work, and probably slow down
> stepping quite a bit....
> However gdb does check the function after a call statement.
> program Project1;
> label a,b;
> call b
> jmp a
> And F8 will step into b (gdb 8.x). Because b is the same function. (and
> apparently gdb does some checks to distinguish this from a recursive call)
> So if fpc would write dwarf info where the function includes the finally
> code, then stepping would work.
> Though with the finally code currently being in front of the function
> body, it would need an entry point. (not tested...). Or the finally code
> could be moved to the end.
> Only tested with 64 bit.
> I can do more tests, if it is considered worth the effort.
For the compiler the finally code is generated essentially as a nested
function. It does not know the concept of a function following immediately
So that would be a rather complex undertaking that I don't believe is worth
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel