the feature request, that started the discussion [Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]]

[Joost van der Sluis]

On Wed, 2011-09-14 at 10:29 +0100, Martin wrote:
> So some points, that I would like to know:
> 
> 1) I believe the general idea, of making a
>       property Counter: Integer read GetCounter
> be encoded as a function of the object( in the same way as GetCounter 
> already is) is acceptable?
> - So field properties are returning the field
> - Getter properties are depending on GDBs  ability to execute functions.

Could be done, but it's a hack. Maybe we can add a compiler-switch to
enable this behavior. Problem with this approach is that when you
evaluate the property, the getter will be executed. At least when GDB
supports all this. 

> 2) Execution of that properties. (getter)
> I understand it depends on GDB, and FPC can probably not affect it much.
> 
> As far as the dwarf debug info can have an influence (if at all), it 
> would be nice, if execution was NOT automatic.

This is in contradiction with 1.

> 3) Any "hint" that a symbol is a property, not a field or function 
> (despite it being encoded as field or function?
> I know there is an desire not to have any hacks/workarounds in FPC, and 
> I understand the reasons.

Maybe we can come up with something.

> Yet, I was hoping, IF available, and effort is minimal, is there any 
> chance at all?
> 
> As i said, i don't know if DW_AT_sibling  for example can be used (I 
> included the dwarf spec below). It looks to me like it is a hint that 
> can be used at the desire of the compiler (debug info provider): "IF ... 
> FEELS ..". If using this flag does not conflict, or abuse the dwarf 
> specs, then maybe it could be used?

Problem is that even when we set such information, gdb has to be able to
parse it, and it has to be possible to query this information.

Playing around a bit does brought me something further, though. It seems
that it is already possible to get the value from a getter, with current
gdb and dwarf-2.

See the attached program, compiled with fpc 2.7.1, -gw2:

=================
Reading symbols from /home/CNOC/joost/tmp/GDBPropTest/test...done.
(gdb) b main
Breakpoint 1 at 0x400229: file test.pas, line 24.
(gdb) r
Starting program: /home/CNOC/joost/tmp/GDBPropTest/test 

Breakpoint 1, main () at test.pas:24
24	  AClass := TMyClass.Create;
(gdb) p aclass
$1 = 0x7ffff7ff6040
(gdb) n
25	  aclass.Int := 3;
(gdb) p getInt(0x7ffff7ff6040)
hello
$2 = 0
(gdb) n
26	  writeln(AClass.Int);
(gdb) p getInt(0x7ffff7ff6040)
hello
$3 = 3
(gdb) 
=================

Only this doesn't work with virtual methods. It can also lead to
problems when the calling-convention. And it does not work when there is
more then one class with the same getter-name. The last issue can be
resolved by mangling the name of these getters, by adding a prefix with
the classname.

Using this tricks, we could try to add some hacks. But I think that it's
also possible to do these things properly.

Joost.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pas
Type: text/x-pascal
Size: 374 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110916/245f3ab9/attachment.pas>