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

[Roul Oldenburger <oldenburger.roul@rheinmetall-de.com>]

Thanks for your effort giving me your explanation!

Looking at the stabs information from our executables which are linked 
from several o-files I find FILENUM being 0 for all typedescriptions.
Probably I could distinguish between the duplicate descriptions if 
FILNUM would differ. Unfortunately I don't know why it is 0 all the way?

Roul



Jim Blandy wrote:
> 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.

-- 
Mit freundlichen Grüßen

^-----------------------------------------------------------+
| Rheinmetall Defence Electronics GmbH     Brüggeweg 54     |
|                                          Postbox 44 84 44 |
| Roul Oldenburger                         28284 Bremen     |
| SPMU                                     Germany          |
| Software Development                                      |
|                                                           |
|      Phone: +49 421 457 2410                              |
|      Email: oldenburger.roul@rheinmetall-de.com           |
|      Web:   http://www.rheinmetall.com/                   |
|             http://www.rheinmetall-de.com/                |
*-----------------------------------------------------------/