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)]]]

[Martin]

On 16/09/2011 16:05, Joost van der Sluis wrote:
> 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.
Will all of those execute? Do we know already?

Foo.Counter
Foo.Counter()
Foo.Lines.FCounter
Foo.Lines().FCounter

Or only the ones with () ?

Or will the .Fcounter force the execute as well.


>> 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.
I am open for ideas.

eventually, i want at least a dwarf reader directly in the IDE.
ptype from gdb is slow, and inaccurate

>> 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.
Not once the IDE can read dwarf.

gdb would only need the bits for -data-evaluate-expression
for that gdb does not necessarily need to know if it is a property or not.

>
> 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.
>
ok, yes, calling it as function, not as method....

unfortunately the unique long names contain "$" signs, so they can not 
be used?