cced lazarus

Best to list individual issues.
If told it should work, then the best is to provide little test apps, that demonstrate the issue.

See my notes on hints in the other mail though.

However, I still recommend trunk => a lot of fixes have been applied.

Known issues are :
- properties with getter.
- strings 0 versus 1 based (I do hope to test with dwarf3 soon, but no idea yet, if it will help...)
- dyn array, element access in deeply nested pascal expression (simple cases are normally handled)
- dyn array: not possible to see the entire list.

I didn't check if it works in (plain) gdb 7.3 yet, but it should work.

- 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.

- dyn array: not possible to see the entire list.

Eh? this one is new for me? What do you mean?

Joost

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.

Joost van der Sluis wrote

On Mon, 2011-09-12 at 23:18 +0100, Martin wrote: > - 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.

See attached excel, with
- various fpc,
- stabs or any dwarf
- various gdb

it needs dynarray^[index]

EXCEPT: dwarf3 + gdb7.3.2
- an anonymously declared dyn-array (var VarDynIntArrayA: Array of Integer;)
-data-evaluate-expression VarDynIntArrayA[1]
returns a SINGLE value: ^done,value="22476996"

- a named type dyn array (type TDynIntArray = Array of Integer;) -data-evaluate-expression VarDynIntArray[1]
returns a SINGLE value: ^done,value="9"

both values make no sense at all => they are not in the list

> - dyn array: not possible to see the entire list. Eh? this one is new for me? What do you mean?

see attached, while a normal array return a list of values (except gdb 7.0): ^done,value="{10, 12, 14, 16, 18}"
a dyn array returns a pointer, or empty list: ^done,value="0x775d0" ^done,value="{}"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb_dyn_array_eval.rar
Type: application/octet-stream
Size: 5502 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110914/c8bf58bd/attachment-0001.obj>

Interestingly enough:

while ansistring pose a general problem, using shhotstring, stabs does the job. (fpc trunk / gdb 7.3-2 / win 32)

VarString15 starts with "T15"
-data-evaluate-expression VarString15[2]
STABS: ^done,value="49 '1'"
DWARF: ^done,value="53 '5'"

dwarf3: ^done,value="84 'T'"

evaluating the entire string, dwarf 3 includes the "length byte" as a char, old-dwarf and stabs do exclude it

This inconsistent output from GDB has bitten me before! I struggled for hours debugging my code, just to find out GDB doesn't handle FPC strings correctly. Since then my GDB usage is limited to breakpoints and stepping, and tiOPF's logging is for analysing the "real" data values.

If you can't trust your debugger, who can you trust? ;-)

Regards,
- Graeme -

Well as I said before (and well it your choice I accept it, but), statement like this make it look like:
You seek the few error, in order to abandon everything.

I agree, error like this, make it incredible hard for newcomers. But from all I know, you aren't a newcomer?

By now, you should know the can-do and con-not-do, and you should be able to use accordingly. (e.g. watch the entire string, instead of an index / or add 1 to the index yourself)

Martin wrote

By now, you should know the can-do and con-not-do, and you should be able to use accordingly. (e.g. watch the entire string, instead of an index / or add 1 to the index yourself)

At the time I reported the inconsistency problem, I used Lazarus IDE for debugging. Tooltip debugging, watches etc. It displayed the wrong character. So from a developers point of view, they believe what the IDE shows them as correct and true. This was not the case (back then).

I believe Lazarus IDE has been improved to "interpret" what the developer meant, and based on the string type, convince GDB to return the correct data via some work-arounds. But from a "normal FPC developers" point of view - they want to use Pascal syntax in a watch window, and expect correct results. At the time, this was not the case.

Regards,
- Graeme -

Unfortunately not...

The problem is to distinguish between string and pchar. As pchar must not be "fixed"

Can you stop sending these useless messages? We know that there are three things that are problematic on gdb. Martin listed them earlier. We also know that two of them should be solved in Dwarf-3. So there's one issue left (properties-using-getters) and one fpc-issue, namely the missing debug-info for RTL units.

You do not have to send a few messages each day about this. We already know. Martin just tries to help solving these issues, by giving more information about it. That's useful. Replying to each message that it is a disgrace that it is that bad, is not please keep us informed on your progress with your fpc-debugger. That could be interesting.

Joost.