[fpc-devel] Insufficient Dwarf info for Interfaces

[Michael Van Canneyt]

On Thu, 15 Sep 2022, Martin Frb via fpc-devel wrote:

> On 15/09/2022 16:17, Michael Van Canneyt via fpc-devel wrote:
>> 
>> 
>> On Thu, 15 Sep 2022, Martin Frb via fpc-devel wrote:
>> 
>>> https://gitlab.com/freepascal.org/fpc/source/-/issues/39904
>>> 
>>> On top of adding the functions in the interface to the dwarf info, it 
>>> would be great if the compiler could also add some sort of link to the 
>>> underlaying TObject.
>>> 
>>> So the debugger could (if available) show the user the object/instance 
>>> that implements the interface.
>> 
>> I believe the whole idea of interfaces is that this info is not available 
>> :-)
> Well yes... From the applications point of view.
>
> From the debuggers (or rather the user doing the debugging) point of view, 
> there is only the question of "can it be done/implemented" (IMHO)

I think the compiler people are better suited to judge this than I am...

>
> When the compiler generates the jump pads for an interface (that is 
> implemented by an object in the app), then the compiler knows the object 
> exists, and the compiler has all the info. It only needs to make it available 
> to the debugger.
>
> The debugger would then need to be able to check, if the address in the 
> interface variable points to such a jump table.
> Either by checking if it is in the correct memory range, or better by finding 
> a dwarf entry describing this address as an "interface vmt". In the latter 
> case that dwarf info could hold in some way the offset for self, and the 
> pointer to the dwarf info for class type (since the interface as a separate 
> jump table at a diff address for each class that implements it)
>
> I understand that it may be deemed to much work.... But it would be helpful.

No argument there.

>From what I can see after some limited testing, Delphi also does not have this info.
I don't know if it is because it is not possible or just because they did
not implement it...

Michael.