[fpc-devel] SEH debug info [Re: "Blank slate" next version of FPC]

[Martin Frb]

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.