[fpc-devel] Archer and Dwarf-3

[Marc Weustink]

I've been quite busy last weeks, so a bit late reply.

Joost van der Sluis wrote:
> Hi all,
> 
> I've switched back to Linux/Fedora 11 to continue testing Dwarf-3 and
> Archer further. (Because that's my natural habitat, Windows just slows
> me down - especially using GIT)
> 
> So I'm on the 'official' fedora-archer-gdb version now, and recent
> fpc-trunk.
> 
> I have a few remarks:
> 
> Case sensitivity
> 
> The name of dynamic arrays are case-sensitive, while the names of
> 'normal' arrays aren't case-sensitive. When you look at the code of
> dbgdwarf this makes sense, since for 'normal' arrays the dwarf-2 code is
> called, while for dwarf-3 some other code is executed. So it could be
> that the dwarf-3 code is case sensitive, but I can't see why. Besides,
> using objdump -w, I see no difference between the defined name of a
> dynamic array and a normal array. So why does gdb handles them
> differently?
 > When dwarf-2 is used, all names are stored in capitals into the
 > debug-information. For dwarf-3 they are stored as how ther are defined
 > in the sources. Is that something new in dwarf-3? That you can supply
 > the casing as it is in the source, but that they still can be handled
 > case-insensitive?

First some background. I introduced the -gw3 (dwarf3) mode of the 
compiler to experiment with my own debugger. The idea was to have a 
clean dwarf3 implementation according to the specs, not hindered by 
limitations in GDB. One of those limitations is/was case sensitivety. In 
dwarf you can specify in what language the code is written and if the 
code is case sensitive. Since I like to view symbols in the same case as 
they are coded, I turned off uppercase names for my dwarf23 extentions. 
(when you use CamelCase variables they become more readable when debugging)
So normal arrays still may use the existing dwarf2 descriptions, while 
dynamic arrays use the "new" dwarf3 descriptions

> Printing arrays
> 
> Printing the contents of an array doesn't work (print arrr). They are
> showed as a pchar, but using 'whatis arr' then the type is correctly
> given. Except that the size of dynamic arrays is bogus. (way too large)
> 
> Using 'print[x]' works fine on arrays of shortint, though. But it fails
> on arrays of ansistrings. It always prints the value of the first
> member. I would say that this is a gdb bug, and not the debug-info. But
> that's just a guess.
> 
> Outside an array, ansistrings work fine!

I see some differences/errors between pchar and ansistring types. It 
seems that the symbols created for them are the same. Depending on the 
gdb function you use, both are reported the same, eihter as ^character 
or as ansistring.
For indexing this is a huge difference, since ansistrings start to count 
at 1 while a ^character starts to count at 0

Marc