<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Martin Frb <<a href="mailto:lazarus@mfriebe.de">lazarus@mfriebe.de</a>> schrieb am Di., 29. Okt. 2019, 20:08:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">About <a href="https://bugs.freepascal.org/view.php?id=34881" rel="noreferrer noreferrer" target="_blank">https://bugs.freepascal.org/view.php?id=34881</a><br>
<br>
First of all, big thanks to Sven for the patch.<br>
I had a look at it, I also looked through the alternatives again.<br>
<br>
First of all the patch would need some tweaking (but that is to be <br>
expected), but I am not sure it is the best way to go.<br>
<br>
Under gdb the issue is that there seems no way to access the data (added <br>
by the patch). And gdb itself does not seem to use it either (it does <br>
read the entries, but does not seem to further access them).<br>
Gdb actually does the same as the IDE does in none seh code. gdb sets <br>
breakpoints at "__cxa_begin_catch".<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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). </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">*** Other OS ??<br>
Are there any plans for such exception handling?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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 as well). </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
======================<br>
About the patch. ...<br>
The need to address the issues below, depends on the outcome of the <br>
above....<br>
<br>
1)<br>
program Project1;<br>
begin<br>
try<br>
try<br>
writeln;<br>
except<br>
writeln;<br>
end;<br>
except<br>
writeln;<br>
end;<br>
end.<br>
<br>
gives<br>
project1.lpr(2,6) Error: Internal error 2019102101<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, I didn't test nested blocks, because I wasn't yet sure whether there debug information should be siblings or nested as well. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2)<br>
The tag for a finally block point to the code in the function containing <br>
the try/finally. That is the asm instruction " call fin$1"<br>
However, in case of an exception this code is not executed. fin$1 is <br>
called from __FPC_specific_handler. So those addresses do not actually help.<br>
<br>
The dwarf spec is not too specific, but I am not sure how good an idea <br>
it is to have the "catch" address range in a different function.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yeah, I noticed that as well, but at least it could be used to set a breakpoint at the called function inside that range... </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
============<br>
Something else / Stepping<br>
Because finally is a subroutine, "step over / F8" does not enter it. <br>
That is not what the user expects.<br>
<br>
In FpDebug that can be solved.<br>
With GDB, that would require a lot of work, and probably slow down <br>
stepping quite a bit....<br>
<br>
However gdb does check the function after a call statement.<br>
program Project1;<br>
label a,b;<br>
begin<br>
writeln;<br>
asm<br>
call b<br>
jmp a<br>
b:<br>
nop<br>
nop<br>
ret<br>
a:<br>
end;<br>
writeln;<br>
end.<br>
<br>
And F8 will step into b (gdb 8.x). Because b is the same function. (and <br>
apparently gdb does some checks to distinguish this from a recursive call)<br>
<br>
So if fpc would write dwarf info where the function includes the finally <br>
code, then stepping would work.<br>
Though with the finally code currently being in front of the function <br>
body, it would need an entry point. (not tested...). Or the finally code <br>
could be moved to the end.<br>
<br>
Only tested with 64 bit.<br>
I can do more tests, if it is considered worth the effort.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">For the compiler the finally code is generated essentially as a nested function. It does not know the concept of a function following immediately afterwards. </div><div dir="auto"><br></div><div dir="auto">So that would be a rather complex undertaking that I don't believe is worth the effort. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>