[fpc-devel] Archer and Dwarf-3

[Joost van der Sluis]

Op zondag 24-05-2009 om 23:29 uur [tijdzone +0200], schreef Marc
Weustink:
> I've been quite busy last weeks, so a bit late reply.

No, problem. It's very welcome. I'm completely new in this subject and
all information is welcome.

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

That sound ok, we can try to convince the gdb people to work according
to the specs also. (I think they will)

>  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

No, that's the strange thing. In the debug-info, both are stored
CamelCase. But GDB only find them case-sensitive when the arrays are not
dynamic.

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

This works ok, because the LOWER_BOUND_LIMIT of the ansistring-type is
defined as '1'. 

I've looked at the gdb-code for the pascal value printer and changed a
few things. (Merely copied code from the fortran-value-printer) Printing
arrays works ok now. (whatis Arr still doesn't work, but ptype Arr does
work, strange enough) I've added (or conserved) the
an-array-of-chars-is-actually-a-string hack, because we still use dyn.
arrays to describe ansistrings. And apart from that, this is good for
backwards-compatibility.

Multiple-dimensional arrays are also working fine now.

Only an array of strings is still not possible. (In fact gdb sees it as
a 2-dimensional array, but that's not the problem)

GDB passes two addresses to the value-printer, the inferior and superior
address. The superior address contains the right value. (This is what
you see when you do 'print @Arr[n]') But the inferior address (which is
the actual used adress to obtain the value) is incorrect. So it's
something deep in gdb's internals. Which implies that it also doesn't
work for Fortran.

Joost