Just thought to catch up.

what is the status on dwarf -3 ?

I just did a test with fpc trunk / gdb 7.3-2 => It appears to work reasonable good (though I can't test all possibilities). A few types get messed up, as the idea tries to work dwarf2 or stabs tricks on the data, but that can probably be fixed.

The 2nd idea is about properties. Afaik in dwarf-3 they may even be encodable => though I have no idea what gdb would do with the info.

Yet even with old dwarf and stabs, if you look at the declaration of a class functions and procedures are encoded (even though gdb isn't necessarily able to call them). So my question here is, if it is (for each or any of the debug types) possible to encode them into the class declaration,even if none functional?

so ptype TFoo would return them in the list of fields and procedures ?

Martin

Martin wrote

Just thought to catch up. what is the status on dwarf -3 ?

Nothing has changed recently.

The 2nd idea is about properties. Afaik in dwarf-3 they may even be encodable => though I have no idea what gdb would do with the info.

Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone submitting a proposal to add them to the DWARF standard either. See e.g. http://dwarfstd.org/ShowIssue.php?issue=090303.1&type=closed3 for an example of how to request an additional feature in the next DWARF standard. New requests can be entered at http://dwarfstd.org/Comment.php

Jonas

Jonas Maebe wrote

Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone submitting a proposal to add them to the DWARF standard either. See e.g.

I was under the impression that you could now define (at least with DWARF3 upwards) your own types or language constructs, without the need for having those added to the official DWARF specifications.

GDB, Duby etc would then simply need to be taught how to interpret those DWARF attributes or tags.

All versions of the DWARF spec have support for vendor-specific extensions. I don't see the advantage of allocating one of those and communicating it to other compiler writers (to avoid them using that same extension for something else) instead of submitting it for inclusion in the official DWARF standard though. Such things should only be used in cases where there is no chance of ever getting it included in the standard.

Jonas

That all fine and good, but all very long time.
I was more hoping, if there is any chance for a more "short" term solution. (and maybe even including a work around in stabs)...

Like it was done for properties that directly map to a field. The now are somehow encoded, so the field is read.
BTW anyone, why is that dwarf only => could stabs not just define another entry under the property name?

Even then it would be a long way, because it would only be in fpc 2.6.2 (if merged) or 2.8.0; before a lazarus release would benefit. On the other hand it would anyway take time for lazarus to be adapted to use the info. And currently the info would have to be readable through gdb, something I hope to change in future.

More than that, Lazarus is not the only way to use the info, people use other IDEs or gdb directly => all that needs to be considered.

Also there are (at least to me) 2 levels.
1) Make available the info that a property exists, even if no way exists to access it. (via gdb)
2) access to the data, or information about hpw to access (pointer to getter/setter functions) (via gdb)

The first would simply mean that something in the "ptype" result of a class indicates the presence of a property

Of course, if the property already maps (aliases) the field (if directly mapped to field) then it is impossible for ptype to return a different result, than the type of the field.

And returning the content of the field is essential, especially if fields themself are structured types (classes).
FooObject.BarObjFieldProperty.BarValue
only works with the current "alias" solution.
While an IDE could transform the expression, if really that was needed, a user using gdb directly would relay on this working (and for an IDE it is much easier and leads to better performance, if that is working)

That already defies the idea of encoding properties as structure (actually differnet properties = diff structures) with a field for getter and setter.
The structure could have been identified as property by a none pascal name (like the $fp framepointer in nested functions)

The structure approach would have been nice, as it would have provided the info about the property in place of the real property name.
- It would have been fine if FooObject.BarObjFieldProperty would return and display the whole structure. An IDE can deal with it, and a gdb user can still read it (assuming that the structure displays all it's values, rather than just an address)
- But it would break FooObject.BarObjFieldProperty.BarValue . Unless the "." after the property can be tought to be an operator that uses the "read-value" field (if it is a field)
(and similar for arras with [])

I am not sure if something like this can be done (and reliable with current gdb versions)

---
Another approach, by far not as nice:

- Leave the getter as is / maybe add getters with function to declare the property to be the same as the read function.
- And add another field PropertyName$Set with the setter info

Accessing a property in value evaluation would work as it does now. An IDE getting a "ptype" could detect the xxx$Set entries, match the getters, and know what is a property => even have a way of modifying them, if it can do code-execution for that purpose...

Alternative xxx$Property with a record (or xxx$Set / xxx$get), to provide info about properties; but leave the actual name mapped to the field (were appropriate) so the expression evaluation would still work

Martin

Jonas Maebe wrote

extensions. I don't see the advantage of allocating one of those and communicating it to other compiler writers (to avoid them using that same extension for something else) instead of submitting it for inclusion in the official DWARF standard though.

I understand that, but waiting for the DWARF specification to accept it, then only get somebody to implement it in GDB, then get somebody to implement it in FPC, then get somebody to add support in Lazarus IDE, MSEide etc could all take a lifetime - I might be retired by then. :-)

PS:
Is there any reason why you or somebody else in the FPC team, that knows DWARF, haven't submitted such a a proposal yet? What's the hold-up?

Like I said before, FPC's really big downside, is that it has VERY BAD debugging support. A compiler and debugger should not be separate entities, but rather developed together. That is why I took it upon myself (even though I knew near zero about the topic when I started) to try and implement a Object Pascal based debugger using FPC. At least then at some point we will have a much faster time-to-market (when the FPC users/developers can actually benefit from new debugger support and features). Currently nobody here or in the Lazarus group (with maybe one or two exceptions) know GDB internals or compile their own GDB versions. So the delay between FPC improving it's DWARF output, GDB supporting that information, and distros updated their GDB versions so developers can benefit from it, is HUGE.

Just the other day I had to use Delphi 7 again to do some maintenance on one of our older products. That's when I again came to the realization what dismal state FPC's debugging support is at - it's like travelling back in time to the early 80's where using writeln() was the normal debugging process. I'll happily pay the $800 licensing fee to Embarcadero if I could get at the same time much better debugging support under Linux.

Regards,
- Graeme -

You don't have to wait until it is published. Both gcc and gdb supported provisional DWARF4 features before the standard was out. Simply asking for comments on the DWARF list and then posting it in their issue tracker is probably already enough.

The point is simply to make sure that there is a fleshed out spec that can be implemented, rather than a hack that will have to be broken again next year because someone forgot about something, and which also will have to be maintained forever for compatibility with existing tools that implemented it (like the hack for shortstring support in Stabs).

Is there any reason why you or somebody else in the FPC team, that knows DWARF, haven't submitted such a a proposal yet? What's the hold-up?

That someone has to spend time on writing a formal specification, and preferably do some tests to flesh out at least some obvious shortcomings. That is quite a bit of work. The reasons I personally have not done that are
a) I have no need whatsoever for debug information for properties b) there are plenty of other things to work on that I consider more interesting (also known as "time")

Jonas

Jonas Maebe wrote

You don't have to wait until it is published. Both gcc and gdb supported provisional DWARF4 features before the standard was out.

And then standing the chance of it being reject - thus doing the implementation in GCC and GDB all for nothing. But maybe that would just be an extreme case.

The point is simply to make sure that there is a fleshed out spec that can be implemented,

So maybe one should start a wiki page regarding this, putting down some ideas that others can review and contribute towards? Building up towards a specification we can later submit to the DWARF guys.

b) there are plenty of other things to work on that I consider more interesting (also known as "time")

Would the incentive of money make it more "interesting"? ;-) See my bounty I just posted to the mailing list.

Regards,
- Graeme -

Graeme Geldenhuys wrote

So maybe one should start a wiki page regarding this, putting down some ideas that others can review and contribute towards? Building up towards a specification we can later submit to the DWARF guys.

That certainly sounds like a good idea.

Would the incentive of money make it more "interesting"? ;-) See my bounty I just posted to the mailing list.

No, I have no interest in writing or maintaining a self-written debugger. Especially because on the platforms I primarily support (Mac OS X, iOS) the debugger interface with the OS is partially private and regularly changes between OS releases. Writing and maintaining a multi- platform debugger is not something you quickly do on the side and then forget about, it's a major project by itself that requires sustained development just like a compiler.

Jonas

Never said that. My statement was about pascal (fpc) only.

people debug fpc compiled code, in various ways. some use plain gdb, others use MSEIDE, some Lazarus, maybe some use other gdb frontends...

Any debug info, encoded into the app must not prevent people from using any of those methods. That does not mean that all of those must understand the added info. By far not, only that all of them must not be stopped from using already present info, just because new info was added.

More than that, Lazarus is not the only way to use the info, people use other IDEs or gdb directly => all that needs to be considered.

You can't have one tool for everybody and everything. A debugger can not (and must not) know about all languages. Language specific support IMO should reside in another layer (IDE, plugin...) between the debugger and the user.

DoDi

IMHO that's a bit exaggerated (the last line)? I do use plenty of watches, and never got any such message. Ok I know I can't see properties, and I do not try to do so. That leaves still plenty of ways to get information.

Mind, I do NOT want to play down say that the lack of property support. Not to break an other war about how serious this is or is not. let everyone decide for themself. But to me a statement like the above, is simple wrong, as I do use Lazarus+gdb, and in 99% of my personal use cases (mostly debugging the IDE itself) it has not caused an issue. (Personally I thing such over exaggerated statements are made in some hope, that making things look worse, would get *others* to fix them => another of my experiences says, that does not work at all)

Anyway, I started the topic exactly because I want the situation to be improved, and to see what can be done.

yes, a none gdb debugger would be nice, infact it is on the list. but it will be a lot of time till then, and even than it will require the debug info.

IMO debugging support was one of the reasons, why Kylix was based on Wine, and the cross-platform versions of Delphi use remote debugging only. For that implementation a tiny (remote) debugger interface is sufficient, and the IDE can implement all the language specific debug support.

I'd be happy if somebody could tell me how to make all those "no such identifier in scope" messages disappear, that currently reduce debugging "support" to breakpoints, call stack and local variables.

DoDi

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?

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

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....

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))

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.

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

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:

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.

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.

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....

When 95% of the identifiers in a subroutine (method) can *not* be inspected, this makes an debugger somewhat useless to me. The hint window on e.g. Self provides some information, but only from the base classes - the remainder is out of view :-(

Mind, I do NOT want to play down say that the lack of property support.

I didn't notice until now that my problems may be related to properties. AFAIR I also couldn't inspect global variables. I'll watch out when debugging the next time.

WRT inspecting properties I'd be happy with the content of the fields, where a property value is stored, e.g. TControl.FBoundsRect for Left or Right. Calling getter methods can be dangerous, I wouldn't expect such support. Again I only realize right now, that such a feature may require an hint in code, which property is stored or derived from which stored field.

DoDi

IMO using gdb is not much more than using an disassembler, WRT inspecting values.

Any debug info, encoded into the app must not prevent people from using any of those methods. That does not mean that all of those must understand the added info. By far not, only that all of them must not be stopped from using already present info, just because new info was added.

I expect that RTTI is used by an FPC debugger, but I don't expect that external debuggers use RTTI, beyond their own (language independent) specs.

DoDi

cced to lazarus list. please switch list.

If that is the case, then your problem lays elsewhere, and maybe it can be remedied by config....
I do not recall having ever had an issue with globals, nor local vars. Maybe you have some units, that are not compiled with debug info, like in packages?

About hints:
- yes they can overflow. A selectable/scrollable hint window is planned
- yes they are badly formatted. But the info is there.

I latest trunks, hint display the data according to the class of the instance, not the declaration

Sender: TObject
if it contains a TForm, you see all the data (except what gets cut off)

UPS:
hints in trunk have a few other bugs => not debug related

- without TurbuPowerIProDSgn (mo html hint) they do close, triggered by their own opening action, if they have large content => this is a hint issue, that happens outside debugging too
- with TurbuPowerIProDSgn they just keep crashing....

So testing the debugger for hints is a bit limited due to other bugs;
sorry about that

make sure you use dwarf

-gw

also make sure under "extra options" you add -godwarfsets otherwise set types may not work .
(ok, the ide should probably make that more automated...)

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.

"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

only thing that then would need codetools involved was to check if the name is a property and not a function/field.

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

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

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

http://www.gnu.org/s/gdb/news/reversible.html

Hans-Peter Diettrich wrote

I expect that RTTI is used by an FPC debugger, but I don't expect that

Not at all! The debugger I am working on ONLY reads the debug information embedded in the executable - in my case DWARF info supplied by FPC.

Regards,
- Graeme -

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 -

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

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 -

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

That's nice but not really helpful - depending on how many properties use getters.

DoDi

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

2011/9/13 Graeme Geldenhuys

Not at all! The debugger I am working on ONLY reads the debug information embedded in the executable - in my case DWARF info supplied by FPC.

Graeme, are you working on Duby or some new debugger? I found your old mails that mentioned a Sybil debugger. Another debugger, maybe fp-debugger, was also mentioned somewhere.

It is not good if there are many competing projects with so little resources.

Regards,
Juha

when you add a watch in Delphi (7) on a property, you have to allow explicitly (checkbox) calling functions.

kind regards,
Dimitri Smits

Graeme Geldenhuys 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.

Juha Manninen wrote

Graeme, are you working on Duby or some new debugger?

I'm working on Duby, but all changes are local to my system. I don't have commit rights to Duby on SourceForge - though I never asked.

I'm also not sure if the original author of duby would accept my changes, as our goals might be slightly different. eg: I don't need Delphi and FPC support (only FPC should do), I don't need STABS and DWARF (only DWARF should do), I prefer compiler mode objfpc (not mode delphi), I changed some UnicodeString and WideString references to String (ansistring), lots of code cleanup, code reformatting and many fixes for 32-bit and 64-bit Linux. I also prefer Git to SubVersion (but this is not critical).

The original Duby author hasn't made any commits in a long time either (I think none in the last year), so not sure if he is still motivated with the project. If he isn't interested, I'll simply fork the project and continue, or take over the maintenance of the original project.

I found your old mails that mentioned a Sybil debugger.

I did look at that, but unfortunately the Sybil debugger (and compiler) is a closed-source. Only the RTL, IDE and documentation was open-sourced. So the Open Sybil and WDSybil projects are pretty screwed as far as I'm concerned.

Another debugger, maybe fp-debugger, was also mentioned somewhere.

Duby is somewhat based on the fpdebug project located in the Lazarus tree - mainly just the command line interface code. fpdebug is a 64-bit windows only debugger (and no idea why it is actually in the Lazarus tree). Duby so far supports Linux, Windows and Mac, and is designed to only use the debug information produced by the compiler.

I'm only working on 32-bit and 64-bit Linux at the moment, but once I have more functionality working on one platform, then I'll start testing on the other platforms too. But I'll obviously try and be platform neutral as far as possible.

I'm learning as I go, because my knowledge of debuggers and DWARF is very limited - but it's quite interesting to get an understanding of what's happens behind the scenes. :)

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:

Could be done, but it's a hack. Maybe we can add a compiler-switch to enable this behavior. Problem with this approach is that when you evaluate the property, the getter will be executed. At least when GDB supports all this.

This is in contradiction with 1.

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.

Maybe we can come up with something.

Problem is that even when we set such information, gdb has to be able to parse it, and it has to be possible to query this information.

Playing around a bit does brought me something further, though. It seems that it is already possible to get the value from a getter, with current gdb and dwarf-2.

See the attached program, compiled with fpc 2.7.1, -gw2:

=================
Reading symbols from /home/CNOC/joost/tmp/GDBPropTest/test...done. (gdb) b main
Breakpoint 1 at 0x400229: file test.pas, line 24.
(gdb) r
Starting program: /home/CNOC/joost/tmp/GDBPropTest/test

Breakpoint 1, main () at test.pas:24
24 AClass := TMyClass.Create;
(gdb) p aclass
$1 = 0x7ffff7ff6040
(gdb) n
25 aclass.Int := 3;
(gdb) p getInt(0x7ffff7ff6040)
hello
$2 = 0
(gdb) n
26 writeln(AClass.Int);
(gdb) p getInt(0x7ffff7ff6040)
hello
$3 = 3
(gdb)
=================

Only this doesn't work with virtual methods. It can also lead to problems when the calling-convention. And it does not work when there is more then one class with the same getter-name. The last issue can be resolved by mangling the name of these getters, by adding a prefix with the classname.

Using this tricks, we could try to add some hacks. But I think that it's also possible to do these things properly.

Joost.

Will all of those execute? Do we know already?

Foo.Counter
Foo.Counter()
Foo.Lines.FCounter
Foo.Lines().FCounter

Or only the ones with () ?

Or will the .Fcounter force the execute as well.

I am open for ideas.

eventually, i want at least a dwarf reader directly in the IDE. ptype from gdb is slow, and inaccurate

Not once the IDE can read dwarf.

gdb would only need the bits for -data-evaluate-expression for that gdb does not necessarily need to know if it is a property or not.

ok, yes, calling it as function, not as method....

unfortunately the unique long names contain "$" signs, so they can not be used?

I guess Martin means that dwarf3 data must allow gdb (or any other reader) to differentiate whether the property is "implemented" by a getter or a field.

-Flávio

Actually, the getter/field will be seen by the fact that the preoprty will appear as field or function.

eg a ptype right now (with dwarf2 or even stabs)

will show
TFoo = class ...
FCounter: integer
function GetCounter
Counter: integer // it looks like just another field

=> there is no indication it is just an alas, caused by a property, there isnothing that tells it is a property

of course if property maps to getCounter, then currentl iy does not 1)
in order to know it exsts
function Counter

step 2)
now it would be nice if one could know it was a property. if anything in the dwarf spec, could be set to a value, that can be used to say "hey a property".
It does not need to be accessible via gdb. It just needs to be ignored by gdb or other debuggers (so the debug info is still valid). And if the IDE reads dwarf, then the IDE knows.

And since dwarf3 is far from usabel (because on most paltforms you don't even get the gdb that does have the extra dwarf3 patches (archer) => I would like it in dwarf2 too.

If it gets into fpc, within the next 3 or 4 month (I am an optimist), then it may (maybe) merged, and be released in 2.6.2 in summer 2012. So if the dwarf reader is also finished in Lazarus by then (or at least to the point that reads the particular bit) => then we have something we can release in summer 2012. It will by far not be perfect. It may not even have the "execute" bit. But it will be a step forward...

Any other approach, or even if we take longer than the 3 to 4 month => and it will be 2013 before something gets to a release...