It's one of the biggest downsides of using the GDB debugger. Delphi for example has a much much much more powerful debugger.
It is a lot more complex:
- FPC writes DWARF (or the older stabs).
DWARF does not have the concept of a property. At least last time I checked, maybe some newer version has....
So Fpc does not include the info that there is a property (or anything of that name).
The exception is "property Foo : TType read FFoo;" => direct field access. Fpc pretends that "Foo" is a field, not a property.
- Method calls
That is something that we can address (not yet done, but no more big hurdles, other than time)
Assuming we can do method calls, and assuming that we find some way, how FPC can tell the debugger: there is something under the name of that property.....
There is at least one more issue.
We could then call
SomeList.GetCount and SomeList.SetCount(cnt)
But
SomeList.GetString
is still an issue.
Strings and arrays are managed types. If the debugger calls that method the ref count is increased. And never released. Still do-able, it would create a memleak.In extremely rare cases change the flow of the application.
SomeList.SetString(val)
The debugger can not create "val" because it must set a refcount, and there is no info how to do that.
Both can be addressed by some pretty vile hacks.
But keeping in mind, that detecting a "string" is already relying on hacks (because dwarf has no type for that either, it is either pchar, or array of char), basing yet more hacks on it..... crumble.
And then I need to check, if currently there is a way to detect virtual and overriden methods. I do not know, I have not checked if that is part of the debug info....
Having said all that, its still something that is on the list.
Most of it requires changes in fpc (writing some info about the property). So most of it cannot be done with fpc 3.2.