On Tue, 2011-01-11 at 00:23 +0000, Martin wrote: > I did some more test., I will check in later... > > None of the old dwarf or stabs seems to define the <> operator for classes. > p Foo<>Bar > gives unknown symbold Foo<>Bar > So it does take it as one symbol? > > > nil > nil is not defined ever. > but under stabs dwarf2 Foo=0 works > > > Dwarf 3: > While the debugger can not do "@ArgTFoo^" in any stabs/dwarf, with the > older formats it can do "(@ArgTFoo)^" (apparently a question of the > order in which the operators are applied) > Under dwarf 3 this fails. > It outputs a class, so it has correctly gotten the type => but the data > in the class, the values of the members are wrong. So it may have > somewhere messed the address up ? > > > a: PAnsiString = 'abc' > -data-evaluate-expression a^ > empty string, but shopuld be 'abc'
Martin, you go way too fast. ;) The decision to change the Dwarf3-object behavior was taken yesterday, and not even final. So now a patch has to be written and committed. (Well, it is written...) Same for variants and the enumerations. Your input is valuable, though. Maybe better to open bug-reports for the variants and enumerations. So it won't be forgotten. For now I my main point is to get a proper case-sensitivity fix. Without that the rest of dwarf-3 is useless anyway. btw: you can see what is changed for Dwarf-3 yourself very easily. It's all in compiler/dbgdwarf.pp. The Dwarf-3 class overrides some methods. (Indeed also those for variants) Joost. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
