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)
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
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On Mon, Sep 12, 2011 at 11:42 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: DaWorm schrieb: 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. Right, property getters can have side effects, like all procedures. That's why I already suggested an hint on property declarations, telling which data item should be displayed for the property. DoDi Yes. Delphi has/had an option to enable function calls/side effects on property evaluation. Often times the getter is pure (no side-effects, just return a field value), it's just either virtual or an interface property, or fetched from an internal helper. GDB supposedly has support for reverse execution/walking back; I don't even know whether it really works for C, not to mention FPC calling conventions, but if it does it would be a killer ;-) -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 13/09/2011 10:31, Flávio Etrusco wrote: GDB supposedly has support for reverse execution/walking back; I don't even know whether it really works for C, not to mention FPC calling conventions, but if it does it would be a killer ;-) afaik, requires hardware support. most intel cpu don't ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 13 Sep 2011, at 12:22, Martin wrote: On 13/09/2011 10:31, Flávio Etrusco wrote: GDB supposedly has support for reverse execution/walking back; I don't even know whether it really works for C, not to mention FPC calling conventions, but if it does it would be a killer ;-) It's unrelated to the programming language. afaik, requires hardware support. Support has to be implemented in GDB for each architecture before it will work (currently it's implemented for x86 and ARM, afaik), but it does not rely on special hardware support. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 13/09/2011 12:11, Jonas Maebe wrote: afaik, requires hardware support. Support has to be implemented in GDB for each architecture before it will work (currently it's implemented for x86 and ARM, afaik), but it does not rely on special hardware support. http://www.gnu.org/s/gdb/news/reversible.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 13/09/2011 01:43, DaWorm wrote: 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 Yes, yes, but I am a big boy and know what I am doing, so I do NOT want the debugger to limit what I am allowed to do. eg: Delphi allows it without *anybody* complaining!. You are a programmer, you should know what you are doing. If you didn't want the getter method to execute, then you should have debugged the field variable instead. What you are describing is like saying we are not supposed to change values at runtime while debugging either. Redicoulous. In Delphi I often got to a loop, iterated the loop once and spot the problem. I then change the value of a some variable, reset the EIP register until before the loop, and then continue running the loop again. All without restarting my debugging session. This was extremely handy! The code I work with daily are also 10's of levels deep in a class hierarchies. How the hell am I supposed to know all the field variable names! I would much rather let the debugger figure that out. Yes, and maybe for those developers that like to have there hands held while debugging, there should be some option to same don't execute getters. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 13 Sep 2011, at 14:20, Graeme Geldenhuys wrote: What you are describing is like saying we are not supposed to change values at runtime while debugging either. No, he's saying that it should not be easy to do this accidentally. I can imagine that in IDEs that evaluate everything your mouse cursor happens to hoover over, automatic evaluation of getters with side effects can be quite an annoyance. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 13/09/2011 14:33, Jonas Maebe wrote: No, he's saying that it should not be easy to do this accidentally. I can imagine that in IDEs that evaluate everything your mouse cursor happens to hoover over, automatic evaluation of getters with side effects can be quite an annoyance. Again, I have not heard of a single developer complain about this in any of the Delphi groups or forums. So I guess the annoyance level is 1% I guess most getters do just the basic, return some field variable without data-changing effects - unlike the idiotic example of fetching a value from a database in a getter. There are MUCH better designs than that example given. [sorry to be harsh towards DaWorm, but that was a damn stupid example] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 13 Sep 2011, at 14:52, Graeme Geldenhuys wrote: On 13/09/2011 14:33, Jonas Maebe wrote: No, he's saying that it should not be easy to do this accidentally. I can imagine that in IDEs that evaluate everything your mouse cursor happens to hoover over, automatic evaluation of getters with side effects can be quite an annoyance. Again, I have not heard of a single developer complain about this in any of the Delphi groups or forums. So I guess the annoyance level is 1% Maybe that's because the evaluation of properties is disabled by default and you have to explicitly enable it exactly because that can cause side effects. At least that was apparently the case in 2006: http://www.skylark-software.com/2006/01/why-are-some-object-properties-zero-in.html Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
Flávio Etrusco schrieb: Right, property getters can have side effects, like all procedures. That's why I already suggested an hint on property declarations, telling which data item should be displayed for the property. Yes. Delphi has/had an option to enable function calls/side effects on property evaluation. That's nice but not really helpful - depending on how many properties use getters. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
Graeme Geldenhuys schrieb: On 13/09/2011 01:43, DaWorm wrote: 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 Yes, yes, but I am a big boy and know what I am doing, so I do NOT want the debugger to limit what I am allowed to do. The opposite is more true: you want the debugger do for you whatever you ask it for. Question is *who* is asking the debugger to call a subroutine, to e.g. get an property value. A user should not have to dig into the getter code, in order to determine whether it's safe to call that specific getter. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: the debugger to limit what I am allowed to do. eg: Delphi allows it without *anybody* complaining!. You are a programmer, you should know what you are doing. If you didn't want the getter method to execute, then you should have debugged the field variable instead. Yes, and maybe for those developers that like to have there hands held while debugging, there should be some option to same don't execute getters. when you add a watch in Delphi (7) on a property, you have to allow explicitly (checkbox) calling functions. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On Tue, Sep 13, 2011 at 8:52 AM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: [sorry to be harsh towards DaWorm, but that was a damn stupid example] It was only an example intended to show that executing getters can have unintended and sometimes disastrous and/or non reversible side effects. By itself it might be a stupid thing to do, but the concept that merely reading a property may actually change something else is not stupid. Maybe your getter returns the next item in a pseudo random sequence, who know what it does? The example wasn't the point: that such an example is possible was the point. And you might not have built such a thing consciously. Maybe you've descended from a third party library routine that you may or may not have the source code, for and that library does something you might not expect. You may have the memory capacity to know that 15 levels deep there is a property that is implemented by a getter with a side effect, but that in this instance it is ok to run that getter in the debugger, but I don't trust my memory that much. I can easily forget that this property has a getter with a side effect and that one doesn't. That's why I create objects in the first place, to hide all of those implementation details once and for all, and concentrate on actually getting things done. I would not want any debugger to automatically execute such a property getter. I wouldn't mind if it warned me with a dialog box or message that this property has a getter defined by such and such method, and I then had the option to go check it out first, then maybe check a box or change a setting saying this is ok from now on, but I don't want it to just go and do it on its own. As for it not being a problem in Delphi, I don't automatically enable that option. I doubt many others do either, at least not after they've been bitten by it the first time. If I try to evaluate a property and it doesn't it is fairly obvious why, and I go down the inheritence chain until I find the getter and look at what it is using. If it is harmless, then I might check the checkbox that says to execute code to get the value, but it is the last thing I do, not the first. Of course, maybe all of my code is bad like that example and so I don't have any choice, and maybe all of your code is perfect and you never have to worry about it. I'd say neither is totally true. Jeff. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12 Sep 2011, at 14:07, Martin wrote: Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? I really don't like hacks like that. They will have to be maintained almost forever because tools will rely on them, just like the previously mentioned hack for shortstrings (they're also represented using a fake record). While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 18:32, Jonas Maebe wrote: On 12 Sep 2011, at 14:07, Martin wrote: Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? I really don't like hacks like that. They will have to be maintained almost forever because tools will rely on them, just like the previously mentioned hack for shortstrings (they're also represented using a fake record). While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. Using codetools is currently in discussion. There is someone who might contribute towards that. If it is done, it will be used anyway, since it will not have to wait for another fpc release. But I don't think it is the preferable solution, if symbols could somehow be provided by debug info means. (even, i they would require an extra switch at compile time / though from your comment that doesn't change the issue). Adding declared-in-unit info: not sure if it will help much. afaik codetools has no problem finding that. Also it would rely on gdb being able to return this info. And currently all is done through gdb. I do plan in future to read dwarf directly, that will solve other issues. But of course it can again only provide info that is present ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 19:08, Martin wrote: On 12/09/2011 18:32, Jonas Maebe wrote: On 12 Sep 2011, at 14:07, Martin wrote: Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? I really don't like hacks like that. They will have to be maintained almost forever because tools will rely on them, just like the previously mentioned hack for shortstrings (they're also represented using a fake record). While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. A less drastic idea: Currently properties that map to a field are already present in dwarf (again why not in stabs?). 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 19:14, Martin wrote: On 12/09/2011 19:08, Martin wrote: On 12/09/2011 18:32, Jonas Maebe wrote: While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. A less drastic idea: Currently properties that map to a field are already present in dwarf (again why not in stabs?). 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. Maybe they can even in both cases (field or function) be encoded as internal pointer (the same that is used vor var param or objects, if I underatnad them correctly? They do auto deref if used , but in ptype some gdb show them , so they can be detected (and where gdb does not show them special, they will be detectable if debug info is read by the IDE, bypassing gdb (planned for future)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12 Sep 2011, at 20:20, Martin wrote: On 12/09/2011 19:14, Martin wrote: Currently properties that map to a field are already present in dwarf (again why not in stabs?). Because Stabs is legacy and I don't want to spend time on it. 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. Maybe they can even in both cases (field or function) be encoded as internal pointer (the same that is used vor var param or objects, if I underatnad them correctly? They do auto deref if used , but in ptype some gdb show them , so they can be detected (and where gdb does not show them special, they will be detectable if debug info is read by the IDE, bypassing gdb (planned for future)) I don't understand this idea. A var parameter is in fact a pointer at the machine code level. A field or method used to implement a property isn't in any way different from other fields or methods. You probably also should not rely on var-parameters being shown as pointer types in gdb, since that's most likely a gdb implementation detail. Adding declared-in-unit info: not sure if it will help much. afaik codetools has no problem finding that. It cannot know from which unit the type comes. It's even not necessarily a type that is visible in the current unit. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 19:31, 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. That would be good... :) Maybe they can even in both cases (field or function) be encoded as internal pointer (the same that is used vor var param or objects, if I underatnad them correctly? They do auto deref if used , but in ptype some gdb show them , so they can be detected (and where gdb does not show them special, they will be detectable if debug info is read by the IDE, bypassing gdb (planned for future)) I don't understand this idea. A var parameter is in fact a pointer at the machine code level. A field or method used to implement a property isn't in any way different from other fields or methods. You probably also should not rely on var-parameters being shown as pointer types in gdb, since that's most likely a gdb implementation detail. You are right that wasn't thought through. They can't be, there is no pointer-value I was looking if there is by any chance any kind of small flag that could be embedded. yet would not chnage the behaviour for gdb. Double nice if it can be displayed via gdb, but even if not, then in future the IDE could read it. I have not much knowledge of dwarf yet, so all my ideas are more or less random attempt... what is DW_AT_sibling used for? could a property be a sibling of the field? 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 Sounds like it is just like a hint that any compiler (debug-info-producer) can add as it wants? Adding declared-in-unit info: not sure if it will help much. afaik codetools has no problem finding that. It cannot know from which unit the type comes. It's even not necessarily a type that is visible in the current unit. That depends: if we speak of the declared type = then it should be visible? if we speak of the actual instance type = then true. We are not talking about virtual methods. (though we might get there, if we have to resolve a function) We are speaking about properties. IIRC, if a property gets re-declared in child classes, then resolution is by declared type? --- I am sure there is a lot more that could be added. I saw thereeven is a field for with blocks. And there will be a need for variables from parents in case of nested procedures procedure Outer; var i: integer; procedure Middle; procedure Inner; begin writeln(i); // from outer end; var i: integer; // middle // not in scope for inner begin end; begin end; Currently we just search parent frames = but that means to get the i from middle. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote: On 12 Sep 2011, at 20:20, Martin wrote: On 12/09/2011 19:14, Martin wrote: Currently properties that map to a field are already present in dwarf (again why not in stabs?). Because Stabs is legacy and I don't want to spend time on it. 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... Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
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
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
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 laza...@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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
DaWorm schrieb: 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. Right, property getters can have side effects, like all procedures. That's why I already suggested an hint on property declarations, telling which data item should be displayed for the property. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
