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