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
lazarus at mfriebe.de
Fri Sep 16 20:25:25 CEST 2011
On 16/09/2011 19:13, Flávio Etrusco wrote:
>>> 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.
>>
> I guess Martin means that dwarf3 data must allow gdb (or any other reader) to
> differentiate whether the property is "implemented" by a getter or a
> field.
>
Actually, the getter/field will be seen by the fact that the preoprty
will appear as field or function.
eg a ptype right now (with dwarf2 or even stabs)
will show
TFoo = class ...
FCounter: integer
function GetCounter
Counter: integer // it looks like just another field
=> there is no indication it is just an alas, caused by a property,
there isnothing that tells it is a property
of course if property maps to getCounter, then currentl iy does not
appear at all.
Step 1)
in order to know it exsts
function Counter
step 2)
now it would be nice if one could know it was a property. if anything
in the dwarf spec, could be set to a value, that can be used to say "hey
a property".
It does not need to be accessible via gdb. It just needs to be ignored
by gdb or other debuggers (so the debug info is still valid). And if the
IDE reads dwarf, then the IDE knows.
And since dwarf3 is far from usabel (because on most paltforms you don't
even get the gdb that does have the extra dwarf3 patches (archer) => I
would like it in dwarf2 too.
If it gets into fpc, within the next 3 or 4 month (I am an optimist),
then it may (maybe) merged, and be released in 2.6.2 in summer 2012. So
if the dwarf reader is also finished in Lazarus by then (or at least to
the point that reads the particular bit) => then we have something we
can release in summer 2012. It will by far not be perfect. It may not
even have the "execute" bit. But it will be a step forward...
Any other approach, or even if we take longer than the 3 to 4 month =>
and it will be 2013 before something gets to a release...
More information about the fpc-devel
mailing list