Re: gdb-internal: determining the type of a variable

[Jim Blandy <jimb@redhat.com>]

Roul Oldenburger <oldenburger.roul@rheinmetall-de.com> writes:
> In fact the type is duration, but my problem is to distinguish between
> the different possibilities ... so looking for the typenumber alone is
> not enough.
> 
> How does gdb does it??
> 
> What am I doing wrong?

First, have you looked at the stabs document?  The manual source is in
gdb/doc/stabs.texi, and http://sources.redhat.com/gdb/documentation/
has a link to it on-line.

However, I don't think that's the clearest description of what's going
on.  (Hmm, invest 15 minutes explaining it now, which I'll have to
repeat the next time someone asks, or days trying to improve
stabs.texi?  My motto: "Fritter, fritter".)

In general, type numbers are only going to be unique within a
compilation unit; the stabs for a given compilation unit are delimited
by N_SO stabs --- but note that there are also N_SO stabs that just
set the working directory.  See the stabs document for more details.

However, if you see an EXCL stab, then your work is harder.  EXCL
stabs are produced by the linker when it factors out information
repeated in all the .o files it's linking together so it only appears
once in the executable.  An EXCL stab points back to stabs earlier in
the list that also belong in this compilation unit, but have been
omitted to save space.

The EXCL stuff depends on some trickiness with the type numbers.
Originally, stabs type numbers were just that --- numbers --- and they
were assigned sequentially.  So you'd see something like:

        LSYM char:t2=r2;0;127;
...
        PSYM argv:p20=*21=*2

to declare argv's type as 'char **'.  This meant that, if the same
header file were #included into several compilation units, its types
would be assigned whatever numbers came next in the sequence for that
compilation unit.  This makes it hard to recognize whether the stabs
for two #inclusions of a file in different compilation units are
really the same or not.

But now, type numbers are (FILENUM,TYPENUM) pairs:

        LSYM char:t(0,2)=r(0,2);0;127;
...
        PSYM argv:p(10,1)=*(10,2)=*(0,2)

Each time we start a new source file for an #inclusion, we assign it a
new FILENUM, and start TYPENUM at one again.  This means that, if the
same header file gets #included into several different compilation
units, the likelihood is that the type numbers introduced by that
header file will differ only in the file number, not the type
numbers, which makes it easier to determine whether the stabs produced
by two #inclusions of the same file in two different compilation units
are the same or not.

The stabs introduced by a header file are bracketed by a BINCL / EINCL
pair.  If the linker sees a BINCL / EINCL pair where the name of the
#included file is the same as some previous BINCL / EINCL pair, and
the stabs contained therein differ only in their file numbers, then it
replaces the second BINCL / EINCL pair and all the stabs between them
with a single EXCL stab, which points back to the first BINCL / EINCL
pair.

Anyway, if you want to read stabs information in linked programs, not
.o files, you'll need to understand that.  See dbxread.c and
stabsread.c for details.  To say much more, I'd just have to refer to
them, too.