Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

[DaWorm]

I don't understand why a property with a getter could ever be ran by a
debugger.  If I have a property called NextValue, implanted by a method
called GetNextValue, that increments a field, stores it in a database, and
returns the new value, I absolutely do not want the debugger to execute that
even if I'm dumb enough to try to ask it to view that property.  I would
expect it to give me a rational error message such as "Property NextValue
implemented by method GetNextValue" which would tell me that it understood
what I was asking, and why it couldn't do it.
On Sep 12, 2011 4:14 PM, "Martin" <lazarus at mfriebe.de> 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....
>
>
>
>
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110912/6074fd94/attachment.html>