[fpc-devel] New Windows gdb-binary
Martin
lazarus at mfriebe.de
Sun Oct 2 15:29:15 CEST 2011
On 02/10/2011 14:05, Joost van der Sluis wrote:
> On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote:
>> On Sat, 2011-10-01 at 01:05 +0100, Martin wrote:
>>> Ok, seems to have big issues with strings in fields.
>> Ow, man.. That's probably difficult again. While evaluating values, it
>> does not 'recurse' into the structure, but uses all kinds of
>> work-arounds. (For example: an array of strings wasn't working either)
> It was easier then I thought. The recursive calls were ok, but you did a
> 'ptype class.stringprop'. But when evaluating the type, there was
> object-address set (which is logical)
>
> New version:
> http://www.lazarussupport.com/gdb_lazarssupport_20111002.zip
Thanks, I will test.
> There are more things that we need to discuss, though.
>
> For example, when I want to evaluate 'object.stringprop', Lazarus issues
> a '-data-evaluate-expression object.stringprop^', which obviously won't
> work with that '^' in the end.
Afaik it should fallback to omit it.
Anyway, those "gdb workarounds" that Lazarus does, will be updated, as
soon as the major gdb crashes are gone.
IIRC, Lazarus uses the ptype result, to detect if the
variable/expression, is of an "internal pointer" type (object,
dyn-array, string). If so, it will attempt the "^" postfix.
This is important for:
- objects, without the "^" gdb only reports the address, but with it,
all the values of all the fields are listed. (afaik this still aplies
iin dwarf 3)
And (also afaik) this behaviour is important, as it allows for
expressions like "Obj1=Obj2" to work the way it is pascal-expectation.
Such expression are used in breakpoint-conditions.
- dyn array: to be tested under dwarf 3, probably no longer needing the
"^". with dwarf2 dyn array do need the "^"
- strings: little tested, they are treated as dyn array of chars.
Obviously, with dwarf3 strings may be improved, and the IDE will get
better detection.
In dwarf2/stabs they are reported as "^(array of char)" which could also
be dyn-array.
It is possible to get the type-name, but:
- the user may have aliased it: "type MyAnsi = type Ansistring;"
- the user may have a local type "type Ansistring = array of char;"
(0-based)
Still even with what dwarf2 delivers (as far as can be detected through
gdb), it may be possible to improve. I simply hadn't yet spent the time
on it....
(And most likely dwarf2 has enough info, if the IDE reads it directly
from the file, but that's not even started yet / planed though)
> Something similar when a method is called (from within the evaluation
> window). Lazarus does 'ptype object.method()'. That doesn't work (could
> be fixable, though) while calling '-data-evaluate-expression
> object.stringprop()' directly will work.
>
No need to fix in gdb.
That must anyway be fixed in the IDE.
The IDE will need settings to allow/disable function calls (global / per
watch). In order to enforce those, the gdb must scan all expressions for
brackets, and detect if they are type casts, or function calls. And then
do whatever is correct.
As function calls are not officially yet implemented, I simply left the
backdoor open.
More information about the fpc-devel
mailing list