[fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)

[Martin]

On 11/09/2011 22:36, Graeme Geldenhuys wrote:
> On 11/09/2011, Jonas Maebe  wrote:
>> Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone
>> submitting a proposal to add them to the DWARF standard either. See e.g.
> I was under the impression that you could now define (at least with
> DWARF3 upwards) your own types or language constructs, without the
> need for having those added to the official DWARF specifications.
>

That all fine and good, but all very long time.
I was more hoping, if there is any chance for a more "short" term 
solution. (and maybe even including a work around in stabs)...

Like it was done for properties that directly map to a field. The now 
are somehow encoded, so the field is read.
BTW anyone, why is that dwarf only => could stabs not just define 
another entry under the property name?


Even then it would be a long way, because it would only be in fpc 2.6.2 
(if merged) or 2.8.0; before a lazarus release would benefit.
On the other hand it would anyway take time for lazarus to be adapted to 
use the info. And currently the info would have to be readable through 
gdb, something I hope to change in future.

More than that, Lazarus is not the only way to use the info, people use 
other IDEs or gdb directly => all that needs to be considered.

Also there are (at least to me) 2 levels.
1) Make available the info that a property exists, even if no way exists 
to access it. (via gdb)
2) access to the data, or information about hpw to access (pointer to 
getter/setter functions) (via gdb)

The first would simply mean that something in the "ptype" result of a 
class indicates the presence of a property

Of course, if the property already maps (aliases) the field (if directly 
mapped to field) then it is impossible for ptype to return a different 
result, than the type of the field.

And returning the content of the field is essential, especially if 
fields themself are structured types (classes).
      FooObject.BarObjFieldProperty.BarValue
only works with the current "alias" solution.
While an IDE could transform the expression, if really that was needed, 
a user using gdb directly would relay on this working (and for an IDE it 
is much easier and leads to better performance, if that is working)

That already defies the idea of encoding properties as structure 
(actually differnet properties = diff structures) with a field for 
getter and setter.
The structure could have been identified as property by a none pascal 
name (like the $fp framepointer in nested functions)

The structure approach would have been nice, as it would have provided 
the info about the property in place of the real property name.
- It would have been fine if  FooObject.BarObjFieldProperty  would 
return and display the whole structure. An IDE can deal with it, and a 
gdb user can still read it (assuming that the structure displays all 
it's values, rather than just an address)
- But it would break FooObject.BarObjFieldProperty.BarValue  . Unless 
the "." after the property can be tought to be an operator that uses the 
"read-value" field (if it is a field)
   (and similar for arras with [])

I am not sure if something like this can be done (and reliable with 
current gdb versions)

---
Another approach, by far not as nice:

- Leave the getter as is / maybe add getters with function to declare 
the property to be the same as the read function.
- And add another field PropertyName$Set with the setter info

Accessing a property in value evaluation would work as it does now.
An IDE getting a "ptype" could detect the xxx$Set entries, match the 
getters, and know what is a property => even have a way of modifying 
them, if it can do code-execution for that purpose...

Alternative xxx$Property with a record (or xxx$Set / xxx$get), to 
provide info about properties; but leave the actual name mapped to the 
field (were appropriate) so the expression evaluation would still work


Martin