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?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
