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
