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
Mon Sep 12 22:13:49 CEST 2011


On 12/09/2011 20:46, Joost van der Sluis wrote:
> On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote:
>> On 12 Sep 2011, at 20:20, Martin wrote:
>>>> Could not properties mapping to a function be implemented the same way =>  normal functions are already listed in "ptype" so
>>>>   public
>>>>   property Counter: Integer read GetCounter
>>>> could appear the same as the function "GetCounter" ?
>>>>
>>>> In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field.
>> That may be possible, yes.
> What is it that we actually need? At the Dwarf-level:
>
> Is the information that a property actually has a getter, and the name
> of that getter enough?
>
> Or do we want that when the value of a property is asked, the getter is
> called automagically? (And that there is some kind of flag that
> indicates that a getter is being used?) I don't think that we can add a
> stack-script in the DW_AT_Location that executes the getter. I've looked
> at DW_OP_call, but that won't help us here.
>
> Or, and maybe this is the best solution: some 'opaque' type that returns
> a reference to something else. Which can be different for reading and
> writing values...
>

There are 2 conflicting desires.

-data-evaluate-expression FooObject.BarObjProp.BarValue
ptype FooObject  / ptype FooObject.BarObjProp

The first only works, ( at current) if it is a field, not a getter 
function. IMHO that is ok.

While alot of people do want code execution for properties, there must 
be a mean of control (in the front end, e.g lazarus). Even if that was 
enabled by default.
That means, I would like that gdb does *not* automatically call the 
function.

So for data evaluation we are fine.
If it is a function, the expression fails, and the IDE needs to look 
into it.

Well having said that. If the function was only called, if brackets are 
supplied, maybe.....
-data-evaluate-expression FooObject.BarObjProp().BarValue

But it is not a must. I am not even sure if desirable.

--------
the 2nd issue is knowledge that
a) a there is something in the object under the name of the property
b) this something happens to be a property

a) is already fulfilled if it is a field-property. Hence I asked, if 
functions could be added the same way.
-data-evaluate-expression FooObject.GetCounter
currently gets no value
-data-evaluate-expression FooObject.Counter
gives an error, "no symbol"

if Counter could be the same as GetCounter (making it effectively a 
function of the object), then at least the symbol was present.
And at the same time, this solves the question of "does it get executed 
or not" => same rules as for "GetCounter"

b) The above of course does make no difference between it being a 
property or just a function.

for normal evaluation, this may most times make no difference. But for 
"debug inspector" type windows (that offer an object inspector like view 
of the object, with values) it may make a diff.
If the users setting is to auo-execute properties, then properties would 
be executed => but functions would not.

So then it would be desirable, if there was any indicator between a 
function (or even field), and a property.
Ideally this difference would be viewable via gdb => but that is not 
even a must. Eventually the IDE will read dwarf directly, at which time 
it could make use of it.

-------------------------
As for the whole "auto execution":

I do not know what the options are => I have not even checked all the 
means of controlling it in gdb....


---------------------------
I know, that given that the IDE anyway hasn't support for it yet, it is 
a very early request.
But support in the IDE is hard to implement, if the feature cannot be 
tested. And also given that it will take time until the feature is 
present in a release, it is neer to early to ask....








More information about the fpc-devel mailing list