On 13/09/2011 13:12, Joost van der Sluis wrote:
On Mon, 2011-09-12 at 23:18 +0100, Martin wrote:
On 12/09/2011 22:51, Hans-Peter Diettrich wrote:
However, I still recommend trunk => a lot of fixes have been applied.
Known issues are :
- strings 0 versus 1 based (I do hope to test with dwarf3 soon, but no
idea yet, if it will help...)
I didn't check if it works in (plain) gdb 7.3 yet, but it should work.
Yeah I have to catch up with 7.3
- dyn array, element access in deeply nested pascal expression (simple
cases are normally handled)
Same as above: works, but maybe not in gdb 7.3 yet.
with old dwarf, I think one needs to write
SomeDynArray^[1]
where in pascal no "^" would be present. The Lazarus IDE fixes that, but
currently only in simple cases => It requires to read extra info from
gdb, and that is slow.
So in order to fix it in complex expression (and only if needed) I need
better detection, that only does the extra work if really required
I have to double check so, if that is really always true...
I have an app that generates a CSV that I can improt in excel to see a
table of how different gdb with diff fpc and diff symboltypes work.
- dyn array: not possible to see the entire list.
Eh? this one is new for me? What do you mean?
I think (at least in many cases) (not at all tested with dwarf 3)
-data-evaluate-expression SomeDynArray
simply give s the pointer, instead of "(1, 3, 8,2,9)"
for normal arrays, you sometimes get the value list.
Again, i need to catch up on all of that.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
