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

[Martin]

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.