On 24/02/2019 15:42, Jonas Maebe wrote:
On 24/02/2019 15:36, Martin Frb wrote:
On 24/02/2019 15:24, Jonas Maebe wrote:
On 24/02/2019 15:22, Marco van de Voort wrote:
It is part of the language, people have lived with it over 20
years. If it bothers you, help making exceptions cheaper (table
based exceptions/seh)
They're already working for Linux/i386 and LLVM targets in de
debug_eh branch. And of course for Win64 (and Win32 for the most
part if you compile a custom compiler).
Will there be any efforts to add debug info, so a debugger can find
except and finally blocks?
https://bugs.freepascal.org/view.php?id=34881
Or maybe I am missing some existing info?
There is a presumably a standard approach for this, which should be
investigated by a Windows developer before we try to create our own
solution. I don't know what the standard way to handle this with
Dwarf-based EH either (maybe the debugger is supposed to parse the EH
tables?)
Its not that easy.
The best the debugger can do, is to find the entry point of the
handlers. e.g. __FPC_finally_handler
For those there may even be symbols in the debug info, or from the
linker..., so given that the debugger only needs to deal with fpc,
knowing that name is fine.
The except handlers (only on windows 64) can be gotten by intercepting
the entry to a kernel method...
But what can for example not be gotten, is the finally handler. You can
intercept __FPC_finally_handler (on 32 bit, there is a similar handler
for except), but you do not know where this calls the finally handler.
Now of course, __FPC_finally_handler get the address for the actual
finally from the SEH info. I do not know if that part is standardized,
or if the SEH tables can contain compiler dependent data.
But parsing the SEH tables is problematic too. The debugger would have
to know everytime that they change.
With an external debugger like gdb, if this process needs to be
controlled by the IDE, then it will be extremely slow. Constantly having
to read the SEH info. And having to update dozens of breakpoints.
Because as it stands, the debugger needs to have a breakpoint for each
and every finally handler that is surrounding the current code.
There no longer is a single point.
Well there is: If the debugger can intercept at __FPC_finally_handler.
But for that, it then needs to have reliable info, thaw will be stable
for future fpc versions, on how to parse the arguments of this function,
to find the finally handler that will be called.
As long as the format of those arguments are not documented and stable
(forward compatible), it will not be practical to intercept for finally.
--------------
On win 64 for "except" this is the case. The code calls the windows api
(unwind), and that is documented, so the debugger knows where the
address of the except handler is.
The debugger can then set a temp breakpoint, and intercept the except
handler.
For finally (and 32 bit except) no kernel method is called.
--------------
Further more / Different issue.
Finally handlers are now subroutines.
That means (if there was no exception) "step over" will step over the
entire finally handler. That is not desirable.
I don't think it is possible to tell gdb that this subroutine is part of
the same code.
Well maybe, it would have to be tested. Gdb actually always steps-in.
And then tests if it needs to step out.
Maybe if the at_pc_low/high would include the finally handler, and there
was no separate dwarf function entry, maybe then it would work (though
that might break locals, depends on if dwarf_frame info is used by gdb,
to unroll the (e/r)bp.
Otherwise at least a concept could be found, that FpDebug could in
future use to detect that a finally sub, is not a sub (well worst case
fpdebug can look at the mangled name).
--------------
All this is based on what I have seen for win32/64
IIRC there is talk of SEH on other OS? Which may lead to similar issues.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
