This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Stab type information in string field
- From: Ian Lance Taylor <ian at airs dot com>
- To: Ludovic Courtès <ludovic dot courtes at laas dot fr>
- Cc: binutils at sources dot redhat dot com
- Date: 21 Mar 2003 15:03:34 -0800
- Subject: Re: Stab type information in string field
- References: <20030321130910.GA9952@laas.fr>
Ludovic Courtès <ludovic dot courtes at laas dot fr> writes:
> The "stabs" node in the GNU Info tree says that the type-information is
> made of a single number (followed by an "=" sign and so on when defining
> a new type). For instance, the string field corresponding to a local
> variable declaration like "int x;" is said to look like "x:1" where 1
> corresponds to type "int".
>
> However, when looking at the stabs of a gcc 2.95.4-compiled excutable
> (with "objdump -G"), it turns out that type information is formatted
> differently. For instance, the following global variable declaration
> "static int i;" results in the following string field :
>
> 450 STSYM 0 28 10012304 40870 i:S(0,1)
>
> Here, the type information is a tuple rather than an integer. The same
> goes for type definitions (the "t" symbol descriptor) and so on.
>
> Could someone please explain me how this works? Did I miss something?
I don't know which version of the document you are reading. The
current document, available at, e.g.,
http://sources.redhat.com/gdb/download/onlinedocs/stabs_1.html#SEC1
says this:
A type-number is often a single number. The GNU and Sun tools
additionally permit a type-number to be a pair
(file-number,filetype-number) (the parentheses appear in the
string, and serve to distinguish the two cases). The file-number
is 0 for the base source file, 1 for the first included file, 2
for the next, and so on. The filetype-number is a number starting
with 1 which is incremented for each new type defined in the
file. (Separating the file number and the type number permits the
N_BINCL optimization to succeed more often; see 2.3 Names of
Include Files).
Ian