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]

Unfortunately, once about 2 mails are exchanged on the subject of what I 
actually tried to talk about, the whole discussion takes off and all 
kind of debugger woes are included....

So back again:
I am trying to find out, if the below could make a reasonable feature 
request (and therefore have a chance to be implemented in FPC)
And if it does => should I put in on mantis.

I believe, Joost may actually have started to look at the requirements, 
since he enquired about gdb and method execution?

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.

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.
e.g NONE of those would execute  (property List: TList read GetList)
   Foo.List
   Foo.List.Counter
The following may or may not:
   Foo.List().Counter

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.

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?

Even if gdb does not show it, it would mean that later means of access 
may exists, and the info is there, and an IDE can at least tell "this is 
a property"



from dwarf 3 specs:
> In cases where a producer of debugging information feels that it will 
> be important for consumers of that information to quickly scan chains 
> of sibling entries, while ignoring the children of individual 
> siblings, that producer may attach a DW_AT_sibling attribute to any 
> debugging information entry. The value of this attribute is a 
> reference to the sibling entry of the entry to which the attribute is 
> attached


On 12/09/2011 21:13, Martin wrote:
> 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....
>
>
>
>
>