http://bugs.freepascal.org/view.php?id=20225

I did run a test on w32 vista

with gdb 6.7.5 / 7.0 / 7.2.1 / 7.3.1 / 7.3.2 with fpc 2.4.4 / recent fixes 2.6 / recent trunk

stabs
dwarf
dwarf3 (only trunk + gdb 7.3.2)

the result:
- all combinations of gdb and fpc using stabs got the correct result.
- none were able to display it with dwarf.

the conclusion on the bug report appears wrong. it is not a gdb version issue (unless gdb 7.2 / 7.3 on linux has fixes over the window version). It is a stabs/dwarf issue

The DWARF3 implementation can only work in combination with a GDB built from the GDB archer branch currently.

the result: - all combinations of gdb and fpc using stabs got the correct result.

Stabs just encodes a dynamic array as a pointer to an infinite-length array.

- none were able to display it with dwarf.

DWARF2 encodes a dynamic array as an array of unknown size. DWARF3 encodes it as an array where the size information has to be dynamically loaded from memory (which is only supported by the GDB from the Archer branch currently)

the conclusion on the bug report appears wrong. it is not a gdb version issue (unless gdb 7.2 / 7.3 on linux has fixes over the window version). It is a stabs/dwarf issue

The DWARF information is correct. Maybe Anton is using a GDB on a Fedora-based distribution. Fedora's GDB is built from the Archer branch. It's possible that this fixes another bug in GDB that is also triggered by the DWARF2-encoding of dynamic arrays.

Jonas

Jonas wrote

The DWARF information is correct. Maybe Anton is using a GDB on a Fedora-based distribution. Fedora's GDB is built from the Archer branch. It's possible that this fixes another bug in GDB that is also triggered by the DWARF2-encoding of dynamic arrays.

This morning I tried the vanilla GDB 7.2 release, the vanilla GDB 7.3.1 release, and various git branches from the archer branch (http://sourceware.org/gdb/wiki/ProjectArcher), specifically the "archer-jankratochvil-vla" and "archer-tromey-python" branches. I was unable to get the correct behavior using any of those branches. Does anyone have any specific knowledge of where the bug is fixed?

-SG

Maybe in http://download.fedora.redhat.com/pub/fedora/linux/updates/15/SRPMS/gdb-7.3-43.fc15.src.rpm ?

Jonas

That should work. Did you compile using -gw3?

Joost

Joost wrote

That should work. Did you compile using -gw3?

I did, but it behaves even more strangely (I can't seem to print any variables). However I'm not in the trunk, I'm using 2.4.4 (this is a production environment) so maybe there's more recent changes in the dwarf 3 generation I don't have that are affecting it as well.

I'm going to take all of the patches from the fedora src RPM Jonas gave me and work on applying all of them and see if any of it makes a difference. I'm actually leaving on vacation Friday and will be gone for 10 days or so, so I apologize in advance if you don't hear from me report back on my results until after that.

Thanks for your help. Cheers and good health.

-SG

There's another difference between Dwarf-3 and Dwarf-2, and that is that Dwarf-2 stores all variables in uppercase, while Dwarf-3 does not. Not all GDB-versions can really handle case-insensitive searches, so a fallback is added to search uppercase. So it could be that GDB is case-sensitive for those variables.

Also make sure that GDB detects the language right, and is running in pascal-mode.

Joost

Thanks for the tips, I'll give it all a go again once I get back from vacation.

-SG

You're right, there was a case sensitivity issue, but even so I'm having issues. Here's what I get compiling with -gw3 using the patches from the Fedora SRC RPM Jonas linked to:

(gdb) print myRec2^
$1 = {c = 16, recs = <error reading variable>
(gdb) print myRec2^.recs
Cannot resolve DW_OP_push_object_address for a missing object

Here's what I get with vanilla GDB 7.3.1:

(gdb) print myRec2^.recs[i]
$10 = {a = -134291376, b = 32767} (note that in this one the values aren't even right)
(gdb) print myRec2^.recs[i].a
Type Record1Array is not a structure or union type.

I'll try a few more combinations, I've got a couple of hours before I have to leave.

-SG