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 am not sure how that would best be done (i.e. maybe add some internal field, maybe there is some dwarf tag that can be used, maybe a dwarf extension....)
From what I  understand, this would require the offset between the interface table and the class (i.e. the value that is subtracted from "self" in the interface's method).
If for a debug build the compiler could write that value in front of the interface, then it could point the debugger to it....

Just my 2 cents.

I believe the whole idea of interfaces is that this info is not available :-)

For externally implemented interfaces (COM and the like) this will definitely not be available.
Delphi has a special interface which - when implemented - returns the object (TComponent) behind an interface.
You can then query this interface and get a reference to the object. It's called IInterfaceComponentReference

Michael.

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)

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.

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

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.

You are aware that an interface can be implemented by multiple different class types and that the offsets for each class that implements a specific interface will be different depending on the amount of interfaces a class implements? So if you have a given interface neither you nor the compiler will know what is on the other side.

Regards,
Sven

Yes.

And I am also aware that for each class that implements the interface, their is a separate set of jump pads (with code adjusting "self" by that offset), and there is a "interface vmt" for those jump pads.

If TFoo implements ISome, then A:ISome = $100010
If TBAr implements ISome, then A:ISome = $102210

So there are 2 options
1) the compiler writes the "offset" at $100008 and $102208 (4 or 8 bytes before). (only if debug info generation is on)
The the debugger needs to figure out this is implemented by a class (and not external)

2) The compiler writes separate dwarf for the 2 version of the "interface vmt".
And It says "this is at address xxxx"
THen the debugger does a reverse lookup by address => and finds the dwarf info for the "interface vmt"
The problem is to find what dwarf info to use. It must include the address, and then the offset (or an dwarf expression to calculate the object instance).
This dwarf info for the interface can also link to the type of the instance (the class that implements the interface)

The compiler already writes stuff to dwarf like
  DW_TAG_structure_type
  with name   $VMTDEF$TBARU2
  and a size
  but no other info.

Unfortunately this is a type declaration, so it does not have an address... (which is really required)

This will likely need a custom dwarf entry. Or tweaking an existing, such as including an DW_AT_Location
OR a DW_TAG_VARIABLE to hold the address for this type

----------
All the info is already there, except really not accessible.

If the debugger has an interface, and it says address=$1002233 => the debugger can look up the first method of the interface => check the code is in one of the compilation units (code generated from pascal source)
=> disassemble the code to get the offset
=> calculate the address of the object instance
=> use RTTI to get the classname.
=> find the dwarf for that class, typecast, and voila