Commit | Line | Data |
---|---|---|
e505224d PB |
1 | \input texinfo |
2 | @setfilename stabs.info | |
3 | ||
4 | @ifinfo | |
5 | @format | |
6 | START-INFO-DIR-ENTRY | |
8a6d5d4f | 7 | * Stabs:: The "stabs" debugging information format. |
e505224d PB |
8 | END-INFO-DIR-ENTRY |
9 | @end format | |
10 | @end ifinfo | |
11 | ||
12 | @ifinfo | |
8c59ee11 | 13 | This document describes the stabs debugging symbol tables. |
e505224d | 14 | |
612dbd4c | 15 | Copyright 1992 Free Software Foundation, Inc. |
e505224d PB |
16 | Contributed by Cygnus Support. Written by Julia Menapace. |
17 | ||
18 | Permission is granted to make and distribute verbatim copies of | |
19 | this manual provided the copyright notice and this permission notice | |
20 | are preserved on all copies. | |
21 | ||
22 | @ignore | |
23 | Permission is granted to process this file through Tex and print the | |
24 | results, provided the printed document carries copying permission | |
25 | notice identical to this one except for the removal of this paragraph | |
26 | (this paragraph not being relevant to the printed manual). | |
27 | ||
28 | @end ignore | |
29 | Permission is granted to copy or distribute modified versions of this | |
30 | manual under the terms of the GPL (for which purpose this text may be | |
31 | regarded as a program in the language TeX). | |
32 | @end ifinfo | |
33 | ||
139741da | 34 | @setchapternewpage odd |
e505224d PB |
35 | @settitle STABS |
36 | @titlepage | |
139741da | 37 | @title The ``stabs'' debug format |
e505224d PB |
38 | @author Julia Menapace |
39 | @author Cygnus Support | |
40 | @page | |
41 | @tex | |
42 | \def\$#1${{#1}} % Kluge: collect RCS revision info without $...$ | |
43 | \xdef\manvers{\$Revision$} % For use in headers, footers too | |
44 | {\parskip=0pt | |
45 | \hfill Cygnus Support\par | |
46 | \hfill \manvers\par | |
47 | \hfill \TeX{}info \texinfoversion\par | |
48 | } | |
49 | @end tex | |
50 | ||
51 | @vskip 0pt plus 1filll | |
899bafeb RP |
52 | Copyright @copyright{} 1992 Free Software Foundation, Inc. |
53 | Contributed by Cygnus Support. | |
e505224d PB |
54 | |
55 | Permission is granted to make and distribute verbatim copies of | |
56 | this manual provided the copyright notice and this permission notice | |
57 | are preserved on all copies. | |
58 | ||
59 | @end titlepage | |
60 | ||
899bafeb RP |
61 | @ifinfo |
62 | @node Top | |
63 | @top The "stabs" representation of debugging information | |
e505224d | 64 | |
6ae55c65 | 65 | This document describes the stabs debugging format. |
e505224d PB |
66 | |
67 | @menu | |
139741da RP |
68 | * Overview:: Overview of stabs |
69 | * Program structure:: Encoding of the structure of the program | |
6897f9ec | 70 | * Constants:: Constants |
139741da | 71 | * Example:: A comprehensive example in C |
e505224d | 72 | * Variables:: |
8c59ee11 | 73 | * Types:: Type definitions |
63cef7d7 | 74 | * Symbol Tables:: Symbol information in symbol tables |
8c59ee11 | 75 | * Cplusplus:: |
e505224d PB |
76 | |
77 | Appendixes: | |
139741da RP |
78 | * Example2.c:: Source code for extended example |
79 | * Example2.s:: Assembly code for extended example | |
3d4cf720 JK |
80 | * Stab Types:: Symbol types in a.out files |
81 | * Symbol Descriptors:: Table of Symbol Descriptors | |
82 | * Type Descriptors:: Table of Symbol Descriptors | |
139741da RP |
83 | * Expanded reference:: Reference information by stab type |
84 | * Questions:: Questions and anomolies | |
85 | * xcoff-differences:: Differences between GNU stabs in a.out | |
86 | and GNU stabs in xcoff | |
87 | * Sun-differences:: Differences between GNU stabs and Sun | |
88 | native stabs | |
807e8368 | 89 | * Stabs-in-elf:: Stabs in an ELF file. |
e505224d | 90 | @end menu |
899bafeb | 91 | @end ifinfo |
e505224d PB |
92 | |
93 | ||
899bafeb | 94 | @node Overview |
e505224d PB |
95 | @chapter Overview of stabs |
96 | ||
139741da RP |
97 | @dfn{Stabs} refers to a format for information that describes a program |
98 | to a debugger. This format was apparently invented by | |
99 | @c FIXME! <<name of inventor>> at | |
100 | the University of California at Berkeley, for the @code{pdx} Pascal | |
101 | debugger; the format has spread widely since then. | |
102 | ||
8c59ee11 JK |
103 | This document is one of the few published sources of documentation on |
104 | stabs. It is believed to be completely comprehensive for stabs used by | |
105 | C. The lists of symbol descriptors (@pxref{Symbol Descriptors}) and | |
106 | type descriptors (@pxref{Type Descriptors}) are believed to be completely | |
107 | comprehensive. There are known to be stabs for C++ and COBOL which are | |
108 | poorly documented here. Stabs specific to other languages (e.g. Pascal, | |
109 | Modula-2) are probably not as well documented as they should be. | |
110 | ||
111 | Other sources of information on stabs are @cite{dbx and dbxtool | |
112 | interfaces}, 2nd edition, by Sun, circa 1988, and @cite{AIX Version 3.2 | |
113 | Files Reference}, Fourth Edition, September 1992, "dbx Stabstring | |
114 | Grammar" in the a.out section, page 2-31. This document is believed to | |
115 | incorporate the information from those two sources except where it | |
116 | explictly directs you to them for more information. | |
117 | ||
e505224d PB |
118 | @menu |
119 | * Flow:: Overview of debugging information flow | |
8c59ee11 | 120 | * Stabs Format:: Overview of stab format |
e505224d PB |
121 | * C example:: A simple example in C source |
122 | * Assembly code:: The simple example at the assembly level | |
123 | @end menu | |
124 | ||
899bafeb | 125 | @node Flow |
e505224d PB |
126 | @section Overview of debugging information flow |
127 | ||
139741da RP |
128 | The GNU C compiler compiles C source in a @file{.c} file into assembly |
129 | language in a @file{.s} file, which is translated by the assembler into | |
130 | a @file{.o} file, and then linked with other @file{.o} files and | |
131 | libraries to produce an executable file. | |
e505224d | 132 | |
139741da RP |
133 | With the @samp{-g} option, GCC puts additional debugging information in |
134 | the @file{.s} file, which is slightly transformed by the assembler and | |
e505224d PB |
135 | linker, and carried through into the final executable. This debugging |
136 | information describes features of the source file like line numbers, | |
137 | the types and scopes of variables, and functions, their parameters and | |
138 | their scopes. | |
139 | ||
140 | For some object file formats, the debugging information is | |
139741da | 141 | encapsulated in assembler directives known collectively as `stab' (symbol |
e505224d PB |
142 | table) directives, interspersed with the generated code. Stabs are |
143 | the native format for debugging information in the a.out and xcoff | |
144 | object file formats. The GNU tools can also emit stabs in the coff | |
145 | and ecoff object file formats. | |
146 | ||
139741da RP |
147 | The assembler adds the information from stabs to the symbol information |
148 | it places by default in the symbol table and the string table of the | |
149 | @file{.o} file it is building. The linker consolidates the @file{.o} | |
150 | files into one executable file, with one symbol table and one string | |
151 | table. Debuggers use the symbol and string tables in the executable as | |
152 | a source of debugging information about the program. | |
e505224d | 153 | |
8c59ee11 | 154 | @node Stabs Format |
e505224d PB |
155 | @section Overview of stab format |
156 | ||
157 | There are three overall formats for stab assembler directives | |
139741da RP |
158 | differentiated by the first word of the stab. The name of the directive |
159 | describes what combination of four possible data fields will follow. It | |
160 | is either @code{.stabs} (string), @code{.stabn} (number), or | |
63cef7d7 JK |
161 | @code{.stabd} (dot). IBM's xcoff uses @code{.stabx} (and some other |
162 | directives such as @code{.file} and @code{.bi}) instead of | |
163 | @code{.stabs}, @code{.stabn} or @code{.stabd}. | |
e505224d PB |
164 | |
165 | The overall format of each class of stab is: | |
166 | ||
167 | @example | |
139741da | 168 | .stabs "@var{string}",@var{type},0,@var{desc},@var{value} |
63cef7d7 JK |
169 | .stabx "@var{string}",@var{value},@var{type},@var{sdb-type} |
170 | .stabn @var{type},0,@var{desc},@var{value} | |
171 | .stabd @var{type},0,@var{desc} | |
e505224d PB |
172 | @end example |
173 | ||
63cef7d7 JK |
174 | @c what is the correct term for "current file location"? My AIX |
175 | @c assembler manual calls it "the value of the current location counter". | |
176 | For @code{.stabn} and @code{.stabd}, there is no string (the | |
177 | @code{n_strx} field is zero, @pxref{Symbol Tables}). For @code{.stabd} | |
178 | the value field is implicit and has the value of the current file | |
179 | location. The @var{sdb-type} field to @code{.stabx} is unused for stabs | |
180 | and can always be set to 0. | |
e505224d | 181 | |
6897f9ec JK |
182 | The number in the type field gives some basic information about what |
183 | type of stab this is (or whether it @emph{is} a stab, as opposed to an | |
184 | ordinary symbol). Each possible type number defines a different stab | |
185 | type. The stab type further defines the exact interpretation of, and | |
186 | possible values for, any remaining @code{"@var{string}"}, @var{desc}, or | |
3d4cf720 JK |
187 | @var{value} fields present in the stab. @xref{Stab Types}, for a list |
188 | in numeric order of the possible type field values for stab directives. | |
e505224d | 189 | |
139741da RP |
190 | For @code{.stabs} the @code{"@var{string}"} field holds the meat of the |
191 | debugging information. The generally unstructured nature of this field | |
192 | is what makes stabs extensible. For some stab types the string field | |
193 | contains only a name. For other stab types the contents can be a great | |
194 | deal more complex. | |
e505224d | 195 | |
139741da | 196 | The overall format is of the @code{"@var{string}"} field is: |
e505224d PB |
197 | |
198 | @example | |
46351197 | 199 | "@var{name}:@var{symbol-descriptor} @var{type-information}" |
e505224d PB |
200 | @end example |
201 | ||
139741da | 202 | @var{name} is the name of the symbol represented by the stab. |
6897f9ec | 203 | @var{name} can be omitted, which means the stab represents an unnamed |
8c59ee11 | 204 | object. For example, @samp{:t10=*2} defines type 10 as a pointer to |
6897f9ec JK |
205 | type 2, but does not give the type a name. Omitting the @var{name} |
206 | field is supported by AIX dbx and GDB after about version 4.8, but not | |
46351197 JK |
207 | other debuggers. GCC sometimes uses a single space as the name instead |
208 | of omitting the name altogether; apparently that is supported by most | |
209 | debuggers. | |
e505224d | 210 | |
139741da RP |
211 | The @var{symbol_descriptor} following the @samp{:} is an alphabetic |
212 | character that tells more specifically what kind of symbol the stab | |
213 | represents. If the @var{symbol_descriptor} is omitted, but type | |
214 | information follows, then the stab represents a local variable. For a | |
8c59ee11 | 215 | list of symbol descriptors, see @ref{Symbol Descriptors,,Table C: Symbol |
139741da | 216 | descriptors}. |
e505224d | 217 | |
6897f9ec JK |
218 | The @samp{c} symbol descriptor is an exception in that it is not |
219 | followed by type information. @xref{Constants}. | |
220 | ||
139741da RP |
221 | Type information is either a @var{type_number}, or a |
222 | @samp{@var{type_number}=}. The @var{type_number} alone is a type | |
223 | reference, referring directly to a type that has already been defined. | |
e505224d | 224 | |
139741da RP |
225 | The @samp{@var{type_number}=} is a type definition, where the number |
226 | represents a new type which is about to be defined. The type definition | |
227 | may refer to other types by number, and those type numbers may be | |
228 | followed by @samp{=} and nested definitions. | |
e505224d PB |
229 | |
230 | In a type definition, if the character that follows the equals sign is | |
139741da RP |
231 | non-numeric then it is a @var{type_descriptor}, and tells what kind of |
232 | type is about to be defined. Any other values following the | |
233 | @var{type_descriptor} vary, depending on the @var{type_descriptor}. If | |
234 | a number follows the @samp{=} then the number is a @var{type_reference}. | |
235 | This is described more thoroughly in the section on types. @xref{Type | |
236 | Descriptors,,Table D: Type Descriptors}, for a list of | |
237 | @var{type_descriptor} values. | |
238 | ||
6897f9ec JK |
239 | There is an AIX extension for type attributes. Following the @samp{=} |
240 | is any number of type attributes. Each one starts with @samp{@@} and | |
241 | ends with @samp{;}. Debuggers, including AIX's dbx, skip any type | |
8abe8194 | 242 | attributes they do not recognize. GDB 4.9 does not do this---it will |
8c59ee11 JK |
243 | ignore the entire symbol containing a type attribute. Hopefully this |
244 | will be fixed in the next GDB release. Because of a conflict with C++ | |
245 | (@pxref{Cplusplus}), new attributes should not be defined which begin | |
246 | with a digit, @samp{(}, or @samp{-}; GDB may be unable to distinguish | |
247 | those from the C++ type descriptor @samp{@@}. The attributes are: | |
6897f9ec JK |
248 | |
249 | @table @code | |
250 | @item a@var{boundary} | |
8c59ee11 | 251 | @var{boundary} is an integer specifying the alignment. I assume it |
6897f9ec JK |
252 | applies to all variables of this type. |
253 | ||
254 | @item s@var{size} | |
8c59ee11 | 255 | Size in bits of a variable of this type. |
6897f9ec JK |
256 | |
257 | @item p@var{integer} | |
258 | Pointer class (for checking). Not sure what this means, or how | |
259 | @var{integer} is interpreted. | |
260 | ||
261 | @item P | |
262 | Indicate this is a packed type, meaning that structure fields or array | |
263 | elements are placed more closely in memory, to save memory at the | |
264 | expense of speed. | |
265 | @end table | |
266 | ||
b6963343 JK |
267 | All this can make the @code{"@var{string}"} field quite long. All |
268 | versions of GDB, and some versions of DBX, can handle arbitrarily long | |
269 | strings. But many versions of DBX cretinously limit the strings to | |
270 | about 80 characters, so compilers which must work with such DBX's need | |
271 | to split the @code{.stabs} directive into several @code{.stabs} | |
272 | directives. Each stab duplicates exactly all but the | |
6897f9ec | 273 | @code{"@var{string}"} field. The @code{"@var{string}"} field of |
b6963343 JK |
274 | every stab except the last is marked as continued with a |
275 | double-backslash at the end. Removing the backslashes and concatenating | |
276 | the @code{"@var{string}"} fields of each stab produces the original, | |
277 | long string. | |
e505224d | 278 | |
899bafeb | 279 | @node C example |
e505224d PB |
280 | @section A simple example in C source |
281 | ||
282 | To get the flavor of how stabs describe source information for a C | |
283 | program, let's look at the simple program: | |
284 | ||
285 | @example | |
286 | main() | |
287 | @{ | |
139741da | 288 | printf("Hello world"); |
e505224d PB |
289 | @} |
290 | @end example | |
291 | ||
139741da RP |
292 | When compiled with @samp{-g}, the program above yields the following |
293 | @file{.s} file. Line numbers have been added to make it easier to refer | |
294 | to parts of the @file{.s} file in the description of the stabs that | |
295 | follows. | |
e505224d | 296 | |
899bafeb | 297 | @node Assembly code |
e505224d PB |
298 | @section The simple example at the assembly level |
299 | ||
300 | @example | |
301 | 1 gcc2_compiled.: | |
302 | 2 .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 | |
303 | 3 .stabs "hello.c",100,0,0,Ltext0 | |
304 | 4 .text | |
305 | 5 Ltext0: | |
306 | 6 .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 | |
307 | 7 .stabs "char:t2=r2;0;127;",128,0,0,0 | |
308 | 8 .stabs "long int:t3=r1;-2147483648;2147483647;",128,0,0,0 | |
309 | 9 .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0 | |
310 | 10 .stabs "long unsigned int:t5=r1;0;-1;",128,0,0,0 | |
311 | 11 .stabs "short int:t6=r1;-32768;32767;",128,0,0,0 | |
312 | 12 .stabs "long long int:t7=r1;0;-1;",128,0,0,0 | |
313 | 13 .stabs "short unsigned int:t8=r1;0;65535;",128,0,0,0 | |
314 | 14 .stabs "long long unsigned int:t9=r1;0;-1;",128,0,0,0 | |
315 | 15 .stabs "signed char:t10=r1;-128;127;",128,0,0,0 | |
316 | 16 .stabs "unsigned char:t11=r1;0;255;",128,0,0,0 | |
317 | 17 .stabs "float:t12=r1;4;0;",128,0,0,0 | |
318 | 18 .stabs "double:t13=r1;8;0;",128,0,0,0 | |
319 | 19 .stabs "long double:t14=r1;8;0;",128,0,0,0 | |
320 | 20 .stabs "void:t15=15",128,0,0,0 | |
139741da | 321 | 21 .align 4 |
e505224d | 322 | 22 LC0: |
139741da RP |
323 | 23 .ascii "Hello, world!\12\0" |
324 | 24 .align 4 | |
325 | 25 .global _main | |
326 | 26 .proc 1 | |
e505224d PB |
327 | 27 _main: |
328 | 28 .stabn 68,0,4,LM1 | |
329 | 29 LM1: | |
139741da RP |
330 | 30 !#PROLOGUE# 0 |
331 | 31 save %sp,-136,%sp | |
332 | 32 !#PROLOGUE# 1 | |
333 | 33 call ___main,0 | |
334 | 34 nop | |
e505224d PB |
335 | 35 .stabn 68,0,5,LM2 |
336 | 36 LM2: | |
337 | 37 LBB2: | |
139741da RP |
338 | 38 sethi %hi(LC0),%o1 |
339 | 39 or %o1,%lo(LC0),%o0 | |
340 | 40 call _printf,0 | |
341 | 41 nop | |
e505224d PB |
342 | 42 .stabn 68,0,6,LM3 |
343 | 43 LM3: | |
344 | 44 LBE2: | |
345 | 45 .stabn 68,0,6,LM4 | |
346 | 46 LM4: | |
347 | 47 L1: | |
139741da RP |
348 | 48 ret |
349 | 49 restore | |
e505224d PB |
350 | 50 .stabs "main:F1",36,0,0,_main |
351 | 51 .stabn 192,0,0,LBB2 | |
352 | 52 .stabn 224,0,0,LBE2 | |
353 | @end example | |
354 | ||
139741da | 355 | This simple ``hello world'' example demonstrates several of the stab |
e505224d PB |
356 | types used to describe C language source files. |
357 | ||
899bafeb | 358 | @node Program structure |
139741da | 359 | @chapter Encoding for the structure of the program |
e505224d PB |
360 | |
361 | @menu | |
63cef7d7 JK |
362 | * Source Files:: The path and name of the source file |
363 | * Line Numbers:: | |
e505224d | 364 | * Procedures:: |
8d0dca57 | 365 | * Block Structure:: |
e505224d PB |
366 | @end menu |
367 | ||
63cef7d7 JK |
368 | @node Source Files |
369 | @section The path and name of the source files | |
e505224d | 370 | |
63cef7d7 JK |
371 | Before any other stabs occur, there must be a stab specifying the source |
372 | file. This information is contained in a symbol of stab type | |
373 | @code{N_SO}; the string contains the name of the file. The value of the | |
374 | symbol is the start address of portion of the text section corresponding | |
375 | to that file. | |
e505224d | 376 | |
ded6bcab JK |
377 | With the Sun Solaris2 compiler, the @code{desc} field contains a |
378 | source-language code. | |
379 | ||
63cef7d7 JK |
380 | Some compilers (for example, gcc2 and SunOS4 @file{/bin/cc}) also |
381 | include the directory in which the source was compiled, in a second | |
382 | @code{N_SO} symbol preceding the one containing the file name. This | |
ded6bcab JK |
383 | symbol can be distinguished by the fact that it ends in a slash. Code |
384 | from the cfront C++ compiler can have additional @code{N_SO} symbols for | |
385 | nonexistent source files after the @code{N_SO} for the real source file; | |
386 | these are believed to contain no useful information. | |
e505224d | 387 | |
63cef7d7 JK |
388 | For example: |
389 | ||
390 | @example | |
391 | .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 ; 100 is N_SO | |
392 | .stabs "hello.c",100,0,0,Ltext0 | |
393 | .text | |
394 | Ltext0: | |
395 | @end example | |
396 | ||
397 | Instead of @code{N_SO} symbols, XCOFF uses a @code{.file} assembler | |
398 | directive which assembles to a standard COFF @code{.file} symbol; | |
399 | explaining this in detail is outside the scope of this document. | |
400 | ||
401 | There are several different schemes for dealing with include files: the | |
402 | traditional @code{N_SOL} approach, Sun's @code{N_BINCL} scheme, and the | |
403 | XCOFF @code{C_BINCL} (which despite the similar name has little in | |
404 | common with @code{N_BINCL}). | |
405 | ||
406 | An @code{N_SOL} symbol specifies which include file subsequent symbols | |
407 | refer to. The string field is the name of the file and the value is the | |
408 | text address corresponding to the start of the previous include file and | |
409 | the start of this one. To specify the main source file again, use an | |
410 | @code{N_SOL} symbol with the name of the main source file. | |
411 | ||
412 | A @code{N_BINCL} symbol specifies the start of an include file. In an | |
413 | object file, only the name is significant. The Sun linker puts data | |
414 | into some of the other fields. The end of the include file is marked by | |
ded6bcab JK |
415 | a @code{N_EINCL} symbol (which has no name field). In an ojbect file, |
416 | there is no significant data in the @code{N_EINCL} symbol; the Sun | |
417 | linker puts data into some of the fields. @code{N_BINCL} and | |
418 | @code{N_EINCL} can be nested. If the linker detects that two source | |
419 | files have identical stabs with a @code{N_BINCL} and @code{N_EINCL} pair | |
420 | (as will generally be the case for a header file), then it only puts out | |
421 | the stabs once. Each additional occurance is replaced by an | |
422 | @code{N_EXCL} symbol. I believe the Sun (SunOS4, not sure about | |
423 | Solaris) linker is the only one which supports this feature. | |
63cef7d7 JK |
424 | |
425 | For the start of an include file in XCOFF, use the @file{.bi} assembler | |
426 | directive which generates a @code{C_BINCL} symbol. A @file{.ei} | |
427 | directive, which generates a @code{C_EINCL} symbol, denotes the end of | |
428 | the include file. Both directives are followed by the name of the | |
429 | source file in quotes, which becomes the string for the symbol. The | |
430 | value of each symbol, produced automatically by the assembler and | |
431 | linker, is an offset into the executable which points to the beginning | |
432 | (inclusive, as you'd expect) and end (inclusive, as you would not | |
433 | expect) of the portion of the COFF linetable which corresponds to this | |
434 | include file. @code{C_BINCL} and @code{C_EINCL} do not nest. | |
435 | ||
436 | @node Line Numbers | |
e505224d PB |
437 | @section Line Numbers |
438 | ||
63cef7d7 JK |
439 | A @code{N_SLINE} symbol represents the start of a source line. The |
440 | @var{desc} field contains the line number and the @var{value} field | |
f0f4b04e JK |
441 | contains the code address for the start of that source line. On most |
442 | machines the address is absolute; for Sun's stabs-in-elf, it is relative | |
443 | to the function in which the @code{N_SLINE} symbol occurs. | |
e505224d | 444 | |
63cef7d7 JK |
445 | GNU documents @code{N_DSLINE} and @code{N_BSLINE} symbols for line |
446 | numbers in the data or bss segments, respectively. They are identical | |
447 | to @code{N_SLINE} but are relocated differently by the linker. They | |
448 | were intended to be used to describe the source location of a variable | |
449 | declaration, but I believe that gcc2 actually puts the line number in | |
450 | the desc field of the stab for the variable itself. GDB has been | |
451 | ignoring these symbols (unless they contain a string field) at least | |
452 | since GDB 3.5. | |
e505224d | 453 | |
63cef7d7 JK |
454 | XCOFF uses COFF line numbers instead, which are outside the scope of |
455 | this document, ammeliorated by adequate marking of include files | |
456 | (@pxref{Source Files}). | |
139741da | 457 | |
63cef7d7 JK |
458 | For single source lines that generate discontiguous code, such as flow |
459 | of control statements, there may be more than one line number entry for | |
460 | the same source line. In this case there is a line number entry at the | |
461 | start of each code range, each with the same line number. | |
e505224d | 462 | |
899bafeb | 463 | @node Procedures |
6897f9ec JK |
464 | @section Procedures |
465 | ||
466 | All of the following stabs use the @samp{N_FUN} symbol type. | |
467 | ||
468 | A function is represented by a @samp{F} symbol descriptor for a global | |
469 | (extern) function, and @samp{f} for a static (local) function. The next | |
470 | @samp{N_SLINE} symbol can be used to find the line number of the start | |
471 | of the function. The value field is the address of the start of the | |
472 | function. The type information of the stab represents the return type | |
473 | of the function; thus @samp{foo:f5} means that foo is a function | |
474 | returning type 5. | |
475 | ||
ded6bcab JK |
476 | The type information of the stab is optionally followed by type |
477 | information for each argument, with each argument preceded by @samp{;}. | |
478 | An argument type of 0 means that additional arguments are being passed, | |
479 | whose types and number may vary (@samp{...} in ANSI C). This extension | |
480 | is used by Sun's Solaris compiler. GDB has tolerated it (i.e. at least | |
481 | parsed the syntax, if not necessarily used the information) at least | |
482 | since version 4.8; I don't know whether all versions of dbx will | |
483 | tolerate it. The argument types given here are not merely redundant | |
484 | with the symbols for the arguments themselves (@pxref{Parameters}), they | |
485 | are the types of the arguments as they are passed, before any | |
486 | conversions might take place. For example, if a C function which is | |
487 | declared without a prototype takes a @code{float} argument, the value is | |
488 | passed as a @code{double} but then converted to a @code{float}. | |
489 | Debuggers need to use the types given in the arguments when printing | |
490 | values, but if calling the function they need to use the types given in | |
491 | the symbol defining the function. | |
492 | ||
493 | If the return type and types of arguments of a function which is defined | |
494 | in another source file are specified (i.e. a function prototype in ANSI | |
495 | C), traditionally compilers emit no stab; the only way for the debugger | |
496 | to find the information is if the source file where the function is | |
497 | defined was also compiled with debugging symbols. As an extension the | |
498 | Solaris compiler uses symbol descriptor @samp{P} followed by the return | |
499 | type of the function, followed by the arguments, each preceded by | |
500 | @samp{;}, as in a stab with symbol descriptor @samp{f} or @samp{F}. | |
501 | This use of symbol descriptor @samp{P} can be distinguished from its use | |
502 | for register parameters (@pxref{Parameters}) by the fact that it has | |
503 | symbol type @code{N_FUN}. | |
504 | ||
6897f9ec JK |
505 | The AIX documentation also defines symbol descriptor @samp{J} as an |
506 | internal function. I assume this means a function nested within another | |
507 | function. It also says Symbol descriptor @samp{m} is a module in | |
508 | Modula-2 or extended Pascal. | |
509 | ||
510 | Procedures (functions which do not return values) are represented as | |
511 | functions returning the void type in C. I don't see why this couldn't | |
512 | be used for all languages (inventing a void type for this purpose if | |
513 | necessary), but the AIX documentation defines @samp{I}, @samp{P}, and | |
514 | @samp{Q} for internal, global, and static procedures, respectively. | |
515 | These symbol descriptors are unusual in that they are not followed by | |
516 | type information. | |
517 | ||
8c59ee11 JK |
518 | For any of the above symbol descriptors, after the symbol descriptor and |
519 | the type information, there is optionally a comma, followed by the name | |
520 | of the procedure, followed by a comma, followed by a name specifying the | |
521 | scope. The first name is local to the scope specified. I assume then | |
522 | that the name of the symbol (before the @samp{:}), if specified, is some | |
523 | sort of global name. I assume the name specifying the scope is the name | |
524 | of a function specifying that scope. This feature is an AIX extension, | |
525 | and this information is based on the manual; I haven't actually tried | |
526 | it. | |
6897f9ec JK |
527 | |
528 | The stab representing a procedure is located immediately following the | |
529 | code of the procedure. This stab is in turn directly followed by a | |
530 | group of other stabs describing elements of the procedure. These other | |
531 | stabs describe the procedure's parameters, its block local variables and | |
532 | its block structure. | |
e505224d PB |
533 | |
534 | @example | |
139741da RP |
535 | 48 ret |
536 | 49 restore | |
e505224d PB |
537 | @end example |
538 | ||
139741da RP |
539 | The @code{.stabs} entry after this code fragment shows the @var{name} of |
540 | the procedure (@code{main}); the type descriptor @var{desc} (@code{F}, | |
541 | for a global procedure); a reference to the predefined type @code{int} | |
542 | for the return type; and the starting @var{address} of the procedure. | |
543 | ||
544 | Here is an exploded summary (with whitespace introduced for clarity), | |
545 | followed by line 50 of our sample assembly output, which has this form: | |
546 | ||
e505224d | 547 | @example |
139741da RP |
548 | .stabs "@var{name}: |
549 | @var{desc} @r{(global proc @samp{F})} | |
550 | @var{return_type_ref} @r{(int)} | |
551 | ",N_FUN, NIL, NIL, | |
552 | @var{address} | |
e505224d PB |
553 | @end example |
554 | ||
555 | @example | |
556 | 50 .stabs "main:F1",36,0,0,_main | |
557 | @end example | |
558 | ||
899bafeb | 559 | @node Block Structure |
e505224d PB |
560 | @section Block Structure |
561 | ||
139741da | 562 | The program's block structure is represented by the @code{N_LBRAC} (left |
f0f4b04e JK |
563 | brace) and the @code{N_RBRAC} (right brace) stab types. The variables |
564 | defined inside a block preceded the @code{N_LBRAC} symbol for most | |
565 | compilers, including GCC. Other compilers, such as the Convex, Acorn | |
566 | RISC machine, and Sun acc compilers, put the variables after the | |
567 | @code{N_LBRAC} symbol. The values of the @code{N_LBRAC} and | |
568 | @code{N_RBRAC} symbols are the start and end addresses of the code of | |
569 | the block, respectively. For most machines, they are relative to the | |
570 | starting address of this source file. For the Gould NP1, they are | |
571 | absolute. For Sun's stabs-in-elf, they are relative to the function in | |
572 | which they occur. | |
e505224d | 573 | |
139741da | 574 | The @code{N_LBRAC} and @code{N_RBRAC} stabs that describe the block |
f0f4b04e JK |
575 | scope of a procedure are located after the @code{N_FUN} stab that |
576 | represents the procedure itself. | |
e505224d | 577 | |
f0f4b04e JK |
578 | Sun documents the @code{desc} field of @code{N_LBRAC} and |
579 | @code{N_RBRAC} symbols as containing the nesting level of the block. | |
580 | However, dbx seems not to care, and GCC just always set @code{desc} to | |
581 | zero. | |
e505224d | 582 | |
6897f9ec JK |
583 | @node Constants |
584 | @chapter Constants | |
585 | ||
586 | The @samp{c} symbol descriptor indicates that this stab represents a | |
587 | constant. This symbol descriptor is an exception to the general rule | |
588 | that symbol descriptors are followed by type information. Instead, it | |
589 | is followed by @samp{=} and one of the following: | |
590 | ||
591 | @table @code | |
b273dc0f | 592 | @item b @var{value} |
6897f9ec JK |
593 | Boolean constant. @var{value} is a numeric value; I assume it is 0 for |
594 | false or 1 for true. | |
595 | ||
b273dc0f | 596 | @item c @var{value} |
6897f9ec JK |
597 | Character constant. @var{value} is the numeric value of the constant. |
598 | ||
b273dc0f JK |
599 | @item e @var{type-information} , @var{value} |
600 | Constant whose value can be represented as integral. | |
601 | @var{type-information} is the type of the constant, as it would appear | |
602 | after a symbol descriptor (@pxref{Stabs Format}). @var{value} is the | |
603 | numeric value of the constant. GDB 4.9 does not actually get the right | |
604 | value if @var{value} does not fit in a host @code{int}, but it does not | |
605 | do anything violent, and future debuggers could be extended to accept | |
606 | integers of any size (whether unsigned or not). This constant type is | |
607 | usually documented as being only for enumeration constants, but GDB has | |
608 | never imposed that restriction; I don't know about other debuggers. | |
609 | ||
610 | @item i @var{value} | |
611 | Integer constant. @var{value} is the numeric value. The type is some | |
612 | sort of generic integer type (for GDB, a host @code{int}); to specify | |
613 | the type explicitly, use @samp{e} instead. | |
614 | ||
615 | @item r @var{value} | |
6897f9ec JK |
616 | Real constant. @var{value} is the real value, which can be @samp{INF} |
617 | (optionally preceded by a sign) for infinity, @samp{QNAN} for a quiet | |
618 | NaN (not-a-number), or @samp{SNAN} for a signalling NaN. If it is a | |
619 | normal number the format is that accepted by the C library function | |
620 | @code{atof}. | |
621 | ||
b273dc0f | 622 | @item s @var{string} |
6897f9ec JK |
623 | String constant. @var{string} is a string enclosed in either @samp{'} |
624 | (in which case @samp{'} characters within the string are represented as | |
625 | @samp{\'} or @samp{"} (in which case @samp{"} characters within the | |
626 | string are represented as @samp{\"}). | |
627 | ||
b273dc0f | 628 | @item S @var{type-information} , @var{elements} , @var{bits} , @var{pattern} |
6897f9ec | 629 | Set constant. @var{type-information} is the type of the constant, as it |
8c59ee11 | 630 | would appear after a symbol descriptor (@pxref{Stabs Format}). |
a03f27c3 JK |
631 | @var{elements} is the number of elements in the set (Does this means |
632 | how many bits of @var{pattern} are actually used, which would be | |
633 | redundant with the type, or perhaps the number of bits set in | |
634 | @var{pattern}? I don't get it), @var{bits} is the number of bits in the | |
635 | constant (meaning it specifies the length of @var{pattern}, I think), | |
636 | and @var{pattern} is a hexadecimal representation of the set. AIX | |
637 | documentation refers to a limit of 32 bytes, but I see no reason why | |
638 | this limit should exist. This form could probably be used for arbitrary | |
639 | constants, not just sets; the only catch is that @var{pattern} should be | |
640 | understood to be target, not host, byte order and format. | |
6897f9ec JK |
641 | @end table |
642 | ||
643 | The boolean, character, string, and set constants are not supported by | |
644 | GDB 4.9, but it will ignore them. GDB 4.8 and earlier gave an error | |
645 | message and refused to read symbols from the file containing the | |
646 | constants. | |
647 | ||
648 | This information is followed by @samp{;}. | |
649 | ||
899bafeb | 650 | @node Example |
e505224d PB |
651 | @chapter A Comprehensive Example in C |
652 | ||
139741da | 653 | Now we'll examine a second program, @code{example2}, which builds on the |
e505224d PB |
654 | first example to introduce the rest of the stab types, symbol |
655 | descriptors, and type descriptors used in C. | |
139741da RP |
656 | @xref{Example2.c} for the complete @file{.c} source, |
657 | and @pxref{Example2.s} for the @file{.s} assembly code. | |
e505224d PB |
658 | This description includes parts of those files. |
659 | ||
660 | @section Flow of control and nested scopes | |
661 | ||
9cd64d11 | 662 | @table @strong |
139741da RP |
663 | @item Directive: |
664 | @code{.stabn} | |
665 | @item Types: | |
666 | @code{N_SLINE}, @code{N_LBRAC}, @code{N_RBRAC} (cont.) | |
667 | @end table | |
e505224d | 668 | |
899bafeb RP |
669 | Consider the body of @code{main}, from @file{example2.c}. It shows more |
670 | about how @code{N_SLINE}, @code{N_RBRAC}, and @code{N_LBRAC} stabs are used. | |
e505224d PB |
671 | |
672 | @example | |
673 | 20 @{ | |
674 | 21 static float s_flap; | |
139741da RP |
675 | 22 int times; |
676 | 23 for (times=0; times < s_g_repeat; times++)@{ | |
677 | 24 int inner; | |
678 | 25 printf ("Hello world\n"); | |
679 | 26 @} | |
e505224d PB |
680 | 27 @}; |
681 | @end example | |
682 | ||
899bafeb | 683 | Here we have a single source line, the @samp{for} line, that generates |
e505224d | 684 | non-linear flow of control, and non-contiguous code. In this case, an |
899bafeb | 685 | @code{N_SLINE} stab with the same line number proceeds each block of |
e505224d PB |
686 | non-contiguous code generated from the same source line. |
687 | ||
139741da RP |
688 | The example also shows nested scopes. The @code{N_LBRAC} and |
689 | @code{N_LBRAC} stabs that describe block structure are nested in the | |
690 | same order as the corresponding code blocks, those of the for loop | |
691 | inside those for the body of main. | |
e505224d | 692 | |
139741da RP |
693 | @noindent |
694 | This is the label for the @code{N_LBRAC} (left brace) stab marking the | |
695 | start of @code{main}. | |
e505224d | 696 | |
139741da | 697 | @example |
e505224d | 698 | 57 LBB2: |
139741da RP |
699 | @end example |
700 | ||
701 | @noindent | |
702 | In the first code range for C source line 23, the @code{for} loop | |
703 | initialize and test, @code{N_SLINE} (68) records the line number: | |
e505224d | 704 | |
139741da RP |
705 | @example |
706 | .stabn N_SLINE, NIL, | |
707 | @var{line}, | |
708 | @var{address} | |
e505224d | 709 | |
e505224d PB |
710 | 58 .stabn 68,0,23,LM2 |
711 | 59 LM2: | |
139741da | 712 | 60 st %g0,[%fp-20] |
e505224d | 713 | 61 L2: |
139741da RP |
714 | 62 sethi %hi(_s_g_repeat),%o0 |
715 | 63 ld [%fp-20],%o1 | |
716 | 64 ld [%o0+%lo(_s_g_repeat)],%o0 | |
717 | 65 cmp %o1,%o0 | |
718 | 66 bge L3 | |
719 | 67 nop | |
e505224d | 720 | |
139741da | 721 | @exdent label for the @code{N_LBRAC} (start block) marking the start of @code{for} loop |
e505224d | 722 | |
e505224d PB |
723 | 68 LBB3: |
724 | 69 .stabn 68,0,25,LM3 | |
725 | 70 LM3: | |
139741da RP |
726 | 71 sethi %hi(LC0),%o1 |
727 | 72 or %o1,%lo(LC0),%o0 | |
728 | 73 call _printf,0 | |
729 | 74 nop | |
e505224d PB |
730 | 75 .stabn 68,0,26,LM4 |
731 | 76 LM4: | |
e505224d | 732 | |
139741da | 733 | @exdent label for the @code{N_RBRAC} (end block) stab marking the end of the @code{for} loop |
e505224d | 734 | |
e505224d | 735 | 77 LBE3: |
139741da | 736 | @end example |
e505224d | 737 | |
139741da RP |
738 | @noindent |
739 | Now we come to the second code range for source line 23, the @code{for} | |
740 | loop increment and return. Once again, @code{N_SLINE} (68) records the | |
741 | source line number: | |
612dbd4c | 742 | |
139741da RP |
743 | @example |
744 | .stabn, N_SLINE, NIL, | |
745 | @var{line}, | |
746 | @var{address} | |
e505224d | 747 | |
e505224d PB |
748 | 78 .stabn 68,0,23,LM5 |
749 | 79 LM5: | |
750 | 80 L4: | |
139741da RP |
751 | 81 ld [%fp-20],%o0 |
752 | 82 add %o0,1,%o1 | |
753 | 83 st %o1,[%fp-20] | |
754 | 84 b,a L2 | |
e505224d PB |
755 | 85 L3: |
756 | 86 .stabn 68,0,27,LM6 | |
757 | 87 LM6: | |
e505224d | 758 | |
139741da | 759 | @exdent label for the @code{N_RBRAC} (end block) stab marking the end of the @code{for} loop |
e505224d | 760 | |
e505224d PB |
761 | 88 LBE2: |
762 | 89 .stabn 68,0,27,LM7 | |
763 | 90 LM7: | |
764 | 91 L1: | |
139741da RP |
765 | 92 ret |
766 | 93 restore | |
e505224d PB |
767 | 94 .stabs "main:F1",36,0,0,_main |
768 | 95 .stabs "argc:p1",160,0,0,68 | |
769 | 96 .stabs "argv:p20=*21=*2",160,0,0,72 | |
770 | 97 .stabs "s_flap:V12",40,0,0,_s_flap.0 | |
771 | 98 .stabs "times:1",128,0,0,-20 | |
139741da RP |
772 | @end example |
773 | ||
774 | @noindent | |
775 | Here is an illustration of stabs describing nested scopes. The scope | |
776 | nesting is reflected in the nested bracketing stabs (@code{N_LBRAC}, | |
777 | 192, appears here). | |
e505224d | 778 | |
139741da RP |
779 | @example |
780 | .stabn N_LBRAC,NIL,NIL, | |
781 | @var{block-start-address} | |
e505224d PB |
782 | |
783 | 99 .stabn 192,0,0,LBB2 ## begin proc label | |
784 | 100 .stabs "inner:1",128,0,0,-24 | |
785 | 101 .stabn 192,0,0,LBB3 ## begin for label | |
139741da | 786 | @end example |
e505224d | 787 | |
139741da RP |
788 | @noindent |
789 | @code{N_RBRAC} (224), ``right brace'' ends a lexical block (scope). | |
790 | ||
791 | @example | |
792 | .stabn N_RBRAC,NIL,NIL, | |
793 | @var{block-end-address} | |
e505224d PB |
794 | |
795 | 102 .stabn 224,0,0,LBE3 ## end for label | |
796 | 103 .stabn 224,0,0,LBE2 ## end proc label | |
797 | @end example | |
798 | ||
899bafeb | 799 | @node Variables |
e505224d PB |
800 | @chapter Variables |
801 | ||
802 | @menu | |
807e8368 JK |
803 | * Automatic variables:: Variables allocated on the stack. |
804 | * Global Variables:: Variables used by more than one source file. | |
805 | * Common Blocks:: Variables statically allocated together. | |
806 | * Register variables:: Variables in registers. | |
807 | * Initialized statics:: Static variables with values. | |
808 | * Un-initialized statics:: Static variables initialialized to 0. | |
809 | * Parameters:: Passing variables to functions. | |
e505224d PB |
810 | @end menu |
811 | ||
899bafeb | 812 | @node Automatic variables |
e505224d PB |
813 | @section Locally scoped automatic variables |
814 | ||
139741da RP |
815 | @table @strong |
816 | @item Directive: | |
817 | @code{.stabs} | |
818 | @item Type: | |
819 | @code{N_LSYM} | |
820 | @item Symbol Descriptor: | |
821 | none | |
822 | @end table | |
e505224d | 823 | |
139741da RP |
824 | In addition to describing types, the @code{N_LSYM} stab type also |
825 | describes locally scoped automatic variables. Refer again to the body | |
826 | of @code{main} in @file{example2.c}. It allocates two automatic | |
827 | variables: @samp{times} is scoped to the body of @code{main}, and | |
828 | @samp{inner} is scoped to the body of the @code{for} loop. | |
829 | @samp{s_flap} is locally scoped but not automatic, and will be discussed | |
830 | later. | |
e505224d PB |
831 | |
832 | @example | |
833 | 20 @{ | |
834 | 21 static float s_flap; | |
139741da RP |
835 | 22 int times; |
836 | 23 for (times=0; times < s_g_repeat; times++)@{ | |
837 | 24 int inner; | |
838 | 25 printf ("Hello world\n"); | |
839 | 26 @} | |
e505224d PB |
840 | 27 @}; |
841 | @end example | |
842 | ||
139741da RP |
843 | The @code{N_LSYM} stab for an automatic variable is located just before the |
844 | @code{N_LBRAC} stab describing the open brace of the block to which it is | |
e505224d PB |
845 | scoped. |
846 | ||
847 | @example | |
139741da RP |
848 | @exdent @code{N_LSYM} (128): automatic variable, scoped locally to @code{main} |
849 | ||
850 | .stabs "@var{name}: | |
8c59ee11 | 851 | @var{type information}", |
139741da RP |
852 | N_LSYM, NIL, NIL, |
853 | @var{frame-pointer-offset} | |
e505224d PB |
854 | |
855 | 98 .stabs "times:1",128,0,0,-20 | |
856 | 99 .stabn 192,0,0,LBB2 ## begin `main' N_LBRAC | |
857 | ||
139741da RP |
858 | @exdent @code{N_LSYM} (128): automatic variable, scoped locally to the @code{for} loop |
859 | ||
860 | .stabs "@var{name}: | |
8c59ee11 | 861 | @var{type information}", |
139741da RP |
862 | N_LSYM, NIL, NIL, |
863 | @var{frame-pointer-offset} | |
e505224d PB |
864 | |
865 | 100 .stabs "inner:1",128,0,0,-24 | |
866 | 101 .stabn 192,0,0,LBB3 ## begin `for' loop N_LBRAC | |
867 | @end example | |
868 | ||
8c59ee11 JK |
869 | The symbol descriptor is omitted for automatic variables. Since type |
870 | information should being with a digit, @samp{-}, or @samp{(}, only | |
871 | digits, @samp{-}, and @samp{(} are precluded from being used for symbol | |
872 | descriptors by this fact. However, the Acorn RISC machine (ARM) is said | |
873 | to get this wrong: it puts out a mere type definition here, without the | |
874 | preceding @code{@var{typenumber}=}. This is a bad idea; there is no | |
875 | guarantee that type descriptors are distinct from symbol descriptors. | |
e505224d | 876 | |
899bafeb | 877 | @node Global Variables |
e505224d PB |
878 | @section Global Variables |
879 | ||
139741da RP |
880 | @table @strong |
881 | @item Directive: | |
882 | @code{.stabs} | |
883 | @item Type: | |
884 | @code{N_GSYM} | |
885 | @item Symbol Descriptor: | |
886 | @code{G} | |
887 | @end table | |
e505224d | 888 | |
139741da RP |
889 | Global variables are represented by the @code{N_GSYM} stab type. The symbol |
890 | descriptor, following the colon in the string field, is @samp{G}. Following | |
891 | the @samp{G} is a type reference or type definition. In this example it is a | |
892 | type reference to the basic C type, @code{char}. The first source line in | |
893 | @file{example2.c}, | |
e505224d PB |
894 | |
895 | @example | |
896 | 1 char g_foo = 'c'; | |
897 | @end example | |
898 | ||
139741da RP |
899 | @noindent |
900 | yields the following stab. The stab immediately precedes the code that | |
e505224d PB |
901 | allocates storage for the variable it describes. |
902 | ||
903 | @example | |
139741da RP |
904 | @exdent @code{N_GSYM} (32): global symbol |
905 | ||
906 | .stabs "@var{name}: | |
907 | @var{descriptor} | |
908 | @var{type-ref}", | |
909 | N_GSYM, NIL, NIL, NIL | |
e505224d | 910 | |
e505224d | 911 | 21 .stabs "g_foo:G2",32,0,0,0 |
139741da RP |
912 | 22 .global _g_foo |
913 | 23 .data | |
e505224d | 914 | 24 _g_foo: |
139741da | 915 | 25 .byte 99 |
e505224d PB |
916 | @end example |
917 | ||
139741da RP |
918 | The address of the variable represented by the @code{N_GSYM} is not contained |
919 | in the @code{N_GSYM} stab. The debugger gets this information from the | |
e505224d PB |
920 | external symbol for the global variable. |
921 | ||
899bafeb | 922 | @node Register variables |
6897f9ec | 923 | @section Register variables |
139741da | 924 | |
8c59ee11 JK |
925 | @c According to an old version of this manual, AIX uses C_RPSYM instead |
926 | @c of C_RSYM. I am skeptical; this should be verified. | |
6897f9ec JK |
927 | Register variables have their own stab type, @code{N_RSYM}, and their |
928 | own symbol descriptor, @code{r}. The stab's value field contains the | |
929 | number of the register where the variable data will be stored. | |
e505224d | 930 | |
6897f9ec | 931 | The value is the register number. |
e505224d | 932 | |
6897f9ec | 933 | AIX defines a separate symbol descriptor @samp{d} for floating point |
807e8368 JK |
934 | registers. This seems unnecessary---why not just just give floating |
935 | point registers different register numbers? I have not verified whether | |
936 | the compiler actually uses @samp{d}. | |
e505224d | 937 | |
6897f9ec JK |
938 | If the register is explicitly allocated to a global variable, but not |
939 | initialized, as in | |
e505224d PB |
940 | |
941 | @example | |
6897f9ec | 942 | register int g_bar asm ("%g5"); |
e505224d PB |
943 | @end example |
944 | ||
6897f9ec JK |
945 | the stab may be emitted at the end of the object file, with |
946 | the other bss symbols. | |
e505224d | 947 | |
807e8368 JK |
948 | @node Common Blocks |
949 | @section Common Blocks | |
950 | ||
951 | A common block is a statically allocated section of memory which can be | |
952 | referred to by several source files. It may contain several variables. | |
953 | I believe @sc{fortran} is the only language with this feature. A | |
954 | @code{N_BCOMM} stab begins a common block and an @code{N_ECOMM} stab | |
955 | ends it. The only thing which is significant about these two stabs is | |
956 | their name, which can be used to look up a normal (non-debugging) symbol | |
957 | which gives the address of the common block. Each variable in the | |
958 | common block has a @code{N_ECOML} stab, whose value is the offset within | |
959 | the common block of that variable. I'm not sure what symbol descriptor | |
960 | is used for the @code{N_ECOML} stabs. | |
961 | ||
899bafeb | 962 | @node Initialized statics |
e505224d PB |
963 | @section Initialized static variables |
964 | ||
139741da RP |
965 | @table @strong |
966 | @item Directive: | |
967 | @code{.stabs} | |
968 | @item Type: | |
969 | @code{N_STSYM} | |
970 | @item Symbol Descriptors: | |
971 | @code{S} (file scope), @code{V} (procedure scope) | |
972 | @end table | |
e505224d | 973 | |
139741da RP |
974 | Initialized static variables are represented by the @code{N_STSYM} stab |
975 | type. The symbol descriptor part of the string field shows if the | |
976 | variable is file scope static (@samp{S}) or procedure scope static | |
977 | (@samp{V}). The source line | |
e505224d PB |
978 | |
979 | @example | |
980 | 3 static int s_g_repeat = 2; | |
981 | @end example | |
982 | ||
139741da RP |
983 | @noindent |
984 | yields the following code. The stab is located immediately preceding | |
e505224d | 985 | the storage for the variable it represents. Since the variable in |
139741da | 986 | this example is file scope static the symbol descriptor is @samp{S}. |
e505224d PB |
987 | |
988 | @example | |
139741da RP |
989 | @exdent @code{N_STSYM} (38): initialized static variable (data seg w/internal linkage) |
990 | ||
991 | .stabs "@var{name}: | |
992 | @var{descriptor} | |
993 | @var{type-ref}", | |
994 | N_STSYM,NIL,NIL, | |
995 | @var{address} | |
996 | ||
e505224d | 997 | 26 .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat |
139741da | 998 | 27 .align 4 |
e505224d | 999 | 28 _s_g_repeat: |
139741da | 1000 | 29 .word 2 |
e505224d PB |
1001 | @end example |
1002 | ||
1003 | ||
899bafeb | 1004 | @node Un-initialized statics |
e505224d PB |
1005 | @section Un-initialized static variables |
1006 | ||
139741da RP |
1007 | @table @strong |
1008 | @item Directive: | |
1009 | @code{.stabs} | |
1010 | @item Type: | |
1011 | @code{N_LCSYM} | |
1012 | @item Symbol Descriptors: | |
1013 | @code{S} (file scope), @code{V} (procedure scope) | |
1014 | @end table | |
e505224d | 1015 | |
139741da RP |
1016 | Un-initialized static variables are represented by the @code{N_LCSYM} |
1017 | stab type. The symbol descriptor part of the string shows if the | |
1018 | variable is file scope static (@samp{S}) or procedure scope static | |
1019 | (@samp{V}). In this example it is procedure scope static. The source | |
1020 | line allocating @code{s_flap} immediately follows the open brace for the | |
1021 | procedure @code{main}. | |
e505224d PB |
1022 | |
1023 | @example | |
1024 | 20 @{ | |
1025 | 21 static float s_flap; | |
1026 | @end example | |
1027 | ||
139741da RP |
1028 | The code that reserves storage for the variable @code{s_flap} precedes the |
1029 | body of body of @code{main}. | |
e505224d PB |
1030 | |
1031 | @example | |
139741da | 1032 | 39 .reserve _s_flap.0,4,"bss",4 |
e505224d PB |
1033 | @end example |
1034 | ||
139741da RP |
1035 | But since @code{s_flap} is scoped locally to @code{main}, its stab is |
1036 | located with the other stabs representing symbols local to @code{main}. | |
1037 | The stab for @code{s_flap} is located just before the @code{N_LBRAC} for | |
1038 | @code{main}. | |
e505224d PB |
1039 | |
1040 | @example | |
139741da RP |
1041 | @exdent @code{N_LCSYM} (40): uninitialized static var (BSS seg w/internal linkage) |
1042 | ||
1043 | .stabs "@var{name}: | |
1044 | @var{descriptor} | |
1045 | @var{type-ref}", | |
1046 | N_LCSYM, NIL, NIL, | |
1047 | @var{address} | |
e505224d | 1048 | |
e505224d PB |
1049 | 97 .stabs "s_flap:V12",40,0,0,_s_flap.0 |
1050 | 98 .stabs "times:1",128,0,0,-20 | |
139741da | 1051 | 99 .stabn 192,0,0,LBB2 # N_LBRAC for main. |
e505224d PB |
1052 | @end example |
1053 | ||
139741da RP |
1054 | @c ............................................................ |
1055 | ||
899bafeb | 1056 | @node Parameters |
e505224d PB |
1057 | @section Parameters |
1058 | ||
497e44a5 | 1059 | The symbol descriptor @samp{p} is used to refer to parameters which are |
b82ea042 JK |
1060 | in the arglist. Symbols have symbol type @samp{N_PSYM}. The value of |
1061 | the symbol is the offset relative to the argument list. | |
1062 | ||
1063 | If the parameter is passed in a register, then the traditional way to do | |
497e44a5 | 1064 | this is to provide two symbols for each argument: |
e505224d PB |
1065 | |
1066 | @example | |
b82ea042 JK |
1067 | .stabs "arg:p1" . . . ; N_PSYM |
1068 | .stabs "arg:r1" . . . ; N_RSYM | |
e505224d PB |
1069 | @end example |
1070 | ||
497e44a5 JK |
1071 | Debuggers are expected to use the second one to find the value, and the |
1072 | first one to know that it is an argument. | |
e505224d | 1073 | |
b82ea042 JK |
1074 | Because this is kind of ugly, some compilers use symbol descriptor |
1075 | @samp{P} or @samp{R} to indicate an argument which is in a register. | |
1076 | The symbol value is the register number. @samp{P} and @samp{R} mean the | |
1077 | same thing, the difference is that @samp{P} is a GNU invention and | |
1078 | @samp{R} is an IBM (xcoff) invention. As of version 4.9, GDB should | |
1079 | handle either one. Symbol type @samp{C_RPSYM} is used with @samp{R} and | |
1080 | @samp{N_RSYM} is used with @samp{P}. | |
1081 | ||
6897f9ec JK |
1082 | AIX, according to the documentation, uses @samp{D} for a parameter |
1083 | passed in a floating point register. This strikes me as incredibly | |
1084 | bogus---why doesn't it just use @samp{R} with a register number which | |
23aed449 | 1085 | indicates that it's a floating point register? I haven't verified |
6897f9ec JK |
1086 | whether the system actually does what the documentation indicates. |
1087 | ||
a2a2eac8 JK |
1088 | There is at least one case where GCC uses a @samp{p}/@samp{r} pair |
1089 | rather than @samp{P}; this is where the argument is passed in the | |
1090 | argument list and then loaded into a register. | |
1091 | ||
c156f3c1 JK |
1092 | On the sparc and hppa, for a @samp{P} symbol whose type is a structure |
1093 | or union, the register contains the address of the structure. On the | |
1094 | sparc, this is also true of a @samp{p}/@samp{r} pair (using Sun cc) or a | |
1095 | @samp{p} symbol. However, if a (small) structure is really in a | |
1096 | register, @samp{r} is used. And, to top it all off, on the hppa it | |
1097 | might be a structure which was passed on the stack and loaded into a | |
1098 | register and for which there is a @samp{p}/@samp{r} pair! I believe | |
6897f9ec JK |
1099 | that symbol descriptor @samp{i} is supposed to deal with this case, (it |
1100 | is said to mean "value parameter by reference, indirect access", I don't | |
1101 | know the source for this information) but I don't know details or what | |
1102 | compilers or debuggers use it, if any (not GDB or GCC). It is not clear | |
1103 | to me whether this case needs to be dealt with differently than | |
1104 | parameters passed by reference (see below). | |
c156f3c1 | 1105 | |
b82ea042 | 1106 | There is another case similar to an argument in a register, which is an |
98ef6f31 JK |
1107 | argument which is actually stored as a local variable. Sometimes this |
1108 | happens when the argument was passed in a register and then the compiler | |
1109 | stores it as a local variable. If possible, the compiler should claim | |
1110 | that it's in a register, but this isn't always done. Some compilers use | |
1111 | the pair of symbols approach described above ("arg:p" followed by | |
1112 | "arg:"); this includes gcc1 (not gcc2) on the sparc when passing a small | |
23aed449 JK |
1113 | structure and gcc2 (sometimes) when the argument type is float and it is |
1114 | passed as a double and converted to float by the prologue (in the latter | |
1115 | case the type of the "arg:p" symbol is double and the type of the "arg:" | |
1116 | symbol is float). GCC, at least on the 960, uses a single @samp{p} | |
1117 | symbol descriptor for an argument which is stored as a local variable | |
1118 | but uses @samp{N_LSYM} instead of @samp{N_PSYM}. In this case the value | |
1119 | of the symbol is an offset relative to the local variables for that | |
1120 | function, not relative to the arguments (on some machines those are the | |
1121 | same thing, but not on all). | |
e505224d | 1122 | |
6897f9ec JK |
1123 | If the parameter is passed by reference (e.g. Pascal VAR parameters), |
1124 | then type symbol descriptor is @samp{v} if it is in the argument list, | |
1125 | or @samp{a} if it in a register. Other than the fact that these contain | |
1126 | the address of the parameter other than the parameter itself, they are | |
1127 | identical to @samp{p} and @samp{R}, respectively. I believe @samp{a} is | |
1128 | an AIX invention; @samp{v} is supported by all stabs-using systems as | |
1129 | far as I know. | |
1130 | ||
1131 | @c Is this paragraph correct? It is based on piecing together patchy | |
1132 | @c information and some guesswork | |
1133 | Conformant arrays refer to a feature of Modula-2, and perhaps other | |
1134 | languages, in which the size of an array parameter is not known to the | |
1135 | called function until run-time. Such parameters have two stabs, a | |
1136 | @samp{x} for the array itself, and a @samp{C}, which represents the size | |
1137 | of the array. The value of the @samp{x} stab is the offset in the | |
1138 | argument list where the address of the array is stored (it this right? | |
1139 | it is a guess); the value of the @samp{C} stab is the offset in the | |
1140 | argument list where the size of the array (in elements? in bytes?) is | |
1141 | stored. | |
1142 | ||
1143 | The following are also said to go with @samp{N_PSYM}: | |
a2a2eac8 JK |
1144 | |
1145 | @example | |
1146 | "name" -> "param_name:#type" | |
a2a2eac8 | 1147 | -> pP (<<??>>) |
8c59ee11 | 1148 | -> pF FORTRAN function parameter |
a2a2eac8 JK |
1149 | -> X (function result variable) |
1150 | -> b (based variable) | |
1151 | ||
1152 | value -> offset from the argument pointer (positive). | |
1153 | @end example | |
1154 | ||
497e44a5 | 1155 | As a simple example, the code |
899bafeb | 1156 | |
497e44a5 | 1157 | @example |
b82ea042 JK |
1158 | main (argc, argv) |
1159 | int argc; | |
1160 | char **argv; | |
1161 | @{ | |
497e44a5 JK |
1162 | @end example |
1163 | ||
1164 | produces the stabs | |
899bafeb | 1165 | |
497e44a5 | 1166 | @example |
b82ea042 JK |
1167 | .stabs "main:F1",36,0,0,_main ; 36 is N_FUN |
1168 | .stabs "argc:p1",160,0,0,68 ; 160 is N_PSYM | |
1169 | .stabs "argv:p20=*21=*2",160,0,0,72 | |
e505224d PB |
1170 | @end example |
1171 | ||
497e44a5 | 1172 | The type definition of argv is interesting because it contains several |
a2a2eac8 JK |
1173 | type definitions. Type 21 is pointer to type 2 (char) and argv (type 20) is |
1174 | pointer to type 21. | |
e505224d | 1175 | |
8c59ee11 | 1176 | @node Types |
3d4cf720 | 1177 | @chapter Type Definitions |
e505224d | 1178 | |
612dbd4c | 1179 | Now let's look at some variable definitions involving complex types. |
e505224d PB |
1180 | This involves understanding better how types are described. In the |
1181 | examples so far types have been described as references to previously | |
1182 | defined types or defined in terms of subranges of or pointers to | |
1183 | previously defined types. The section that follows will talk about | |
1184 | the various other type descriptors that may follow the = sign in a | |
1185 | type definition. | |
1186 | ||
1187 | @menu | |
8c59ee11 JK |
1188 | * Builtin types:: Integers, floating point, void, etc. |
1189 | * Miscellaneous Types:: Pointers, sets, files, etc. | |
1190 | * Cross-references:: Referring to a type not yet defined. | |
1191 | * Subranges:: A type with a specific range. | |
1192 | * Arrays:: An aggregate type of same-typed elements. | |
1193 | * Strings:: Like an array but also has a length. | |
1194 | * Enumerations:: Like an integer but the values have names. | |
1195 | * Structures:: An aggregate type of different-typed elements. | |
ded6bcab JK |
1196 | * Typedefs:: Giving a type a name. |
1197 | * Unions:: Different types sharing storage. | |
1198 | * Function Types:: | |
e505224d PB |
1199 | @end menu |
1200 | ||
8c59ee11 JK |
1201 | @node Builtin types |
1202 | @section Builtin types | |
e505224d | 1203 | |
8c59ee11 JK |
1204 | Certain types are built in (@code{int}, @code{short}, @code{void}, |
1205 | @code{float}, etc.); the debugger recognizes these types and knows how | |
1206 | to handle them. Thus don't be surprised if some of the following ways | |
1207 | of specifying builtin types do not specify everything that a debugger | |
1208 | would need to know about the type---in some cases they merely specify | |
1209 | enough information to distinguish the type from other types. | |
1210 | ||
1211 | The traditional way to define builtin types is convolunted, so new ways | |
1212 | have been invented to describe them. Sun's ACC uses the @samp{b} and | |
1213 | @samp{R} type descriptors, and IBM uses negative type numbers. GDB can | |
1214 | accept all three, as of version 4.8; dbx just accepts the traditional | |
1215 | builtin types and perhaps one of the other two formats. | |
1216 | ||
1217 | @menu | |
1218 | * Traditional Builtin Types:: Put on your seatbelts and prepare for kludgery | |
1219 | * Builtin Type Descriptors:: Builtin types with special type descriptors | |
1220 | * Negative Type Numbers:: Builtin types using negative type numbers | |
1221 | @end menu | |
1222 | ||
1223 | @node Traditional Builtin Types | |
1224 | @subsection Traditional Builtin types | |
1225 | ||
1226 | Often types are defined as subranges of themselves. If the array bounds | |
1227 | can fit within an @code{int}, then they are given normally. For example: | |
1228 | ||
1229 | @example | |
1230 | .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 ; 128 is N_LSYM | |
1231 | .stabs "char:t2=r2;0;127;",128,0,0,0 | |
1232 | @end example | |
1233 | ||
1234 | Builtin types can also be described as subranges of @code{int}: | |
1235 | ||
1236 | @example | |
1237 | .stabs "unsigned short:t6=r1;0;65535;",128,0,0,0 | |
1238 | @end example | |
1239 | ||
b273dc0f JK |
1240 | If the lower bound of a subrange is 0 and the upper bound is -1, it |
1241 | means that the type is an unsigned integral type whose bounds are too | |
1242 | big to describe in an int. Traditionally this is only used for | |
1243 | @code{unsigned int} and @code{unsigned long}; GCC also sometimes uses it | |
1244 | for @code{long long} and @code{unsigned long long}, and the only way to | |
1245 | tell those types apart is to look at their names. On other machines GCC | |
1246 | puts out bounds in octal, with a leading 0. In this case a negative | |
1247 | bound consists of a number which is a 1 bit followed by a bunch of 0 | |
1248 | bits, and a positive bound is one in which a bunch of bits are 1. | |
8c59ee11 JK |
1249 | |
1250 | @example | |
1251 | .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0 | |
1252 | .stabs "long long int:t7=r1;0;-1;",128,0,0,0 | |
1253 | @end example | |
1254 | ||
b273dc0f JK |
1255 | If the lower bound of a subrange is 0 and the upper bound is negative, |
1256 | it means that it is an unsigned integral type whose size in bytes is the | |
1257 | absolute value of the upper bound. I believe this is a Convex | |
1258 | convention for @code{unsigned long long}. | |
1259 | ||
1260 | If the lower bound of a subrange is negative and the upper bound is 0, | |
1261 | it means that the type is a signed integral type whose size in bytes is | |
1262 | the absolute value of the lower bound. I believe this is a Convex | |
1263 | convention for @code{long long}. To distinguish this from a legitimate | |
1264 | subrange, the type should be a subrange of itself. I'm not sure whether | |
1265 | this is the case for Convex. | |
1266 | ||
8c59ee11 JK |
1267 | If the upper bound of a subrange is 0, it means that this is a floating |
1268 | point type, and the lower bound of the subrange indicates the number of | |
1269 | bytes in the type: | |
1270 | ||
1271 | @example | |
1272 | .stabs "float:t12=r1;4;0;",128,0,0,0 | |
1273 | .stabs "double:t13=r1;8;0;",128,0,0,0 | |
1274 | @end example | |
1275 | ||
1276 | However, GCC writes @code{long double} the same way it writes | |
1277 | @code{double}; the only way to distinguish them is by the name: | |
1278 | ||
1279 | @example | |
1280 | .stabs "long double:t14=r1;8;0;",128,0,0,0 | |
1281 | @end example | |
1282 | ||
1283 | Complex types are defined the same way as floating-point types; the only | |
1284 | way to distinguish a single-precision complex from a double-precision | |
1285 | floating-point type is by the name. | |
1286 | ||
1287 | The C @code{void} type is defined as itself: | |
1288 | ||
1289 | @example | |
1290 | .stabs "void:t15=15",128,0,0,0 | |
1291 | @end example | |
1292 | ||
1293 | I'm not sure how a boolean type is represented. | |
1294 | ||
1295 | @node Builtin Type Descriptors | |
1296 | @subsection Defining Builtin Types using Builtin Type Descriptors | |
1297 | ||
1298 | There are various type descriptors to define builtin types: | |
1299 | ||
1300 | @table @code | |
1a8b5668 JK |
1301 | @c FIXME: clean up description of width and offset, once we figure out |
1302 | @c what they mean | |
8c59ee11 JK |
1303 | @item b @var{signed} @var{char-flag} @var{width} ; @var{offset} ; @var{nbits} ; |
1304 | Define an integral type. @var{signed} is @samp{u} for unsigned or | |
1305 | @samp{s} for signed. @var{char-flag} is @samp{c} which indicates this | |
1306 | is a character type, or is omitted. I assume this is to distinguish an | |
1307 | integral type from a character type of the same size, for example it | |
1308 | might make sense to set it for the C type @code{wchar_t} so the debugger | |
1309 | can print such variables differently (Solaris does not do this). Sun | |
1310 | sets it on the C types @code{signed char} and @code{unsigned char} which | |
1311 | arguably is wrong. @var{width} and @var{offset} appear to be for small | |
1312 | objects stored in larger ones, for example a @code{short} in an | |
1313 | @code{int} register. @var{width} is normally the number of bytes in the | |
1314 | type. @var{offset} seems to always be zero. @var{nbits} is the number | |
1315 | of bits in the type. | |
1316 | ||
1317 | Note that type descriptor @samp{b} used for builtin types conflicts with | |
1318 | its use for Pascal space types (@pxref{Miscellaneous Types}); they can | |
1319 | be distinguished because the character following the type descriptor | |
1320 | will be a digit, @samp{(}, or @samp{-} for a Pascal space type, or | |
1321 | @samp{u} or @samp{s} for a builtin type. | |
1322 | ||
1323 | @item w | |
1324 | Documented by AIX to define a wide character type, but their compiler | |
1325 | actually uses negative type numbers (@pxref{Negative Type Numbers}). | |
1326 | ||
1a8b5668 JK |
1327 | @item R @var{fp_type} ; @var{bytes} ; |
1328 | Define a floating point type. @var{fp_type} has one of the following values: | |
1329 | ||
1330 | @table @code | |
1331 | @item 1 (NF_SINGLE) | |
1332 | IEEE 32-bit (single precision) floating point format. | |
1333 | ||
1334 | @item 2 (NF_DOUBLE) | |
1335 | IEEE 64-bit (double precision) floating point format. | |
1336 | ||
1337 | @item 3 (NF_COMPLEX) | |
1338 | @item 4 (NF_COMPLEX16) | |
1339 | @item 5 (NF_COMPLEX32) | |
3d4cf720 JK |
1340 | @c "GDB source" really means @file{include/aout/stab_gnu.h}, but trying |
1341 | @c to put that here got an overfull hbox. | |
1342 | These are for complex numbers. A comment in the GDB source describes | |
1343 | them as Fortran complex, double complex, and complex*16, respectively, | |
1344 | but what does that mean? (i.e. Single precision? Double precison?). | |
1a8b5668 JK |
1345 | |
1346 | @item 6 (NF_LDOUBLE) | |
ded6bcab JK |
1347 | Long double. This should probably only be used for Sun format long |
1348 | double, and new codes should be used for other floating point formats | |
1349 | (NF_DOUBLE can be used if a long double is really just an IEEE double, | |
1350 | of course). | |
1a8b5668 JK |
1351 | @end table |
1352 | ||
1353 | @var{bytes} is the number of bytes occupied by the type. This allows a | |
1354 | debugger to perform some operations with the type even if it doesn't | |
1355 | understand @var{fp_code}. | |
8c59ee11 JK |
1356 | |
1357 | @item g @var{type-information} ; @var{nbits} | |
1358 | Documented by AIX to define a floating type, but their compiler actually | |
1359 | uses negative type numbers (@pxref{Negative Type Numbers}). | |
1360 | ||
1361 | @item c @var{type-information} ; @var{nbits} | |
1362 | Documented by AIX to define a complex type, but their compiler actually | |
1363 | uses negative type numbers (@pxref{Negative Type Numbers}). | |
1364 | @end table | |
1365 | ||
1366 | The C @code{void} type is defined as a signed integral type 0 bits long: | |
1367 | @example | |
1368 | .stabs "void:t19=bs0;0;0",128,0,0,0 | |
1369 | @end example | |
e9f687d5 JK |
1370 | The Solaris compiler seems to omit the trailing semicolon in this case. |
1371 | Getting sloppy in this way is not a swift move because if a type is | |
1372 | embedded in a more complex expression it is necessary to be able to tell | |
1373 | where it ends. | |
8c59ee11 JK |
1374 | |
1375 | I'm not sure how a boolean type is represented. | |
1376 | ||
1377 | @node Negative Type Numbers | |
1378 | @subsection Negative Type numbers | |
1379 | ||
1380 | Since the debugger knows about the builtin types anyway, the idea of | |
1381 | negative type numbers is simply to give a special type number which | |
1382 | indicates the built in type. There is no stab defining these types. | |
1383 | ||
1384 | I'm not sure whether anyone has tried to define what this means if | |
1385 | @code{int} can be other than 32 bits (or other types can be other than | |
1386 | their customary size). If @code{int} has exactly one size for each | |
1387 | architecture, then it can be handled easily enough, but if the size of | |
1388 | @code{int} can vary according the compiler options, then it gets hairy. | |
1389 | I guess the consistent way to do this would be to define separate | |
1390 | negative type numbers for 16-bit @code{int} and 32-bit @code{int}; | |
1391 | therefore I have indicated below the customary size (and other format | |
1392 | information) for each type. The information below is currently correct | |
1393 | because AIX on the RS6000 is the only system which uses these type | |
1394 | numbers. If these type numbers start to get used on other systems, I | |
1395 | suspect the correct thing to do is to define a new number in cases where | |
1396 | a type does not have the size and format indicated below. | |
1397 | ||
b273dc0f JK |
1398 | Also note that part of the definition of the negative type number is |
1399 | the name of the type. Types with identical size and format but | |
1400 | different names have different negative type numbers. | |
1401 | ||
8c59ee11 JK |
1402 | @table @code |
1403 | @item -1 | |
1404 | @code{int}, 32 bit signed integral type. | |
1405 | ||
1406 | @item -2 | |
1407 | @code{char}, 8 bit type holding a character. Both GDB and dbx on AIX | |
1408 | treat this as signed. GCC uses this type whether @code{char} is signed | |
1409 | or not, which seems like a bad idea. The AIX compiler (xlc) seems to | |
1410 | avoid this type; it uses -5 instead for @code{char}. | |
1411 | ||
1412 | @item -3 | |
1413 | @code{short}, 16 bit signed integral type. | |
1414 | ||
1415 | @item -4 | |
1416 | @code{long}, 32 bit signed integral type. | |
1417 | ||
1418 | @item -5 | |
1419 | @code{unsigned char}, 8 bit unsigned integral type. | |
1420 | ||
1421 | @item -6 | |
1422 | @code{signed char}, 8 bit signed integral type. | |
1423 | ||
1424 | @item -7 | |
1425 | @code{unsigned short}, 16 bit unsigned integral type. | |
1426 | ||
1427 | @item -8 | |
1428 | @code{unsigned int}, 32 bit unsigned integral type. | |
1429 | ||
1430 | @item -9 | |
1431 | @code{unsigned}, 32 bit unsigned integral type. | |
1432 | ||
1433 | @item -10 | |
1434 | @code{unsigned long}, 32 bit unsigned integral type. | |
1435 | ||
1436 | @item -11 | |
1437 | @code{void}, type indicating the lack of a value. | |
1438 | ||
1439 | @item -12 | |
1440 | @code{float}, IEEE single precision. | |
1441 | ||
1442 | @item -13 | |
1443 | @code{double}, IEEE double precision. | |
1444 | ||
1445 | @item -14 | |
b273dc0f JK |
1446 | @code{long double}, IEEE double precision. The compiler claims the size |
1447 | will increase in a future release, and for binary compatibility you have | |
1448 | to avoid using @code{long double}. I hope when they increase it they | |
1449 | use a new negative type number. | |
8c59ee11 JK |
1450 | |
1451 | @item -15 | |
b273dc0f | 1452 | @code{integer}. 32 bit signed integral type. |
8c59ee11 JK |
1453 | |
1454 | @item -16 | |
b273dc0f | 1455 | @code{boolean}. Only one bit is used, not sure about the actual size of the |
8c59ee11 JK |
1456 | type. |
1457 | ||
1458 | @item -17 | |
b273dc0f | 1459 | @code{short real}. IEEE single precision. |
8c59ee11 JK |
1460 | |
1461 | @item -18 | |
b273dc0f | 1462 | @code{real}. IEEE double precision. |
8c59ee11 JK |
1463 | |
1464 | @item -19 | |
b273dc0f | 1465 | @code{stringptr}. @xref{Strings}. |
8c59ee11 JK |
1466 | |
1467 | @item -20 | |
1468 | @code{character}, 8 bit unsigned type. | |
1469 | ||
1470 | @item -21 | |
1471 | @code{logical*1}, 8 bit unsigned integral type. | |
1472 | ||
1473 | @item -22 | |
1474 | @code{logical*2}, 16 bit unsigned integral type. | |
1475 | ||
1476 | @item -23 | |
1477 | @code{logical*4}, 32 bit unsigned integral type. | |
1478 | ||
1479 | @item -24 | |
1480 | @code{logical}, 32 bit unsigned integral type. | |
1481 | ||
1482 | @item -25 | |
b273dc0f JK |
1483 | @code{complex}. A complex type consisting of two IEEE single-precision |
1484 | floating point values. | |
8c59ee11 JK |
1485 | |
1486 | @item -26 | |
b273dc0f JK |
1487 | @code{complex}. A complex type consisting of two IEEE double-precision |
1488 | floating point values. | |
8c59ee11 JK |
1489 | |
1490 | @item -27 | |
1491 | @code{integer*1}, 8 bit signed integral type. | |
1492 | ||
1493 | @item -28 | |
1494 | @code{integer*2}, 16 bit signed integral type. | |
1495 | ||
1496 | @item -29 | |
1497 | @code{integer*4}, 32 bit signed integral type. | |
1498 | ||
1499 | @item -30 | |
b273dc0f JK |
1500 | @code{wchar}. Wide character, 16 bits wide (Unicode format?). This is |
1501 | not used for the C type @code{wchar_t}. | |
8c59ee11 JK |
1502 | @end table |
1503 | ||
1504 | @node Miscellaneous Types | |
1505 | @section Miscellaneous Types | |
1506 | ||
1507 | @table @code | |
1508 | @item b @var{type-information} ; @var{bytes} | |
1509 | Pascal space type. This is documented by IBM; what does it mean? | |
1510 | ||
1511 | Note that this use of the @samp{b} type descriptor can be distinguished | |
1512 | from its use for builtin integral types (@pxref{Builtin Type | |
1513 | Descriptors}) because the character following the type descriptor is | |
1514 | always a digit, @samp{(}, or @samp{-}. | |
1515 | ||
1516 | @item B @var{type-information} | |
1517 | A volatile-qualified version of @var{type-information}. This is a Sun | |
1518 | extension. A volatile-qualified type means that references and stores | |
1519 | to a variable of that type must not be optimized or cached; they must | |
1520 | occur as the user specifies them. | |
1521 | ||
1522 | @item d @var{type-information} | |
1523 | File of type @var{type-information}. As far as I know this is only used | |
1524 | by Pascal. | |
1525 | ||
1526 | @item k @var{type-information} | |
1527 | A const-qualified version of @var{type-information}. This is a Sun | |
1528 | extension. A const-qualified type means that a variable of this type | |
1529 | cannot be modified. | |
1530 | ||
1531 | @item M @var{type-information} ; @var{length} | |
1532 | Multiple instance type. The type seems to composed of @var{length} | |
1533 | repetitions of @var{type-information}, for example @code{character*3} is | |
1534 | represented by @samp{M-2;3}, where @samp{-2} is a reference to a | |
1535 | character type (@pxref{Negative Type Numbers}). I'm not sure how this | |
1536 | differs from an array. This appears to be a FORTRAN feature. | |
1537 | @var{length} is a bound, like those in range types, @xref{Subranges}. | |
1538 | ||
1539 | @item S @var{type-information} | |
1540 | Pascal set type. @var{type-information} must be a small type such as an | |
1541 | enumeration or a subrange, and the type is a bitmask whose length is | |
1542 | specified by the number of elements in @var{type-information}. | |
1543 | ||
1544 | @item * @var{type-information} | |
1545 | Pointer to @var{type-information}. | |
139741da | 1546 | @end table |
e505224d | 1547 | |
8c59ee11 JK |
1548 | @node Cross-references |
1549 | @section Cross-references to other types | |
1550 | ||
1551 | If a type is used before it is defined, one common way to deal with this | |
1552 | is just to use a type reference to a type which has not yet been | |
1553 | defined. The debugger is expected to be able to deal with this. | |
1554 | ||
1555 | Another way is with the @samp{x} type descriptor, which is followed by | |
1556 | @samp{s} for a structure tag, @samp{u} for a union tag, or @samp{e} for | |
1557 | a enumerator tag, followed by the name of the tag, followed by @samp{:}. | |
1558 | for example the following C declarations: | |
e505224d PB |
1559 | |
1560 | @example | |
8c59ee11 JK |
1561 | struct foo; |
1562 | struct foo *bar; | |
e505224d PB |
1563 | @end example |
1564 | ||
8c59ee11 JK |
1565 | produce |
1566 | ||
1567 | @example | |
1568 | .stabs "bar:G16=*17=xsfoo:",32,0,0,0 | |
1569 | @end example | |
1570 | ||
1571 | Not all debuggers support the @samp{x} type descriptor, so on some | |
1572 | machines GCC does not use it. I believe that for the above example it | |
1573 | would just emit a reference to type 17 and never define it, but I | |
1574 | haven't verified that. | |
1575 | ||
1576 | Modula-2 imported types, at least on AIX, use the @samp{i} type | |
1577 | descriptor, which is followed by the name of the module from which the | |
1578 | type is imported, followed by @samp{:}, followed by the name of the | |
1579 | type. There is then optionally a comma followed by type information for | |
1580 | the type (This differs from merely naming the type (@pxref{Typedefs}) in | |
1581 | that it identifies the module; I don't understand whether the name of | |
1582 | the type given here is always just the same as the name we are giving | |
1583 | it, or whether this type descriptor is used with a nameless stab | |
1584 | (@pxref{Stabs Format}), or what). The symbol ends with @samp{;}. | |
e505224d | 1585 | |
8c59ee11 JK |
1586 | @node Subranges |
1587 | @section Subrange types | |
1588 | ||
1589 | The @samp{r} type descriptor defines a type as a subrange of another | |
1590 | type. It is followed by type information for the type which it is a | |
1591 | subrange of, a semicolon, an integral lower bound, a semicolon, an | |
1592 | integral upper bound, and a semicolon. The AIX documentation does not | |
63cef7d7 JK |
1593 | specify the trailing semicolon, in an effort to specify array indexes |
1594 | more cleanly, but a subrange which is not an array index has always | |
466bdeb2 | 1595 | included a trailing semicolon (@pxref{Arrays}). |
8c59ee11 | 1596 | |
8cfe3beb | 1597 | Instead of an integer, either bound can be one of the following: |
8c59ee11 JK |
1598 | |
1599 | @table @code | |
1600 | @item A @var{offset} | |
1601 | The bound is passed by reference on the stack at offset @var{offset} | |
1602 | from the argument list. @xref{Parameters}, for more information on such | |
1603 | offsets. | |
1604 | ||
1605 | @item T @var{offset} | |
1606 | The bound is passed by value on the stack at offset @var{offset} from | |
1607 | the argument list. | |
1608 | ||
1609 | @item a @var{register-number} | |
1610 | The bound is pased by reference in register number | |
1611 | @var{register-number}. | |
1612 | ||
1613 | @item t @var{register-number} | |
1614 | The bound is passed by value in register number @var{register-number}. | |
1615 | ||
1616 | @item J | |
1617 | There is no bound. | |
1618 | @end table | |
1619 | ||
1620 | Subranges are also used for builtin types, @xref{Traditional Builtin Types}. | |
1621 | ||
1622 | @node Arrays | |
1623 | @section Array types | |
1624 | ||
1625 | Arrays use the @samp{a} type descriptor. Following the type descriptor | |
63cef7d7 JK |
1626 | is the type of the index and the type of the array elements. If the |
1627 | index type is a range type, it will end in a semicolon; if it is not a | |
1628 | range type (for example, if it is a type reference), there does not | |
1629 | appear to be any way to tell where the types are separated. In an | |
1630 | effort to clean up this mess, IBM documents the two types as being | |
1631 | separated by a semicolon, and a range type as not ending in a semicolon | |
1632 | (but this is not right for range types which are not array indexes, | |
1633 | @pxref{Subranges}). I think probably the best solution is to specify | |
1634 | that a semicolon ends a range type, and that the index type and element | |
1635 | type of an array are separated by a semicolon, but that if the index | |
1636 | type is a range type, the extra semicolon can be omitted. GDB (at least | |
1637 | through version 4.9) doesn't support any kind of index type other than a | |
1638 | range anyway; I'm not sure about dbx. | |
6aa83a79 | 1639 | |
ee59134e | 1640 | It is well established, and widely used, that the type of the index, |
3d4cf720 JK |
1641 | unlike most types found in the stabs, is merely a type definition, not |
1642 | type information (@pxref{Stabs Format}) (that is, it need not start with | |
1643 | @var{type-number}@code{=} if it is defining a new type). According to a | |
1644 | comment in GDB, this is also true of the type of the array elements; it | |
1645 | gives @samp{ar1;1;10;ar1;1;10;4} as a legitimate way to express a two | |
1646 | dimensional array. According to AIX documentation, the element type | |
1647 | must be type information. GDB accepts either. | |
ee59134e | 1648 | |
6aa83a79 | 1649 | The type of the index is often a range type, expressed as the letter r |
8c59ee11 JK |
1650 | and some parameters. It defines the size of the array. In the example |
1651 | below, the range @code{r1;0;2;} defines an index type which is a | |
1652 | subrange of type 1 (integer), with a lower bound of 0 and an upper bound | |
1653 | of 2. This defines the valid range of subscripts of a three-element C | |
1654 | array. | |
e505224d | 1655 | |
8c59ee11 | 1656 | For example, the definition |
e505224d PB |
1657 | |
1658 | @example | |
8c59ee11 JK |
1659 | char char_vec[3] = @{'a','b','c'@}; |
1660 | @end example | |
e505224d | 1661 | |
8c59ee11 JK |
1662 | @noindent |
1663 | produces the output | |
1664 | ||
1665 | @example | |
1666 | .stabs "char_vec:G19=ar1;0;2;2",32,0,0,0 | |
1667 | .global _char_vec | |
1668 | .align 4 | |
1669 | _char_vec: | |
1670 | .byte 97 | |
1671 | .byte 98 | |
1672 | .byte 99 | |
1673 | @end example | |
1674 | ||
1675 | If an array is @dfn{packed}, it means that the elements are spaced more | |
1676 | closely than normal, saving memory at the expense of speed. For | |
1677 | example, an array of 3-byte objects might, if unpacked, have each | |
1678 | element aligned on a 4-byte boundary, but if packed, have no padding. | |
1679 | One way to specify that something is packed is with type attributes | |
1680 | (@pxref{Stabs Format}), in the case of arrays another is to use the | |
1681 | @samp{P} type descriptor instead of @samp{a}. Other than specifying a | |
1682 | packed array, @samp{P} is identical to @samp{a}. | |
1683 | ||
1684 | @c FIXME-what is it? A pointer? | |
1685 | An open array is represented by the @samp{A} type descriptor followed by | |
1686 | type information specifying the type of the array elements. | |
1687 | ||
1688 | @c FIXME: what is the format of this type? A pointer to a vector of pointers? | |
1689 | An N-dimensional dynamic array is represented by | |
1690 | ||
1691 | @example | |
1692 | D @var{dimensions} ; @var{type-information} | |
1693 | @end example | |
1694 | ||
1695 | @c Does dimensions really have this meaning? The AIX documentation | |
1696 | @c doesn't say. | |
1697 | @var{dimensions} is the number of dimensions; @var{type-information} | |
1698 | specifies the type of the array elements. | |
1699 | ||
1700 | @c FIXME: what is the format of this type? A pointer to some offsets in | |
1701 | @c another array? | |
1702 | A subarray of an N-dimensional array is represented by | |
1703 | ||
1704 | @example | |
1705 | E @var{dimensions} ; @var{type-information} | |
e505224d PB |
1706 | @end example |
1707 | ||
8c59ee11 JK |
1708 | @c Does dimensions really have this meaning? The AIX documentation |
1709 | @c doesn't say. | |
1710 | @var{dimensions} is the number of dimensions; @var{type-information} | |
1711 | specifies the type of the array elements. | |
1712 | ||
1713 | @node Strings | |
1714 | @section Strings | |
1715 | ||
1716 | Some languages, like C or the original Pascal, do not have string types, | |
1717 | they just have related things like arrays of characters. But most | |
1718 | Pascals and various other languages have string types, which are | |
1719 | indicated as follows: | |
1720 | ||
1721 | @table @code | |
1722 | @item n @var{type-information} ; @var{bytes} | |
1723 | @var{bytes} is the maximum length. I'm not sure what | |
1724 | @var{type-information} is; I suspect that it means that this is a string | |
1725 | of @var{type-information} (thus allowing a string of integers, a string | |
1726 | of wide characters, etc., as well as a string of characters). Not sure | |
1727 | what the format of this type is. This is an AIX feature. | |
1728 | ||
1729 | @item z @var{type-information} ; @var{bytes} | |
1730 | Just like @samp{n} except that this is a gstring, not an ordinary | |
1731 | string. I don't know the difference. | |
1732 | ||
1733 | @item N | |
1734 | Pascal Stringptr. What is this? This is an AIX feature. | |
1735 | @end table | |
1736 | ||
899bafeb | 1737 | @node Enumerations |
e505224d PB |
1738 | @section Enumerations |
1739 | ||
8c59ee11 | 1740 | Enumerations are defined with the @samp{e} type descriptor. |
e505224d | 1741 | |
8c59ee11 JK |
1742 | @c FIXME: Where does this information properly go? Perhaps it is |
1743 | @c redundant with something we already explain. | |
e505224d PB |
1744 | The source line below declares an enumeration type. It is defined at |
1745 | file scope between the bodies of main and s_proc in example2.c. | |
8c59ee11 | 1746 | The type definition is located after the N_RBRAC that marks the end of |
e505224d | 1747 | the previous procedure's block scope, and before the N_FUN that marks |
8c59ee11 JK |
1748 | the beginning of the next procedure's block scope. Therefore it does not |
1749 | describe a block local symbol, but a file local one. | |
1750 | ||
1751 | The source line: | |
e505224d PB |
1752 | |
1753 | @example | |
8c59ee11 | 1754 | enum e_places @{first,second=3,last@}; |
e505224d PB |
1755 | @end example |
1756 | ||
899bafeb | 1757 | @noindent |
8c59ee11 | 1758 | generates the following stab |
e505224d | 1759 | |
899bafeb | 1760 | @example |
8c59ee11 | 1761 | .stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0 |
899bafeb | 1762 | @end example |
e505224d PB |
1763 | |
1764 | The symbol descriptor (T) says that the stab describes a structure, | |
1765 | enumeration, or type tag. The type descriptor e, following the 22= of | |
1766 | the type definition narrows it down to an enumeration type. Following | |
1767 | the e is a list of the elements of the enumeration. The format is | |
1768 | name:value,. The list of elements ends with a ;. | |
1769 | ||
8c59ee11 JK |
1770 | There is no standard way to specify the size of an enumeration type; it |
1771 | is determined by the architecture (normally all enumerations types are | |
1772 | 32 bits). There should be a way to specify an enumeration type of | |
1773 | another size; type attributes would be one way to do this @xref{Stabs | |
1774 | Format}. | |
1775 | ||
1776 | @node Structures | |
1777 | @section Structures | |
e505224d | 1778 | |
139741da RP |
1779 | @table @strong |
1780 | @item Directive: | |
1781 | @code{.stabs} | |
1782 | @item Type: | |
8c59ee11 | 1783 | @code{N_LSYM} or @code{C_DECL} |
139741da RP |
1784 | @item Symbol Descriptor: |
1785 | @code{T} | |
1786 | @item Type Descriptor: | |
1787 | @code{s} | |
1788 | @end table | |
e505224d PB |
1789 | |
1790 | The following source code declares a structure tag and defines an | |
4d7f562d | 1791 | instance of the structure in global scope. Then a typedef equates the |
e505224d PB |
1792 | structure tag with a new type. A seperate stab is generated for the |
1793 | structure tag, the structure typedef, and the structure instance. The | |
1794 | stabs for the tag and the typedef are emited when the definitions are | |
1795 | encountered. Since the structure elements are not initialized, the | |
1796 | stab and code for the structure variable itself is located at the end | |
1797 | of the program in .common. | |
1798 | ||
1799 | @example | |
1800 | 6 struct s_tag @{ | |
1801 | 7 int s_int; | |
1802 | 8 float s_float; | |
1803 | 9 char s_char_vec[8]; | |
1804 | 10 struct s_tag* s_next; | |
1805 | 11 @} g_an_s; | |
1806 | 12 | |
1807 | 13 typedef struct s_tag s_typedef; | |
1808 | @end example | |
1809 | ||
1810 | The structure tag is an N_LSYM stab type because, like the enum, the | |
1811 | symbol is file scope. Like the enum, the symbol descriptor is T, for | |
1812 | enumeration, struct or tag type. The symbol descriptor s following | |
1813 | the 16= of the type definition narrows the symbol type to struct. | |
1814 | ||
1815 | Following the struct symbol descriptor is the number of bytes the | |
1816 | struct occupies, followed by a description of each structure element. | |
1817 | The structure element descriptions are of the form name:type, bit | |
1818 | offset from the start of the struct, and number of bits in the | |
1819 | element. | |
1820 | ||
1821 | ||
612dbd4c | 1822 | @example |
e505224d PB |
1823 | <128> N_LSYM - type definition |
1824 | .stabs "name:sym_desc(struct tag) Type_def(16)=type_desc(struct type) | |
139741da | 1825 | struct_bytes |
e505224d | 1826 | elem_name:type_ref(int),bit_offset,field_bits; |
139741da | 1827 | elem_name:type_ref(float),bit_offset,field_bits; |
6aa83a79 JG |
1828 | elem_name:type_def(17)=type_desc(array) |
1829 | index_type(range of int from 0 to 7); | |
1830 | element_type(char),bit_offset,field_bits;;", | |
139741da | 1831 | N_LSYM,NIL,NIL,NIL |
e505224d PB |
1832 | |
1833 | 30 .stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32; | |
139741da | 1834 | s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0 |
612dbd4c | 1835 | @end example |
e505224d PB |
1836 | |
1837 | In this example, two of the structure elements are previously defined | |
1838 | types. For these, the type following the name: part of the element | |
1839 | description is a simple type reference. The other two structure | |
1840 | elements are new types. In this case there is a type definition | |
1841 | embedded after the name:. The type definition for the array element | |
1842 | looks just like a type definition for a standalone array. The s_next | |
1843 | field is a pointer to the same kind of structure that the field is an | |
1844 | element of. So the definition of structure type 16 contains an type | |
1845 | definition for an element which is a pointer to type 16. | |
1846 | ||
899bafeb | 1847 | @node Typedefs |
8c59ee11 | 1848 | @section Giving a type a name |
e505224d | 1849 | |
8c59ee11 | 1850 | To give a type a name, use the @samp{t} symbol descriptor. For example, |
e505224d | 1851 | |
899bafeb | 1852 | @example |
8c59ee11 | 1853 | .stabs "s_typedef:t16",128,0,0,0 |
899bafeb | 1854 | @end example |
e505224d | 1855 | |
8c59ee11 JK |
1856 | specifies that @code{s_typedef} refers to type number 16. Such stabs |
1857 | have symbol type @code{N_LSYM} or @code{C_DECL}. | |
e505224d | 1858 | |
466bdeb2 | 1859 | If instead, you are specifying the tag name for a structure, union, or |
8c59ee11 JK |
1860 | enumeration, use the @samp{T} symbol descriptor instead. I believe C is |
1861 | the only language with this feature. | |
e505224d | 1862 | |
8c59ee11 JK |
1863 | If the type is an opaque type (I believe this is a Modula-2 feature), |
1864 | AIX provides a type descriptor to specify it. The type descriptor is | |
1865 | @samp{o} and is followed by a name. I don't know what the name | |
1866 | means---is it always the same as the name of the type, or is this type | |
1867 | descriptor used with a nameless stab (@pxref{Stabs Format})? There | |
1868 | optionally follows a comma followed by type information which defines | |
1869 | the type of this type. If omitted, a semicolon is used in place of the | |
1870 | comma and the type information, and, the type is much like a generic | |
1871 | pointer type---it has a known size but little else about it is | |
1872 | specified. | |
e505224d | 1873 | |
899bafeb | 1874 | @node Unions |
e505224d PB |
1875 | @section Unions |
1876 | ||
612dbd4c | 1877 | Next let's look at unions. In example2 this union type is declared |
e505224d PB |
1878 | locally to a procedure and an instance of the union is defined. |
1879 | ||
1880 | @example | |
1881 | 36 union u_tag @{ | |
1882 | 37 int u_int; | |
1883 | 38 float u_float; | |
1884 | 39 char* u_char; | |
1885 | 40 @} an_u; | |
1886 | @end example | |
1887 | ||
1888 | This code generates a stab for the union tag and a stab for the union | |
1889 | variable. Both use the N_LSYM stab type. Since the union variable is | |
1890 | scoped locally to the procedure in which it is defined, its stab is | |
139741da | 1891 | located immediately preceding the N_LBRAC for the procedure's block |
e505224d PB |
1892 | start. |
1893 | ||
139741da | 1894 | The stab for the union tag, however is located preceding the code for |
e505224d PB |
1895 | the procedure in which it is defined. The stab type is N_LSYM. This |
1896 | would seem to imply that the union type is file scope, like the struct | |
1897 | type s_tag. This is not true. The contents and position of the stab | |
1898 | for u_type do not convey any infomation about its procedure local | |
1899 | scope. | |
1900 | ||
899bafeb | 1901 | @display |
e505224d PB |
1902 | <128> N_LSYM - type |
1903 | .stabs "name:sym_desc(union tag)type_def(22)=type_desc(union) | |
1904 | byte_size(4) | |
1905 | elem_name:type_ref(int),bit_offset(0),bit_size(32); | |
1906 | elem_name:type_ref(float),bit_offset(0),bit_size(32); | |
1907 | elem_name:type_ref(ptr to char),bit_offset(0),bit_size(32);;" | |
1908 | N_LSYM, NIL, NIL, NIL | |
899bafeb | 1909 | @end display |
e505224d | 1910 | |
5bc927fb RP |
1911 | @smallexample |
1912 | 105 .stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;", | |
1913 | 128,0,0,0 | |
1914 | @end smallexample | |
e505224d PB |
1915 | |
1916 | The symbol descriptor, T, following the name: means that the stab | |
4d7f562d | 1917 | describes an enumeration, struct or type tag. The type descriptor u, |
e505224d PB |
1918 | following the 23= of the type definition, narrows it down to a union |
1919 | type definition. Following the u is the number of bytes in the union. | |
1920 | After that is a list of union element descriptions. Their format is | |
1921 | name:type, bit offset into the union, and number of bytes for the | |
1922 | element;. | |
1923 | ||
1924 | The stab for the union variable follows. Notice that the frame | |
1925 | pointer offset for local variables is negative. | |
1926 | ||
899bafeb | 1927 | @display |
e505224d PB |
1928 | <128> N_LSYM - local variable (with no symbol descriptor) |
1929 | .stabs "name:type_ref(u_tag)", N_LSYM, NIL, NIL, frame_ptr_offset | |
899bafeb | 1930 | @end display |
e505224d | 1931 | |
899bafeb | 1932 | @example |
e505224d | 1933 | 130 .stabs "an_u:23",128,0,0,-20 |
899bafeb | 1934 | @end example |
e505224d | 1935 | |
a03f27c3 | 1936 | @node Function Types |
e505224d PB |
1937 | @section Function types |
1938 | ||
8c59ee11 JK |
1939 | There are various types for function variables. These types are not |
1940 | used in defining functions; see symbol descriptor @samp{f}; they are | |
1941 | used for things like pointers to functions. | |
e505224d | 1942 | |
8c59ee11 JK |
1943 | The simple, traditional, type is type descriptor @samp{f} is followed by |
1944 | type information for the return type of the function, followed by a | |
1945 | semicolon. | |
1946 | ||
1947 | This does not deal with functions the number and type of whose | |
1948 | parameters are part of their type, as found in Modula-2 or ANSI C. AIX | |
1949 | provides extensions to specify these, using the @samp{f}, @samp{F}, | |
1950 | @samp{p}, and @samp{R} type descriptors. | |
1951 | ||
1952 | First comes the type descriptor. Then, if it is @samp{f} or @samp{F}, | |
1953 | this is a function, and the type information for the return type of the | |
1954 | function follows, followed by a comma. Then comes the number of | |
1955 | parameters to the function and a semicolon. Then, for each parameter, | |
1956 | there is the name of the parameter followed by a colon (this is only | |
1957 | present for type descriptors @samp{R} and @samp{F} which represent | |
1958 | Pascal function or procedure parameters), type information for the | |
1959 | parameter, a comma, @samp{0} if passed by reference or @samp{1} if | |
1960 | passed by value, and a semicolon. The type definition ends with a | |
1961 | semicolon. | |
1962 | ||
1963 | For example, | |
e505224d PB |
1964 | |
1965 | @example | |
8c59ee11 | 1966 | int (*g_pf)(); |
e505224d PB |
1967 | @end example |
1968 | ||
8c59ee11 JK |
1969 | @noindent |
1970 | generates the following code: | |
e505224d | 1971 | |
899bafeb | 1972 | @example |
8c59ee11 JK |
1973 | .stabs "g_pf:G24=*25=f1",32,0,0,0 |
1974 | .common _g_pf,4,"bss" | |
899bafeb | 1975 | @end example |
e505224d | 1976 | |
8c59ee11 JK |
1977 | The variable defines a new type, 24, which is a pointer to another new |
1978 | type, 25, which is defined as a function returning int. | |
e505224d | 1979 | |
63cef7d7 | 1980 | @node Symbol Tables |
e505224d PB |
1981 | @chapter Symbol information in symbol tables |
1982 | ||
1983 | This section examines more closely the format of symbol table entries | |
1984 | and how stab assembler directives map to them. It also describes what | |
1985 | transformations the assembler and linker make on data from stabs. | |
1986 | ||
1987 | Each time the assembler encounters a stab in its input file it puts | |
1988 | each field of the stab into corresponding fields in a symbol table | |
1989 | entry of its output file. If the stab contains a string field, the | |
1990 | symbol table entry for that stab points to a string table entry | |
1991 | containing the string data from the stab. Assembler labels become | |
1992 | relocatable addresses. Symbol table entries in a.out have the format: | |
1993 | ||
1994 | @example | |
1995 | struct internal_nlist @{ | |
139741da RP |
1996 | unsigned long n_strx; /* index into string table of name */ |
1997 | unsigned char n_type; /* type of symbol */ | |
1998 | unsigned char n_other; /* misc info (usually empty) */ | |
1999 | unsigned short n_desc; /* description field */ | |
2000 | bfd_vma n_value; /* value of symbol */ | |
e505224d PB |
2001 | @}; |
2002 | @end example | |
2003 | ||
2004 | For .stabs directives, the n_strx field holds the character offset | |
2005 | from the start of the string table to the string table entry | |
2006 | containing the "string" field. For other classes of stabs (.stabn and | |
2007 | .stabd) this field is null. | |
2008 | ||
2009 | Symbol table entries with n_type fields containing a value greater or | |
2010 | equal to 0x20 originated as stabs generated by the compiler (with one | |
2011 | random exception). Those with n_type values less than 0x20 were | |
2012 | placed in the symbol table of the executable by the assembler or the | |
2013 | linker. | |
2014 | ||
2015 | The linker concatenates object files and does fixups of externally | |
2016 | defined symbols. You can see the transformations made on stab data by | |
2017 | the assembler and linker by examining the symbol table after each pass | |
2018 | of the build, first the assemble and then the link. | |
2019 | ||
2020 | To do this use nm with the -ap options. This dumps the symbol table, | |
2021 | including debugging information, unsorted. For stab entries the | |
2022 | columns are: value, other, desc, type, string. For assembler and | |
2023 | linker symbols, the columns are: value, type, string. | |
2024 | ||
2025 | There are a few important things to notice about symbol tables. Where | |
2026 | the value field of a stab contains a frame pointer offset, or a | |
2027 | register number, that value is unchanged by the rest of the build. | |
2028 | ||
2029 | Where the value field of a stab contains an assembly language label, | |
2030 | it is transformed by each build step. The assembler turns it into a | |
2031 | relocatable address and the linker turns it into an absolute address. | |
2032 | This source line defines a static variable at file scope: | |
2033 | ||
899bafeb | 2034 | @example |
e505224d | 2035 | 3 static int s_g_repeat |
899bafeb | 2036 | @end example |
e505224d | 2037 | |
899bafeb | 2038 | @noindent |
e505224d PB |
2039 | The following stab describes the symbol. |
2040 | ||
899bafeb | 2041 | @example |
e505224d | 2042 | 26 .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat |
899bafeb | 2043 | @end example |
e505224d | 2044 | |
899bafeb | 2045 | @noindent |
e505224d | 2046 | The assembler transforms the stab into this symbol table entry in the |
899bafeb | 2047 | @file{.o} file. The location is expressed as a data segment offset. |
e505224d | 2048 | |
899bafeb | 2049 | @example |
e505224d | 2050 | 21 00000084 - 00 0000 STSYM s_g_repeat:S1 |
899bafeb | 2051 | @end example |
e505224d | 2052 | |
899bafeb | 2053 | @noindent |
e505224d PB |
2054 | in the symbol table entry from the executable, the linker has made the |
2055 | relocatable address absolute. | |
2056 | ||
899bafeb | 2057 | @example |
e505224d | 2058 | 22 0000e00c - 00 0000 STSYM s_g_repeat:S1 |
899bafeb | 2059 | @end example |
e505224d PB |
2060 | |
2061 | Stabs for global variables do not contain location information. In | |
2062 | this case the debugger finds location information in the assembler or | |
2063 | linker symbol table entry describing the variable. The source line: | |
2064 | ||
899bafeb | 2065 | @example |
e505224d | 2066 | 1 char g_foo = 'c'; |
899bafeb | 2067 | @end example |
e505224d | 2068 | |
899bafeb | 2069 | @noindent |
e505224d PB |
2070 | generates the stab: |
2071 | ||
899bafeb | 2072 | @example |
e505224d | 2073 | 21 .stabs "g_foo:G2",32,0,0,0 |
899bafeb | 2074 | @end example |
e505224d PB |
2075 | |
2076 | The variable is represented by the following two symbol table entries | |
2077 | in the object file. The first one originated as a stab. The second | |
2078 | one is an external symbol. The upper case D signifies that the n_type | |
2079 | field of the symbol table contains 7, N_DATA with local linkage (see | |
2080 | Table B). The value field following the file's line number is empty | |
2081 | for the stab entry. For the linker symbol it contains the | |
2082 | rellocatable address corresponding to the variable. | |
2083 | ||
899bafeb | 2084 | @example |
e505224d PB |
2085 | 19 00000000 - 00 0000 GSYM g_foo:G2 |
2086 | 20 00000080 D _g_foo | |
899bafeb | 2087 | @end example |
e505224d | 2088 | |
899bafeb | 2089 | @noindent |
e505224d PB |
2090 | These entries as transformed by the linker. The linker symbol table |
2091 | entry now holds an absolute address. | |
2092 | ||
899bafeb | 2093 | @example |
e505224d | 2094 | 21 00000000 - 00 0000 GSYM g_foo:G2 |
899bafeb | 2095 | @dots{} |
e505224d | 2096 | 215 0000e008 D _g_foo |
899bafeb | 2097 | @end example |
e505224d | 2098 | |
8c59ee11 | 2099 | @node Cplusplus |
612dbd4c | 2100 | @chapter GNU C++ stabs |
e505224d PB |
2101 | |
2102 | @menu | |
b32ae57b | 2103 | * Basic Cplusplus types:: |
e505224d PB |
2104 | * Simple classes:: |
2105 | * Class instance:: | |
2106 | * Methods:: Method definition | |
2107 | * Protections:: | |
2dd00294 JG |
2108 | * Method Modifiers:: (const, volatile, const volatile) |
2109 | * Virtual Methods:: | |
2110 | * Inheritence:: | |
2111 | * Virtual Base Classes:: | |
2112 | * Static Members:: | |
e505224d PB |
2113 | @end menu |
2114 | ||
e505224d PB |
2115 | @subsection type descriptors added for C++ descriptions |
2116 | ||
2117 | @table @code | |
2118 | @item # | |
2119 | method type (two ## if minimal debug) | |
2120 | ||
8c59ee11 JK |
2121 | @item @@ |
2122 | Member (class and variable) type. It is followed by type information | |
2123 | for the offset basetype, a comma, and type information for the type of | |
2124 | the field being pointed to. (FIXME: this is acknowledged to be | |
2125 | gibberish. Can anyone say what really goes here?). | |
2126 | ||
2127 | Note that there is a conflict between this and type attributes | |
2128 | (@pxref{Stabs Format}); both use type descriptor @samp{@@}. | |
2129 | Fortunately, the @samp{@@} type descriptor used in this C++ sense always | |
2130 | will be followed by a digit, @samp{(}, or @samp{-}, and type attributes | |
2131 | never start with those things. | |
e505224d PB |
2132 | @end table |
2133 | ||
b32ae57b | 2134 | @node Basic Cplusplus types |
e505224d PB |
2135 | @section Basic types for C++ |
2136 | ||
2137 | << the examples that follow are based on a01.C >> | |
2138 | ||
2139 | ||
2140 | C++ adds two more builtin types to the set defined for C. These are | |
2141 | the unknown type and the vtable record type. The unknown type, type | |
2142 | 16, is defined in terms of itself like the void type. | |
2143 | ||
2144 | The vtable record type, type 17, is defined as a structure type and | |
2145 | then as a structure tag. The structure has four fields, delta, index, | |
2146 | pfn, and delta2. pfn is the function pointer. | |
2147 | ||
2148 | << In boilerplate $vtbl_ptr_type, what are the fields delta, | |
2149 | index, and delta2 used for? >> | |
2150 | ||
2151 | This basic type is present in all C++ programs even if there are no | |
2152 | virtual methods defined. | |
2153 | ||
899bafeb | 2154 | @display |
e505224d | 2155 | .stabs "struct_name:sym_desc(type)type_def(17)=type_desc(struct)struct_bytes(8) |
139741da RP |
2156 | elem_name(delta):type_ref(short int),bit_offset(0),field_bits(16); |
2157 | elem_name(index):type_ref(short int),bit_offset(16),field_bits(16); | |
2158 | elem_name(pfn):type_def(18)=type_desc(ptr to)type_ref(void), | |
2159 | bit_offset(32),field_bits(32); | |
2160 | elem_name(delta2):type_def(short int);bit_offset(32),field_bits(16);;" | |
2161 | N_LSYM, NIL, NIL | |
899bafeb | 2162 | @end display |
139741da | 2163 | |
899bafeb | 2164 | @smallexample |
e505224d | 2165 | .stabs "$vtbl_ptr_type:t17=s8 |
139741da RP |
2166 | delta:6,0,16;index:6,16,16;pfn:18=*15,32,32;delta2:6,32,16;;" |
2167 | ,128,0,0,0 | |
899bafeb | 2168 | @end smallexample |
e505224d | 2169 | |
899bafeb | 2170 | @display |
e505224d | 2171 | .stabs "name:sym_dec(struct tag)type_ref($vtbl_ptr_type)",N_LSYM,NIL,NIL,NIL |
899bafeb | 2172 | @end display |
e505224d | 2173 | |
899bafeb | 2174 | @example |
e505224d | 2175 | .stabs "$vtbl_ptr_type:T17",128,0,0,0 |
899bafeb | 2176 | @end example |
e505224d | 2177 | |
899bafeb | 2178 | @node Simple classes |
e505224d PB |
2179 | @section Simple class definition |
2180 | ||
2181 | The stabs describing C++ language features are an extension of the | |
2182 | stabs describing C. Stabs representing C++ class types elaborate | |
2183 | extensively on the stab format used to describe structure types in C. | |
2184 | Stabs representing class type variables look just like stabs | |
2185 | representing C language variables. | |
2186 | ||
2187 | Consider the following very simple class definition. | |
2188 | ||
2189 | @example | |
2190 | class baseA @{ | |
2191 | public: | |
139741da RP |
2192 | int Adat; |
2193 | int Ameth(int in, char other); | |
e505224d PB |
2194 | @}; |
2195 | @end example | |
2196 | ||
2197 | The class baseA is represented by two stabs. The first stab describes | |
2198 | the class as a structure type. The second stab describes a structure | |
2199 | tag of the class type. Both stabs are of stab type N_LSYM. Since the | |
2200 | stab is not located between an N_FUN and a N_LBRAC stab this indicates | |
2201 | that the class is defined at file scope. If it were, then the N_LSYM | |
2202 | would signify a local variable. | |
2203 | ||
2204 | A stab describing a C++ class type is similar in format to a stab | |
2205 | describing a C struct, with each class member shown as a field in the | |
2206 | structure. The part of the struct format describing fields is | |
2207 | expanded to include extra information relevent to C++ class members. | |
2208 | In addition, if the class has multiple base classes or virtual | |
2209 | functions the struct format outside of the field parts is also | |
2210 | augmented. | |
2211 | ||
2212 | In this simple example the field part of the C++ class stab | |
2213 | representing member data looks just like the field part of a C struct | |
2214 | stab. The section on protections describes how its format is | |
2215 | sometimes extended for member data. | |
2216 | ||
2217 | The field part of a C++ class stab representing a member function | |
2218 | differs substantially from the field part of a C struct stab. It | |
2219 | still begins with `name:' but then goes on to define a new type number | |
2220 | for the member function, describe its return type, its argument types, | |
2221 | its protection level, any qualifiers applied to the method definition, | |
2222 | and whether the method is virtual or not. If the method is virtual | |
2223 | then the method description goes on to give the vtable index of the | |
2224 | method, and the type number of the first base class defining the | |
2225 | method. | |
2226 | ||
2227 | When the field name is a method name it is followed by two colons | |
2228 | rather than one. This is followed by a new type definition for the | |
2229 | method. This is a number followed by an equal sign and then the | |
2230 | symbol descriptor `##', indicating a method type. This is followed by | |
2231 | a type reference showing the return type of the method and a | |
2232 | semi-colon. | |
2233 | ||
2234 | The format of an overloaded operator method name differs from that | |
2235 | of other methods. It is "op$::XXXX." where XXXX is the operator name | |
612dbd4c JG |
2236 | such as + or +=. The name ends with a period, and any characters except |
2237 | the period can occur in the XXXX string. | |
e505224d PB |
2238 | |
2239 | The next part of the method description represents the arguments to | |
2240 | the method, preceeded by a colon and ending with a semi-colon. The | |
2241 | types of the arguments are expressed in the same way argument types | |
2242 | are expressed in C++ name mangling. In this example an int and a char | |
2243 | map to `ic'. | |
2244 | ||
2245 | This is followed by a number, a letter, and an asterisk or period, | |
2246 | followed by another semicolon. The number indicates the protections | |
2247 | that apply to the member function. Here the 2 means public. The | |
2248 | letter encodes any qualifier applied to the method definition. In | |
2249 | this case A means that it is a normal function definition. The dot | |
2250 | shows that the method is not virtual. The sections that follow | |
2251 | elaborate further on these fields and describe the additional | |
2252 | information present for virtual methods. | |
2253 | ||
2254 | ||
899bafeb | 2255 | @display |
e505224d | 2256 | .stabs "class_name:sym_desc(type)type_def(20)=type_desc(struct)struct_bytes(4) |
139741da | 2257 | field_name(Adat):type(int),bit_offset(0),field_bits(32); |
e505224d | 2258 | |
139741da RP |
2259 | method_name(Ameth)::type_def(21)=type_desc(method)return_type(int); |
2260 | :arg_types(int char); | |
2261 | protection(public)qualifier(normal)virtual(no);;" | |
2262 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 2263 | @end display |
e505224d | 2264 | |
899bafeb | 2265 | @smallexample |
e505224d PB |
2266 | .stabs "baseA:t20=s4Adat:1,0,32;Ameth::21=##1;:ic;2A.;;",128,0,0,0 |
2267 | ||
2268 | .stabs "class_name:sym_desc(struct tag)",N_LSYM,NIL,NIL,NIL | |
2269 | ||
2270 | .stabs "baseA:T20",128,0,0,0 | |
899bafeb | 2271 | @end smallexample |
e505224d | 2272 | |
899bafeb | 2273 | @node Class instance |
e505224d PB |
2274 | @section Class instance |
2275 | ||
2276 | As shown above, describing even a simple C++ class definition is | |
2277 | accomplished by massively extending the stab format used in C to | |
2278 | describe structure types. However, once the class is defined, C stabs | |
2279 | with no modifications can be used to describe class instances. The | |
2280 | following source: | |
2281 | ||
2282 | @example | |
2283 | main () @{ | |
139741da | 2284 | baseA AbaseA; |
e505224d PB |
2285 | @} |
2286 | @end example | |
2287 | ||
899bafeb RP |
2288 | @noindent |
2289 | yields the following stab describing the class instance. It looks no | |
e505224d PB |
2290 | different from a standard C stab describing a local variable. |
2291 | ||
899bafeb | 2292 | @display |
e505224d | 2293 | .stabs "name:type_ref(baseA)", N_LSYM, NIL, NIL, frame_ptr_offset |
899bafeb | 2294 | @end display |
e505224d | 2295 | |
899bafeb | 2296 | @example |
e505224d | 2297 | .stabs "AbaseA:20",128,0,0,-20 |
899bafeb | 2298 | @end example |
e505224d | 2299 | |
899bafeb | 2300 | @node Methods |
e505224d PB |
2301 | @section Method defintion |
2302 | ||
2303 | The class definition shown above declares Ameth. The C++ source below | |
2304 | defines Ameth: | |
2305 | ||
2306 | @example | |
2307 | int | |
2308 | baseA::Ameth(int in, char other) | |
2309 | @{ | |
139741da | 2310 | return in; |
e505224d PB |
2311 | @}; |
2312 | @end example | |
2313 | ||
2314 | ||
2315 | This method definition yields three stabs following the code of the | |
2316 | method. One stab describes the method itself and following two | |
2317 | describe its parameters. Although there is only one formal argument | |
2318 | all methods have an implicit argument which is the `this' pointer. | |
2319 | The `this' pointer is a pointer to the object on which the method was | |
2320 | called. Note that the method name is mangled to encode the class name | |
2321 | and argument types. << Name mangling is not described by this | |
2322 | document - Is there already such a doc? >> | |
2323 | ||
612dbd4c | 2324 | @example |
e505224d | 2325 | .stabs "name:symbol_desriptor(global function)return_type(int)", |
139741da | 2326 | N_FUN, NIL, NIL, code_addr_of_method_start |
e505224d PB |
2327 | |
2328 | .stabs "Ameth__5baseAic:F1",36,0,0,_Ameth__5baseAic | |
612dbd4c | 2329 | @end example |
e505224d PB |
2330 | |
2331 | Here is the stab for the `this' pointer implicit argument. The name | |
c2dc518b | 2332 | of the `this' pointer is always `this.' Type 19, the `this' pointer is |
e505224d PB |
2333 | defined as a pointer to type 20, baseA, but a stab defining baseA has |
2334 | not yet been emited. Since the compiler knows it will be emited | |
2335 | shortly, here it just outputs a cross reference to the undefined | |
2336 | symbol, by prefixing the symbol name with xs. | |
2337 | ||
612dbd4c | 2338 | @example |
e505224d | 2339 | .stabs "name:sym_desc(register param)type_def(19)= |
139741da | 2340 | type_desc(ptr to)type_ref(baseA)= |
e505224d PB |
2341 | type_desc(cross-reference to)baseA:",N_RSYM,NIL,NIL,register_number |
2342 | ||
c2dc518b | 2343 | .stabs "this:P19=*20=xsbaseA:",64,0,0,8 |
612dbd4c | 2344 | @end example |
e505224d PB |
2345 | |
2346 | The stab for the explicit integer argument looks just like a parameter | |
2347 | to a C function. The last field of the stab is the offset from the | |
2348 | argument pointer, which in most systems is the same as the frame | |
2349 | pointer. | |
2350 | ||
612dbd4c | 2351 | @example |
e505224d | 2352 | .stabs "name:sym_desc(value parameter)type_ref(int)", |
139741da | 2353 | N_PSYM,NIL,NIL,offset_from_arg_ptr |
e505224d PB |
2354 | |
2355 | .stabs "in:p1",160,0,0,72 | |
612dbd4c | 2356 | @end example |
e505224d PB |
2357 | |
2358 | << The examples that follow are based on A1.C >> | |
2359 | ||
899bafeb | 2360 | @node Protections |
e505224d PB |
2361 | @section Protections |
2362 | ||
2363 | ||
2364 | In the simple class definition shown above all member data and | |
2365 | functions were publicly accessable. The example that follows | |
2366 | contrasts public, protected and privately accessable fields and shows | |
2367 | how these protections are encoded in C++ stabs. | |
2368 | ||
2369 | Protections for class member data are signified by two characters | |
2370 | embeded in the stab defining the class type. These characters are | |
2371 | located after the name: part of the string. /0 means private, /1 | |
2372 | means protected, and /2 means public. If these characters are omited | |
2373 | this means that the member is public. The following C++ source: | |
2374 | ||
2375 | @example | |
2376 | class all_data @{ | |
139741da RP |
2377 | private: |
2378 | int priv_dat; | |
e505224d | 2379 | protected: |
139741da | 2380 | char prot_dat; |
e505224d | 2381 | public: |
139741da | 2382 | float pub_dat; |
e505224d PB |
2383 | @}; |
2384 | @end example | |
2385 | ||
899bafeb | 2386 | @noindent |
e505224d PB |
2387 | generates the following stab to describe the class type all_data. |
2388 | ||
899bafeb | 2389 | @display |
e505224d | 2390 | .stabs "class_name:sym_desc(type)type_def(19)=type_desc(struct)struct_bytes |
139741da RP |
2391 | data_name:/protection(private)type_ref(int),bit_offset,num_bits; |
2392 | data_name:/protection(protected)type_ref(char),bit_offset,num_bits; | |
2393 | data_name:(/num omited, private)type_ref(float),bit_offset,num_bits;;" | |
2394 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 2395 | @end display |
e505224d | 2396 | |
899bafeb | 2397 | @smallexample |
e505224d | 2398 | .stabs "all_data:t19=s12 |
139741da | 2399 | priv_dat:/01,0,32;prot_dat:/12,32,8;pub_dat:12,64,32;;",128,0,0,0 |
899bafeb | 2400 | @end smallexample |
e505224d PB |
2401 | |
2402 | Protections for member functions are signified by one digit embeded in | |
2403 | the field part of the stab describing the method. The digit is 0 if | |
2404 | private, 1 if protected and 2 if public. Consider the C++ class | |
2405 | definition below: | |
2406 | ||
2407 | @example | |
2408 | class all_methods @{ | |
2409 | private: | |
139741da | 2410 | int priv_meth(int in)@{return in;@}; |
e505224d | 2411 | protected: |
139741da | 2412 | char protMeth(char in)@{return in;@}; |
e505224d | 2413 | public: |
139741da | 2414 | float pubMeth(float in)@{return in;@}; |
e505224d PB |
2415 | @}; |
2416 | @end example | |
2417 | ||
2418 | It generates the following stab. The digit in question is to the left | |
2419 | of an `A' in each case. Notice also that in this case two symbol | |
2420 | descriptors apply to the class name struct tag and struct type. | |
2421 | ||
899bafeb | 2422 | @display |
e505224d | 2423 | .stabs "class_name:sym_desc(struct tag&type)type_def(21)= |
139741da RP |
2424 | sym_desc(struct)struct_bytes(1) |
2425 | meth_name::type_def(22)=sym_desc(method)returning(int); | |
2426 | :args(int);protection(private)modifier(normal)virtual(no); | |
2427 | meth_name::type_def(23)=sym_desc(method)returning(char); | |
2428 | :args(char);protection(protected)modifier(normal)virual(no); | |
2429 | meth_name::type_def(24)=sym_desc(method)returning(float); | |
2430 | :args(float);protection(public)modifier(normal)virtual(no);;", | |
2431 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 2432 | @end display |
139741da | 2433 | |
899bafeb | 2434 | @smallexample |
e505224d | 2435 | .stabs "all_methods:Tt21=s1priv_meth::22=##1;:i;0A.;protMeth::23=##2;:c;1A.; |
139741da | 2436 | pubMeth::24=##12;:f;2A.;;",128,0,0,0 |
899bafeb | 2437 | @end smallexample |
e505224d | 2438 | |
899bafeb RP |
2439 | @node Method Modifiers |
2440 | @section Method Modifiers (const, volatile, const volatile) | |
e505224d PB |
2441 | |
2442 | << based on a6.C >> | |
2443 | ||
2444 | In the class example described above all the methods have the normal | |
2445 | modifier. This method modifier information is located just after the | |
2446 | protection information for the method. This field has four possible | |
2447 | character values. Normal methods use A, const methods use B, volatile | |
2448 | methods use C, and const volatile methods use D. Consider the class | |
2449 | definition below: | |
2450 | ||
2451 | @example | |
2452 | class A @{ | |
2453 | public: | |
139741da RP |
2454 | int ConstMeth (int arg) const @{ return arg; @}; |
2455 | char VolatileMeth (char arg) volatile @{ return arg; @}; | |
2456 | float ConstVolMeth (float arg) const volatile @{return arg; @}; | |
e505224d PB |
2457 | @}; |
2458 | @end example | |
2459 | ||
2460 | This class is described by the following stab: | |
2461 | ||
899bafeb | 2462 | @display |
e505224d | 2463 | .stabs "class(A):sym_desc(struct)type_def(20)=type_desc(struct)struct_bytes(1) |
139741da RP |
2464 | meth_name(ConstMeth)::type_def(21)sym_desc(method) |
2465 | returning(int);:arg(int);protection(public)modifier(const)virtual(no); | |
2466 | meth_name(VolatileMeth)::type_def(22)=sym_desc(method) | |
2467 | returning(char);:arg(char);protection(public)modifier(volatile)virt(no) | |
2468 | meth_name(ConstVolMeth)::type_def(23)=sym_desc(method) | |
2469 | returning(float);:arg(float);protection(public)modifer(const volatile) | |
2470 | virtual(no);;", @dots{} | |
899bafeb | 2471 | @end display |
139741da | 2472 | |
899bafeb | 2473 | @example |
e505224d | 2474 | .stabs "A:T20=s1ConstMeth::21=##1;:i;2B.;VolatileMeth::22=##2;:c;2C.; |
139741da | 2475 | ConstVolMeth::23=##12;:f;2D.;;",128,0,0,0 |
612dbd4c | 2476 | @end example |
e505224d | 2477 | |
899bafeb | 2478 | @node Virtual Methods |
e505224d PB |
2479 | @section Virtual Methods |
2480 | ||
2481 | << The following examples are based on a4.C >> | |
2482 | ||
2483 | The presence of virtual methods in a class definition adds additional | |
2484 | data to the class description. The extra data is appended to the | |
2485 | description of the virtual method and to the end of the class | |
2486 | description. Consider the class definition below: | |
2487 | ||
2488 | @example | |
2489 | class A @{ | |
2490 | public: | |
139741da RP |
2491 | int Adat; |
2492 | virtual int A_virt (int arg) @{ return arg; @}; | |
e505224d PB |
2493 | @}; |
2494 | @end example | |
2495 | ||
2496 | This results in the stab below describing class A. It defines a new | |
2497 | type (20) which is an 8 byte structure. The first field of the class | |
2498 | struct is Adat, an integer, starting at structure offset 0 and | |
2499 | occupying 32 bits. | |
2500 | ||
2501 | The second field in the class struct is not explicitly defined by the | |
2502 | C++ class definition but is implied by the fact that the class | |
2503 | contains a virtual method. This field is the vtable pointer. The | |
2504 | name of the vtable pointer field starts with $vf and continues with a | |
2505 | type reference to the class it is part of. In this example the type | |
2506 | reference for class A is 20 so the name of its vtable pointer field is | |
2507 | $vf20, followed by the usual colon. | |
2508 | ||
2509 | Next there is a type definition for the vtable pointer type (21). | |
2510 | This is in turn defined as a pointer to another new type (22). | |
2511 | ||
2512 | Type 22 is the vtable itself, which is defined as an array, indexed by | |
6aa83a79 JG |
2513 | a range of integers between 0 and 1, and whose elements are of type |
2514 | 17. Type 17 was the vtable record type defined by the boilerplate C++ | |
2515 | type definitions, as shown earlier. | |
e505224d PB |
2516 | |
2517 | The bit offset of the vtable pointer field is 32. The number of bits | |
2518 | in the field are not specified when the field is a vtable pointer. | |
2519 | ||
2520 | Next is the method definition for the virtual member function A_virt. | |
2521 | Its description starts out using the same format as the non-virtual | |
2522 | member functions described above, except instead of a dot after the | |
2523 | `A' there is an asterisk, indicating that the function is virtual. | |
2524 | Since is is virtual some addition information is appended to the end | |
2525 | of the method description. | |
2526 | ||
2527 | The first number represents the vtable index of the method. This is a | |
2528 | 32 bit unsigned number with the high bit set, followed by a | |
2529 | semi-colon. | |
2530 | ||
2531 | The second number is a type reference to the first base class in the | |
2532 | inheritence hierarchy defining the virtual member function. In this | |
2533 | case the class stab describes a base class so the virtual function is | |
2534 | not overriding any other definition of the method. Therefore the | |
2535 | reference is to the type number of the class that the stab is | |
2536 | describing (20). | |
2537 | ||
2538 | This is followed by three semi-colons. One marks the end of the | |
2539 | current sub-section, one marks the end of the method field, and the | |
2540 | third marks the end of the struct definition. | |
2541 | ||
2542 | For classes containing virtual functions the very last section of the | |
2543 | string part of the stab holds a type reference to the first base | |
2544 | class. This is preceeded by `~%' and followed by a final semi-colon. | |
2545 | ||
899bafeb | 2546 | @display |
e505224d | 2547 | .stabs "class_name(A):type_def(20)=sym_desc(struct)struct_bytes(8) |
139741da RP |
2548 | field_name(Adat):type_ref(int),bit_offset(0),field_bits(32); |
2549 | field_name(A virt func ptr):type_def(21)=type_desc(ptr to)type_def(22)= | |
6aa83a79 JG |
2550 | sym_desc(array)index_type_ref(range of int from 0 to 1); |
2551 | elem_type_ref(vtbl elem type), | |
139741da RP |
2552 | bit_offset(32); |
2553 | meth_name(A_virt)::typedef(23)=sym_desc(method)returning(int); | |
2554 | :arg_type(int),protection(public)normal(yes)virtual(yes) | |
2555 | vtable_index(1);class_first_defining(A);;;~%first_base(A);", | |
2556 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 2557 | @end display |
e505224d | 2558 | |
3d4cf720 | 2559 | @c FIXME: bogus line break. |
899bafeb | 2560 | @example |
3d4cf720 JK |
2561 | .stabs "A:t20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32; |
2562 | A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0 | |
612dbd4c | 2563 | @end example |
e505224d | 2564 | |
2dd00294 JG |
2565 | @node Inheritence |
2566 | @section Inheritence | |
e505224d PB |
2567 | |
2568 | Stabs describing C++ derived classes include additional sections that | |
2569 | describe the inheritence hierarchy of the class. A derived class stab | |
2570 | also encodes the number of base classes. For each base class it tells | |
2571 | if the base class is virtual or not, and if the inheritence is private | |
2572 | or public. It also gives the offset into the object of the portion of | |
2573 | the object corresponding to each base class. | |
2574 | ||
2575 | This additional information is embeded in the class stab following the | |
2576 | number of bytes in the struct. First the number of base classes | |
2577 | appears bracketed by an exclamation point and a comma. | |
2578 | ||
2579 | Then for each base type there repeats a series: two digits, a number, | |
2580 | a comma, another number, and a semi-colon. | |
2581 | ||
2582 | The first of the two digits is 1 if the base class is virtual and 0 if | |
2583 | not. The second digit is 2 if the derivation is public and 0 if not. | |
2584 | ||
2585 | The number following the first two digits is the offset from the start | |
2586 | of the object to the part of the object pertaining to the base class. | |
2587 | ||
2588 | After the comma, the second number is a type_descriptor for the base | |
2589 | type. Finally a semi-colon ends the series, which repeats for each | |
2590 | base class. | |
2591 | ||
2592 | The source below defines three base classes A, B, and C and the | |
2593 | derived class D. | |
2594 | ||
2595 | ||
2596 | @example | |
2597 | class A @{ | |
2598 | public: | |
139741da RP |
2599 | int Adat; |
2600 | virtual int A_virt (int arg) @{ return arg; @}; | |
e505224d PB |
2601 | @}; |
2602 | ||
2603 | class B @{ | |
2604 | public: | |
139741da RP |
2605 | int B_dat; |
2606 | virtual int B_virt (int arg) @{return arg; @}; | |
e505224d PB |
2607 | @}; |
2608 | ||
2609 | class C @{ | |
2610 | public: | |
139741da RP |
2611 | int Cdat; |
2612 | virtual int C_virt (int arg) @{return arg; @}; | |
e505224d PB |
2613 | @}; |
2614 | ||
2615 | class D : A, virtual B, public C @{ | |
2616 | public: | |
139741da RP |
2617 | int Ddat; |
2618 | virtual int A_virt (int arg ) @{ return arg+1; @}; | |
2619 | virtual int B_virt (int arg) @{ return arg+2; @}; | |
2620 | virtual int C_virt (int arg) @{ return arg+3; @}; | |
2621 | virtual int D_virt (int arg) @{ return arg; @}; | |
e505224d PB |
2622 | @}; |
2623 | @end example | |
2624 | ||
2625 | Class stabs similar to the ones described earlier are generated for | |
2626 | each base class. | |
2627 | ||
5bc927fb RP |
2628 | @c FIXME!!! the linebreaks in the following example probably make the |
2629 | @c examples literally unusable, but I don't know any other way to get | |
2630 | @c them on the page. | |
63cef7d7 JK |
2631 | @c One solution would be to put some of the type definitions into |
2632 | @c separate stabs, even if that's not exactly what the compiler actually | |
2633 | @c emits. | |
899bafeb | 2634 | @smallexample |
5bc927fb RP |
2635 | .stabs "A:T20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32; |
2636 | A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0 | |
e505224d | 2637 | |
5bc927fb RP |
2638 | .stabs "B:Tt25=s8Bdat:1,0,32;$vf25:21,32;B_virt::26=##1; |
2639 | :i;2A*-2147483647;25;;;~%25;",128,0,0,0 | |
e505224d | 2640 | |
5bc927fb RP |
2641 | .stabs "C:Tt28=s8Cdat:1,0,32;$vf28:21,32;C_virt::29=##1; |
2642 | :i;2A*-2147483647;28;;;~%28;",128,0,0,0 | |
899bafeb | 2643 | @end smallexample |
e505224d PB |
2644 | |
2645 | In the stab describing derived class D below, the information about | |
2646 | the derivation of this class is encoded as follows. | |
2647 | ||
899bafeb | 2648 | @display |
e505224d | 2649 | .stabs "derived_class_name:symbol_descriptors(struct tag&type)= |
139741da RP |
2650 | type_descriptor(struct)struct_bytes(32)!num_bases(3), |
2651 | base_virtual(no)inheritence_public(no)base_offset(0), | |
2652 | base_class_type_ref(A); | |
2653 | base_virtual(yes)inheritence_public(no)base_offset(NIL), | |
2654 | base_class_type_ref(B); | |
2655 | base_virtual(no)inheritence_public(yes)base_offset(64), | |
2656 | base_class_type_ref(C); @dots{} | |
899bafeb | 2657 | @end display |
139741da | 2658 | |
5bc927fb | 2659 | @c FIXME! fake linebreaks. |
899bafeb | 2660 | @smallexample |
5bc927fb RP |
2661 | .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat: |
2662 | 1,160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt: | |
2663 | :32:i;2A*-2147483647;25;;C_virt::32:i;2A*-2147483647; | |
2664 | 28;;D_virt::32:i;2A*-2147483646;31;;;~%20;",128,0,0,0 | |
899bafeb | 2665 | @end smallexample |
e505224d | 2666 | |
2dd00294 | 2667 | @node Virtual Base Classes |
e505224d PB |
2668 | @section Virtual Base Classes |
2669 | ||
2670 | A derived class object consists of a concatination in memory of the | |
2671 | data areas defined by each base class, starting with the leftmost and | |
2672 | ending with the rightmost in the list of base classes. The exception | |
2673 | to this rule is for virtual inheritence. In the example above, class | |
2674 | D inherits virtually from base class B. This means that an instance | |
2675 | of a D object will not contain it's own B part but merely a pointer to | |
2676 | a B part, known as a virtual base pointer. | |
2677 | ||
2678 | In a derived class stab, the base offset part of the derivation | |
2679 | information, described above, shows how the base class parts are | |
2680 | ordered. The base offset for a virtual base class is always given as | |
2681 | 0. Notice that the base offset for B is given as 0 even though B is | |
2682 | not the first base class. The first base class A starts at offset 0. | |
2683 | ||
2684 | The field information part of the stab for class D describes the field | |
2685 | which is the pointer to the virtual base class B. The vbase pointer | |
2686 | name is $vb followed by a type reference to the virtual base class. | |
2687 | Since the type id for B in this example is 25, the vbase pointer name | |
2688 | is $vb25. | |
2689 | ||
5bc927fb | 2690 | @c FIXME!! fake linebreaks below |
899bafeb | 2691 | @smallexample |
5bc927fb RP |
2692 | .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:1, |
2693 | 160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt::32:i; | |
2694 | 2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;28;;D_virt: | |
2695 | :32:i;2A*-2147483646;31;;;~%20;",128,0,0,0 | |
899bafeb | 2696 | @end smallexample |
e505224d PB |
2697 | |
2698 | Following the name and a semicolon is a type reference describing the | |
2699 | type of the virtual base class pointer, in this case 24. Type 24 was | |
c2dc518b | 2700 | defined earlier as the type of the B class `this` pointer. The |
e505224d PB |
2701 | `this' pointer for a class is a pointer to the class type. |
2702 | ||
899bafeb | 2703 | @example |
c2dc518b | 2704 | .stabs "this:P24=*25=xsB:",64,0,0,8 |
899bafeb | 2705 | @end example |
e505224d PB |
2706 | |
2707 | Finally the field offset part of the vbase pointer field description | |
2708 | shows that the vbase pointer is the first field in the D object, | |
2709 | before any data fields defined by the class. The layout of a D class | |
2710 | object is a follows, Adat at 0, the vtable pointer for A at 32, Cdat | |
2711 | at 64, the vtable pointer for C at 96, the virtual ase pointer for B | |
2712 | at 128, and Ddat at 160. | |
2713 | ||
2714 | ||
899bafeb | 2715 | @node Static Members |
e505224d PB |
2716 | @section Static Members |
2717 | ||
446e5d80 JG |
2718 | The data area for a class is a concatenation of the space used by the |
2719 | data members of the class. If the class has virtual methods, a vtable | |
e505224d | 2720 | pointer follows the class data. The field offset part of each field |
446e5d80 | 2721 | description in the class stab shows this ordering. |
e505224d | 2722 | |
446e5d80 | 2723 | << How is this reflected in stabs? See Cygnus bug #677 for some info. >> |
e505224d | 2724 | |
899bafeb | 2725 | @node Example2.c |
e505224d PB |
2726 | @appendix Example2.c - source code for extended example |
2727 | ||
2728 | @example | |
2729 | 1 char g_foo = 'c'; | |
2730 | 2 register int g_bar asm ("%g5"); | |
2731 | 3 static int s_g_repeat = 2; | |
2732 | 4 int (*g_pf)(); | |
2733 | 5 | |
2734 | 6 struct s_tag @{ | |
2735 | 7 int s_int; | |
2736 | 8 float s_float; | |
2737 | 9 char s_char_vec[8]; | |
2738 | 10 struct s_tag* s_next; | |
2739 | 11 @} g_an_s; | |
2740 | 12 | |
2741 | 13 typedef struct s_tag s_typedef; | |
2742 | 14 | |
2743 | 15 char char_vec[3] = @{'a','b','c'@}; | |
2744 | 16 | |
2745 | 17 main (argc, argv) | |
2746 | 18 int argc; | |
2747 | 19 char* argv[]; | |
2748 | 20 @{ | |
2749 | 21 static float s_flap; | |
139741da RP |
2750 | 22 int times; |
2751 | 23 for (times=0; times < s_g_repeat; times++)@{ | |
2752 | 24 int inner; | |
2753 | 25 printf ("Hello world\n"); | |
2754 | 26 @} | |
e505224d PB |
2755 | 27 @}; |
2756 | 28 | |
2757 | 29 enum e_places @{first,second=3,last@}; | |
2758 | 30 | |
2759 | 31 static s_proc (s_arg, s_ptr_arg, char_vec) | |
2760 | 32 s_typedef s_arg; | |
2761 | 33 s_typedef* s_ptr_arg; | |
2762 | 34 char* char_vec; | |
2763 | 35 @{ | |
2764 | 36 union u_tag @{ | |
2765 | 37 int u_int; | |
2766 | 38 float u_float; | |
2767 | 39 char* u_char; | |
2768 | 40 @} an_u; | |
2769 | 41 @} | |
2770 | 42 | |
2771 | 43 | |
2772 | @end example | |
2773 | ||
899bafeb | 2774 | @node Example2.s |
e505224d PB |
2775 | @appendix Example2.s - assembly code for extended example |
2776 | ||
2777 | @example | |
2778 | 1 gcc2_compiled.: | |
2779 | 2 .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 | |
2780 | 3 .stabs "example2.c",100,0,0,Ltext0 | |
139741da | 2781 | 4 .text |
e505224d PB |
2782 | 5 Ltext0: |
2783 | 6 .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 | |
2784 | 7 .stabs "char:t2=r2;0;127;",128,0,0,0 | |
2785 | 8 .stabs "long int:t3=r1;-2147483648;2147483647;",128,0,0,0 | |
2786 | 9 .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0 | |
2787 | 10 .stabs "long unsigned int:t5=r1;0;-1;",128,0,0,0 | |
2788 | 11 .stabs "short int:t6=r1;-32768;32767;",128,0,0,0 | |
2789 | 12 .stabs "long long int:t7=r1;0;-1;",128,0,0,0 | |
2790 | 13 .stabs "short unsigned int:t8=r1;0;65535;",128,0,0,0 | |
2791 | 14 .stabs "long long unsigned int:t9=r1;0;-1;",128,0,0,0 | |
2792 | 15 .stabs "signed char:t10=r1;-128;127;",128,0,0,0 | |
2793 | 16 .stabs "unsigned char:t11=r1;0;255;",128,0,0,0 | |
2794 | 17 .stabs "float:t12=r1;4;0;",128,0,0,0 | |
2795 | 18 .stabs "double:t13=r1;8;0;",128,0,0,0 | |
2796 | 19 .stabs "long double:t14=r1;8;0;",128,0,0,0 | |
2797 | 20 .stabs "void:t15=15",128,0,0,0 | |
2798 | 21 .stabs "g_foo:G2",32,0,0,0 | |
139741da RP |
2799 | 22 .global _g_foo |
2800 | 23 .data | |
e505224d | 2801 | 24 _g_foo: |
139741da | 2802 | 25 .byte 99 |
e505224d | 2803 | 26 .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat |
139741da | 2804 | 27 .align 4 |
e505224d | 2805 | 28 _s_g_repeat: |
139741da | 2806 | 29 .word 2 |
5bc927fb RP |
2807 | @c FIXME! fake linebreak in line 30 |
2808 | 30 .stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;s_char_vec: | |
2809 | 17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0 | |
e505224d PB |
2810 | 31 .stabs "s_typedef:t16",128,0,0,0 |
2811 | 32 .stabs "char_vec:G19=ar1;0;2;2",32,0,0,0 | |
139741da RP |
2812 | 33 .global _char_vec |
2813 | 34 .align 4 | |
e505224d | 2814 | 35 _char_vec: |
139741da RP |
2815 | 36 .byte 97 |
2816 | 37 .byte 98 | |
2817 | 38 .byte 99 | |
2818 | 39 .reserve _s_flap.0,4,"bss",4 | |
2819 | 40 .text | |
2820 | 41 .align 4 | |
e505224d | 2821 | 42 LC0: |
139741da RP |
2822 | 43 .ascii "Hello world\12\0" |
2823 | 44 .align 4 | |
2824 | 45 .global _main | |
2825 | 46 .proc 1 | |
e505224d PB |
2826 | 47 _main: |
2827 | 48 .stabn 68,0,20,LM1 | |
2828 | 49 LM1: | |
139741da RP |
2829 | 50 !#PROLOGUE# 0 |
2830 | 51 save %sp,-144,%sp | |
2831 | 52 !#PROLOGUE# 1 | |
2832 | 53 st %i0,[%fp+68] | |
2833 | 54 st %i1,[%fp+72] | |
2834 | 55 call ___main,0 | |
2835 | 56 nop | |
e505224d PB |
2836 | 57 LBB2: |
2837 | 58 .stabn 68,0,23,LM2 | |
2838 | 59 LM2: | |
139741da | 2839 | 60 st %g0,[%fp-20] |
e505224d | 2840 | 61 L2: |
139741da RP |
2841 | 62 sethi %hi(_s_g_repeat),%o0 |
2842 | 63 ld [%fp-20],%o1 | |
2843 | 64 ld [%o0+%lo(_s_g_repeat)],%o0 | |
2844 | 65 cmp %o1,%o0 | |
2845 | 66 bge L3 | |
2846 | 67 nop | |
e505224d PB |
2847 | 68 LBB3: |
2848 | 69 .stabn 68,0,25,LM3 | |
2849 | 70 LM3: | |
139741da RP |
2850 | 71 sethi %hi(LC0),%o1 |
2851 | 72 or %o1,%lo(LC0),%o0 | |
2852 | 73 call _printf,0 | |
2853 | 74 nop | |
e505224d PB |
2854 | 75 .stabn 68,0,26,LM4 |
2855 | 76 LM4: | |
2856 | 77 LBE3: | |
2857 | 78 .stabn 68,0,23,LM5 | |
2858 | 79 LM5: | |
2859 | 80 L4: | |
139741da RP |
2860 | 81 ld [%fp-20],%o0 |
2861 | 82 add %o0,1,%o1 | |
2862 | 83 st %o1,[%fp-20] | |
2863 | 84 b,a L2 | |
e505224d PB |
2864 | 85 L3: |
2865 | 86 .stabn 68,0,27,LM6 | |
2866 | 87 LM6: | |
2867 | 88 LBE2: | |
2868 | 89 .stabn 68,0,27,LM7 | |
2869 | 90 LM7: | |
2870 | 91 L1: | |
139741da RP |
2871 | 92 ret |
2872 | 93 restore | |
e505224d PB |
2873 | 94 .stabs "main:F1",36,0,0,_main |
2874 | 95 .stabs "argc:p1",160,0,0,68 | |
2875 | 96 .stabs "argv:p20=*21=*2",160,0,0,72 | |
2876 | 97 .stabs "s_flap:V12",40,0,0,_s_flap.0 | |
2877 | 98 .stabs "times:1",128,0,0,-20 | |
2878 | 99 .stabn 192,0,0,LBB2 | |
2879 | 100 .stabs "inner:1",128,0,0,-24 | |
2880 | 101 .stabn 192,0,0,LBB3 | |
2881 | 102 .stabn 224,0,0,LBE3 | |
2882 | 103 .stabn 224,0,0,LBE2 | |
2883 | 104 .stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0 | |
5bc927fb RP |
2884 | @c FIXME: fake linebreak in line 105 |
2885 | 105 .stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;", | |
2886 | 128,0,0,0 | |
139741da RP |
2887 | 106 .align 4 |
2888 | 107 .proc 1 | |
e505224d PB |
2889 | 108 _s_proc: |
2890 | 109 .stabn 68,0,35,LM8 | |
2891 | 110 LM8: | |
139741da RP |
2892 | 111 !#PROLOGUE# 0 |
2893 | 112 save %sp,-120,%sp | |
2894 | 113 !#PROLOGUE# 1 | |
2895 | 114 mov %i0,%o0 | |
2896 | 115 st %i1,[%fp+72] | |
2897 | 116 st %i2,[%fp+76] | |
e505224d PB |
2898 | 117 LBB4: |
2899 | 118 .stabn 68,0,41,LM9 | |
2900 | 119 LM9: | |
2901 | 120 LBE4: | |
2902 | 121 .stabn 68,0,41,LM10 | |
2903 | 122 LM10: | |
2904 | 123 L5: | |
139741da RP |
2905 | 124 ret |
2906 | 125 restore | |
e505224d PB |
2907 | 126 .stabs "s_proc:f1",36,0,0,_s_proc |
2908 | 127 .stabs "s_arg:p16",160,0,0,0 | |
2909 | 128 .stabs "s_ptr_arg:p18",160,0,0,72 | |
2910 | 129 .stabs "char_vec:p21",160,0,0,76 | |
2911 | 130 .stabs "an_u:23",128,0,0,-20 | |
2912 | 131 .stabn 192,0,0,LBB4 | |
2913 | 132 .stabn 224,0,0,LBE4 | |
2914 | 133 .stabs "g_bar:r1",64,0,0,5 | |
2915 | 134 .stabs "g_pf:G24=*25=f1",32,0,0,0 | |
139741da | 2916 | 135 .common _g_pf,4,"bss" |
e505224d | 2917 | 136 .stabs "g_an_s:G16",32,0,0,0 |
139741da | 2918 | 137 .common _g_an_s,20,"bss" |
e505224d PB |
2919 | @end example |
2920 | ||
3d4cf720 JK |
2921 | @node Stab Types |
2922 | @appendix Values for the Stab Type Field | |
e505224d | 2923 | |
3d4cf720 JK |
2924 | These are all the possible values for the stab type field, for |
2925 | @code{a.out} files. This does not apply to XCOFF. | |
e505224d | 2926 | |
3d4cf720 JK |
2927 | The following types are used by the linker and assembler; there is |
2928 | nothing stabs-specific about them. Since this document does not attempt | |
2929 | to describe aspects of object file format other than the debugging | |
2930 | format, no details are given. | |
e505224d | 2931 | |
3d4cf720 JK |
2932 | @c Try to get most of these to fit on a single line. |
2933 | @iftex | |
2934 | @tableindent=1.5in | |
2935 | @end iftex | |
e505224d | 2936 | |
3d4cf720 JK |
2937 | @table @code |
2938 | @item 0x0 N_UNDF | |
2939 | Undefined symbol | |
e505224d | 2940 | |
3d4cf720 JK |
2941 | @item 0x2 N_ABS |
2942 | File scope absolute symbol | |
e505224d | 2943 | |
3d4cf720 JK |
2944 | @item 0x3 N_ABS | N_EXT |
2945 | External absolute symbol | |
2946 | ||
2947 | @item 0x4 N_TEXT | |
2948 | File scope text symbol | |
2949 | ||
2950 | @item 0x5 N_TEXT | N_EXT | |
2951 | External text symbol | |
2952 | ||
2953 | @item 0x6 N_DATA | |
2954 | File scope data symbol | |
2955 | ||
2956 | @item 0x7 N_DATA | N_EXT | |
2957 | External data symbol | |
2958 | ||
2959 | @item 0x8 N_BSS | |
2960 | File scope BSS symbol | |
2961 | ||
2962 | @item 0x9 N_BSS | N_EXT | |
2963 | External BSS symbol | |
2964 | ||
2965 | @item 0x0c N_FN_SEQ | |
2966 | Same as N_FN, for Sequent compilers | |
2967 | ||
2968 | @item 0x0a N_INDR | |
2969 | Symbol is indirected to another symbol | |
2970 | ||
2971 | @item 0x12 N_COMM | |
2972 | Common sym -- visable after shared lib dynamic link | |
2973 | ||
2974 | @item 0x14 N_SETA | |
2975 | Absolute set element | |
2976 | ||
2977 | @item 0x16 N_SETT | |
2978 | Text segment set element | |
2979 | ||
2980 | @item 0x18 N_SETD | |
2981 | Data segment set element | |
2982 | ||
2983 | @item 0x1a N_SETB | |
2984 | BSS segment set element | |
2985 | ||
2986 | @item 0x1c N_SETV | |
2987 | Pointer to set vector | |
2988 | ||
2989 | @item 0x1e N_WARNING | |
2990 | Print a warning message during linking | |
2991 | ||
2992 | @item 0x1f N_FN | |
2993 | File name of a .o file | |
2994 | @end table | |
2995 | ||
2996 | The following symbol types indicate that this is a stab. This is the | |
2997 | full list of stab numbers, including stab types that are used in | |
2998 | languages other than C. | |
2999 | ||
3000 | @table @code | |
3001 | @item 0x20 N_GSYM | |
3002 | Global symbol, @xref{N_GSYM}. | |
3003 | ||
3004 | @item 0x22 N_FNAME | |
3005 | Function name (for BSD Fortran), @xref{N_FNAME}. | |
3006 | ||
3007 | @item 0x24 N_FUN | |
3008 | Function name or text segment variable for C, @xref{N_FUN}. | |
3009 | ||
3010 | @item 0x26 N_STSYM | |
3011 | Static symbol (data segment variable with internal linkage), @xref{N_STSYM}. | |
3012 | ||
3013 | @item 0x28 N_LCSYM | |
3014 | .lcomm symbol (BSS segment variable with internal linkage), @xref{N_LCSYM}. | |
3015 | ||
3016 | @item 0x2a N_MAIN | |
3017 | Name of main routine (not used in C), @xref{N_MAIN}. | |
3018 | ||
ded6bcab JK |
3019 | @c FIXME: discuss this in the main body of the text where we talk about |
3020 | @c using N_FUN for variables. | |
3021 | @item 0x2c N_ROSYM | |
3022 | Read-only data symbol (Solaris2). Most systems use N_FUN for this. | |
3023 | ||
3d4cf720 JK |
3024 | @item 0x30 N_PC |
3025 | Global symbol (for Pascal), @xref{N_PC}. | |
3026 | ||
3027 | @item 0x32 N_NSYMS | |
3028 | Number of symbols (according to Ultrix V4.0), @xref{N_NSYMS}. | |
3029 | ||
3030 | @item 0x34 N_NOMAP | |
3031 | No DST map for sym (according to Ultrix V4.0), @xref{N_NOMAP}. | |
3032 | ||
ded6bcab JK |
3033 | @c FIXME: describe this solaris feature in the body of the text (see |
3034 | @c comments in include/aout/stab.def). | |
3035 | @item 0x38 N_OBJ | |
3036 | Object file (Solaris2). | |
3037 | ||
3038 | @c See include/aout/stab.def for (a little) more info. | |
3039 | @item 0x3c N_OPT | |
3040 | Debugger options (Solaris2). | |
3041 | ||
3d4cf720 JK |
3042 | @item 0x40 N_RSYM |
3043 | Register variable, @xref{N_RSYM}. | |
3044 | ||
3045 | @item 0x42 N_M2C | |
3046 | Modula-2 compilation unit, @xref{N_M2C}. | |
3047 | ||
3048 | @item 0x44 N_SLINE | |
3049 | Line number in text segment, @xref{Line Numbers}. | |
3050 | ||
3051 | @item 0x46 N_DSLINE | |
3052 | Line number in data segment, @xref{Line Numbers}. | |
3053 | ||
3054 | @item 0x48 N_BSLINE | |
3055 | Line number in bss segment, @xref{Line Numbers}. | |
3056 | ||
3057 | @item 0x48 N_BROWS | |
3058 | Sun source code browser, path to .cb file, @xref{N_BROWS}. | |
3059 | ||
3060 | @item 0x4a N_DEFD | |
3061 | Gnu Modula2 definition module dependency, @xref{N_DEFD}. | |
3062 | ||
ded6bcab JK |
3063 | @item 0x4c N_FLINE |
3064 | Function start/body/end line numbers (Solaris2). | |
3065 | ||
3d4cf720 JK |
3066 | @item 0x50 N_EHDECL |
3067 | Gnu C++ exception variable, @xref{N_EHDECL}. | |
3068 | ||
3069 | @item 0x50 N_MOD2 | |
3070 | Modula2 info "for imc" (according to Ultrix V4.0), @xref{N_MOD2}. | |
3071 | ||
3072 | @item 0x54 N_CATCH | |
3073 | Gnu C++ "catch" clause, @xref{N_CATCH}. | |
3074 | ||
3075 | @item 0x60 N_SSYM | |
3076 | Structure of union element, @xref{N_SSYM}. | |
3077 | ||
ded6bcab JK |
3078 | @item 0x62 N_ENDM |
3079 | Last stab for module (Solaris2). | |
3080 | ||
3d4cf720 JK |
3081 | @item 0x64 N_SO |
3082 | Path and name of source file , @xref{Source Files}. | |
3083 | ||
3084 | @item 0x80 N_LSYM | |
3085 | Automatic var in the stack or type definition, @xref{N_LSYM}, @xref{Typedefs}. | |
3086 | ||
3087 | @item 0x82 N_BINCL | |
3088 | Beginning of an include file (Sun only), @xref{Source Files}. | |
3089 | ||
3090 | @item 0x84 N_SOL | |
f0f4b04e | 3091 | Name of include file, @xref{Source Files}. |
3d4cf720 JK |
3092 | |
3093 | @item 0xa0 N_PSYM | |
3094 | Parameter variable, @xref{Parameters}. | |
3095 | ||
3096 | @item 0xa2 N_EINCL | |
3097 | End of an include file, @xref{Source Files}. | |
3098 | ||
3099 | @item 0xa4 N_ENTRY | |
3100 | Alternate entry point, @xref{N_ENTRY}. | |
3101 | ||
3102 | @item 0xc0 N_LBRAC | |
f0f4b04e | 3103 | Beginning of a lexical block, @xref{Block Structure}. |
3d4cf720 JK |
3104 | |
3105 | @item 0xc2 N_EXCL | |
3106 | Place holder for a deleted include file, @xref{Source Files}. | |
3107 | ||
3108 | @item 0xc4 N_SCOPE | |
3109 | Modula2 scope information (Sun linker), @xref{N_SCOPE}. | |
3110 | ||
3111 | @item 0xe0 N_RBRAC | |
f0f4b04e | 3112 | End of a lexical block, @xref{Block Structure}. |
3d4cf720 JK |
3113 | |
3114 | @item 0xe2 N_BCOMM | |
807e8368 | 3115 | Begin named common block, @xref{Common Blocks}. |
3d4cf720 JK |
3116 | |
3117 | @item 0xe4 N_ECOMM | |
807e8368 | 3118 | End named common block, @xref{Common Blocks}. |
3d4cf720 JK |
3119 | |
3120 | @item 0xe8 N_ECOML | |
807e8368 | 3121 | Member of a common block, @xref{Common Blocks}. |
3d4cf720 | 3122 | |
ded6bcab JK |
3123 | @c FIXME: How does this really work? Move it to main body of document. |
3124 | @item 0xea N_WITH | |
3125 | Pascal @code{with} statement: type,,0,0,offset (Solaris2). | |
3126 | ||
3d4cf720 | 3127 | @item 0xf0 N_NBTEXT |
ded6bcab | 3128 | Gould non-base registers, @xref{Gould}. |
3d4cf720 JK |
3129 | |
3130 | @item 0xf2 N_NBDATA | |
ded6bcab | 3131 | Gould non-base registers, @xref{Gould}. |
3d4cf720 JK |
3132 | |
3133 | @item 0xf4 N_NBBSS | |
ded6bcab | 3134 | Gould non-base registers, @xref{Gould}. |
3d4cf720 JK |
3135 | |
3136 | @item 0xf6 N_NBSTS | |
ded6bcab | 3137 | Gould non-base registers, @xref{Gould}. |
3d4cf720 JK |
3138 | |
3139 | @item 0xf8 N_NBLCS | |
ded6bcab | 3140 | Gould non-base registers, @xref{Gould}. |
3d4cf720 JK |
3141 | @end table |
3142 | ||
3143 | @c Restore the default table indent | |
3144 | @iftex | |
3145 | @tableindent=.8in | |
3146 | @end iftex | |
e505224d | 3147 | |
8c59ee11 | 3148 | @node Symbol Descriptors |
3d4cf720 | 3149 | @appendix Table of Symbol Descriptors |
e505224d | 3150 | |
ed9708e2 | 3151 | @c Please keep this alphabetical |
497e44a5 | 3152 | @table @code |
466bdeb2 JK |
3153 | @c In TeX, this looks great, digit is in italics. But makeinfo insists |
3154 | @c on putting it in `', not realizing that @var should override @code. | |
3155 | @c I don't know of any way to make makeinfo do the right thing. Seems | |
3156 | @c like a makeinfo bug to me. | |
3157 | @item @var{digit} | |
8c59ee11 JK |
3158 | @itemx ( |
3159 | @itemx - | |
497e44a5 JK |
3160 | Local variable, @xref{Automatic variables}. |
3161 | ||
6897f9ec JK |
3162 | @item a |
3163 | Parameter passed by reference in register, @xref{Parameters}. | |
3164 | ||
3165 | @item c | |
3166 | Constant, @xref{Constants}. | |
3167 | ||
ed9708e2 | 3168 | @item C |
8c59ee11 JK |
3169 | Conformant array bound (Pascal, maybe other languages), |
3170 | @xref{Parameters}. Name of a caught exception (GNU C++). These can be | |
3171 | distinguished because the latter uses N_CATCH and the former uses | |
3172 | another symbol type. | |
6897f9ec JK |
3173 | |
3174 | @item d | |
3175 | Floating point register variable, @xref{Register variables}. | |
3176 | ||
3177 | @item D | |
3178 | Parameter in floating point register, @xref{Parameters}. | |
ed9708e2 | 3179 | |
497e44a5 | 3180 | @item f |
6897f9ec | 3181 | Static function, @xref{Procedures}. |
497e44a5 JK |
3182 | |
3183 | @item F | |
3184 | Global function, @xref{Procedures}. | |
3185 | ||
497e44a5 JK |
3186 | @item G |
3187 | Global variable, @xref{Global Variables}. | |
3188 | ||
ed9708e2 JK |
3189 | @item i |
3190 | @xref{Parameters}. | |
3191 | ||
6897f9ec JK |
3192 | @item I |
3193 | Internal (nested) procedure, @xref{Procedures}. | |
3194 | ||
3195 | @item J | |
3196 | Internal (nested) function, @xref{Procedures}. | |
3197 | ||
3198 | @item L | |
3199 | Label name (documented by AIX, no further information known). | |
3200 | ||
3201 | @item m | |
3202 | Module, @xref{Procedures}. | |
3203 | ||
ed9708e2 | 3204 | @item p |
8c59ee11 | 3205 | Argument list parameter, @xref{Parameters}. |
ed9708e2 JK |
3206 | |
3207 | @item pP | |
3208 | @xref{Parameters}. | |
3209 | ||
3210 | @item pF | |
8c59ee11 | 3211 | FORTRAN Function parameter, @xref{Parameters}. |
ed9708e2 JK |
3212 | |
3213 | @item P | |
1a8b5668 JK |
3214 | Unfortunately, three separate meanings have been independently invented |
3215 | for this symbol descriptor. At least the GNU and Sun uses can be | |
3216 | distinguished by the symbol type. Global Procedure (AIX) (symbol type | |
3217 | used unknown), @xref{Procedures}. Register parameter (GNU) (symbol type | |
3218 | N_PSYM), @xref{Parameters}. Prototype of function referenced by this | |
3219 | file (Sun acc) (symbol type N_FUN). | |
6897f9ec JK |
3220 | |
3221 | @item Q | |
3222 | Static Procedure, @xref{Procedures}. | |
3223 | ||
3224 | @item R | |
ed9708e2 JK |
3225 | Register parameter @xref{Parameters}. |
3226 | ||
497e44a5 JK |
3227 | @item r |
3228 | Register variable, @xref{Register variables}. | |
3229 | ||
3230 | @item S | |
3231 | Static file scope variable @xref{Initialized statics}, | |
1b5c6c05 | 3232 | @xref{Un-initialized statics}. |
497e44a5 | 3233 | |
ed9708e2 JK |
3234 | @item t |
3235 | Type name, @xref{Typedefs}. | |
3236 | ||
3237 | @item T | |
8c59ee11 | 3238 | enumeration, struct or union tag, @xref{Typedefs}. |
ed9708e2 JK |
3239 | |
3240 | @item v | |
8c59ee11 | 3241 | Parameter passed by reference, @xref{Parameters}. |
ed9708e2 | 3242 | |
497e44a5 JK |
3243 | @item V |
3244 | Static procedure scope variable @xref{Initialized statics}, | |
1b5c6c05 | 3245 | @xref{Un-initialized statics}. |
497e44a5 | 3246 | |
6897f9ec JK |
3247 | @item x |
3248 | Conformant array, @xref{Parameters}. | |
3249 | ||
ed9708e2 JK |
3250 | @item X |
3251 | Function return variable, @xref{Parameters}. | |
497e44a5 | 3252 | @end table |
e505224d | 3253 | |
899bafeb | 3254 | @node Type Descriptors |
3d4cf720 | 3255 | @appendix Table of Type Descriptors |
e505224d | 3256 | |
6897f9ec | 3257 | @table @code |
8c59ee11 JK |
3258 | @item @var{digit} |
3259 | @itemx ( | |
3260 | Type reference, @xref{Stabs Format}. | |
3261 | ||
3262 | @item - | |
3263 | Reference to builtin type, @xref{Negative Type Numbers}. | |
3264 | ||
3265 | @item # | |
3266 | Method (C++), @xref{Cplusplus}. | |
6897f9ec JK |
3267 | |
3268 | @item * | |
8c59ee11 JK |
3269 | Pointer, @xref{Miscellaneous Types}. |
3270 | ||
3271 | @item & | |
3272 | Reference (C++). | |
6897f9ec JK |
3273 | |
3274 | @item @@ | |
8c59ee11 JK |
3275 | Type Attributes (AIX), @xref{Stabs Format}. Member (class and variable) |
3276 | type (GNU C++), @xref{Cplusplus}. | |
e505224d | 3277 | |
6897f9ec | 3278 | @item a |
8c59ee11 JK |
3279 | Array, @xref{Arrays}. |
3280 | ||
3281 | @item A | |
3282 | Open array, @xref{Arrays}. | |
3283 | ||
3284 | @item b | |
3285 | Pascal space type (AIX), @xref{Miscellaneous Types}. Builtin integer | |
3286 | type (Sun), @xref{Builtin Type Descriptors}. | |
3287 | ||
3288 | @item B | |
3289 | Volatile-qualified type, @xref{Miscellaneous Types}. | |
3290 | ||
3291 | @item c | |
3292 | Complex builtin type, @xref{Builtin Type Descriptors}. | |
3293 | ||
3294 | @item C | |
3295 | COBOL Picture type. See AIX documentation for details. | |
3296 | ||
3297 | @item d | |
3298 | File type, @xref{Miscellaneous Types}. | |
3299 | ||
3300 | @item D | |
3301 | N-dimensional dynamic array, @xref{Arrays}. | |
6897f9ec JK |
3302 | |
3303 | @item e | |
8c59ee11 JK |
3304 | Enumeration type, @xref{Enumerations}. |
3305 | ||
3306 | @item E | |
3307 | N-dimensional subarray, @xref{Arrays}. | |
6897f9ec JK |
3308 | |
3309 | @item f | |
a03f27c3 JK |
3310 | Function type, @xref{Function Types}. |
3311 | ||
3312 | @item F | |
3313 | Pascal function parameter, @xref{Function Types} | |
8c59ee11 JK |
3314 | |
3315 | @item g | |
3316 | Builtin floating point type, @xref{Builtin Type Descriptors}. | |
3317 | ||
3318 | @item G | |
3319 | COBOL Group. See AIX documentation for details. | |
3320 | ||
3321 | @item i | |
3322 | Imported type, @xref{Cross-references}. | |
3323 | ||
3324 | @item k | |
3325 | Const-qualified type, @xref{Miscellaneous Types}. | |
3326 | ||
3327 | @item K | |
3328 | COBOL File Descriptor. See AIX documentation for details. | |
3329 | ||
a03f27c3 JK |
3330 | @item M |
3331 | Multiple instance type, @xref{Miscellaneous Types}. | |
3332 | ||
8c59ee11 JK |
3333 | @item n |
3334 | String type, @xref{Strings}. | |
3335 | ||
3336 | @item N | |
3337 | Stringptr, @xref{Strings}. | |
3338 | ||
8c59ee11 JK |
3339 | @item o |
3340 | Opaque type, @xref{Typedefs}. | |
3341 | ||
a03f27c3 JK |
3342 | @item p |
3343 | Procedure, @xref{Function Types}. | |
3344 | ||
8c59ee11 JK |
3345 | @item P |
3346 | Packed array, @xref{Arrays}. | |
6897f9ec JK |
3347 | |
3348 | @item r | |
8c59ee11 JK |
3349 | Range type, @xref{Subranges}. |
3350 | ||
3351 | @item R | |
a03f27c3 JK |
3352 | Builtin floating type, @xref{Builtin Type Descriptors} (Sun). Pascal |
3353 | subroutine parameter, @xref{Function Types} (AIX). Detecting this | |
3354 | conflict is possible with careful parsing (hint: a Pascal subroutine | |
3355 | parameter type will always contain a comma, and a builtin type | |
3356 | descriptor never will). | |
6897f9ec JK |
3357 | |
3358 | @item s | |
8c59ee11 JK |
3359 | Structure type, @xref{Structures}. |
3360 | ||
3361 | @item S | |
3362 | Set type, @xref{Miscellaneous Types}. | |
6897f9ec JK |
3363 | |
3364 | @item u | |
8c59ee11 JK |
3365 | Union, @xref{Unions}. |
3366 | ||
3367 | @item v | |
3368 | Variant record. This is a Pascal and Modula-2 feature which is like a | |
3369 | union within a struct in C. See AIX documentation for details. | |
3370 | ||
3371 | @item w | |
3372 | Wide character, @xref{Builtin Type Descriptors}. | |
3373 | ||
3374 | @item x | |
3375 | Cross-reference, @xref{Cross-references}. | |
6897f9ec | 3376 | |
8c59ee11 JK |
3377 | @item z |
3378 | gstring, @xref{Strings}. | |
6897f9ec | 3379 | @end table |
e505224d | 3380 | |
899bafeb | 3381 | @node Expanded reference |
e505224d PB |
3382 | @appendix Expanded reference by stab type. |
3383 | ||
3d4cf720 | 3384 | @c FIXME: This appendix should go away, see N_PSYM or N_SO for an example. |
8c59ee11 | 3385 | |
3d4cf720 JK |
3386 | For a full list of stab types, and cross-references to where they are |
3387 | described, @xref{Stab Types}. This appendix just duplicates certain | |
3388 | information from the main body of this document; eventually the | |
3389 | information will all be in one place. | |
8c59ee11 | 3390 | |
e505224d PB |
3391 | Format of an entry: |
3392 | ||
3393 | The first line is the symbol type expressed in decimal, hexadecimal, | |
3394 | and as a #define (see devo/include/aout/stab.def). | |
3395 | ||
3396 | The second line describes the language constructs the symbol type | |
3397 | represents. | |
3398 | ||
3399 | The third line is the stab format with the significant stab fields | |
3400 | named and the rest NIL. | |
3401 | ||
3402 | Subsequent lines expand upon the meaning and possible values for each | |
3403 | significant stab field. # stands in for the type descriptor. | |
3404 | ||
3405 | Finally, any further information. | |
3406 | ||
899bafeb RP |
3407 | @menu |
3408 | * N_GSYM:: Global variable | |
3409 | * N_FNAME:: Function name (BSD Fortran) | |
3410 | * N_FUN:: C Function name or text segment variable | |
3411 | * N_STSYM:: Initialized static symbol | |
3412 | * N_LCSYM:: Uninitialized static symbol | |
3413 | * N_MAIN:: Name of main routine (not for C) | |
3414 | * N_PC:: Pascal global symbol | |
3415 | * N_NSYMS:: Number of symbols | |
3416 | * N_NOMAP:: No DST map | |
3417 | * N_RSYM:: Register variable | |
3418 | * N_M2C:: Modula-2 compilation unit | |
899bafeb RP |
3419 | * N_BROWS:: Path to .cb file for Sun source code browser |
3420 | * N_DEFD:: GNU Modula2 definition module dependency | |
3421 | * N_EHDECL:: GNU C++ exception variable | |
3422 | * N_MOD2:: Modula2 information "for imc" | |
3423 | * N_CATCH:: GNU C++ "catch" clause | |
3424 | * N_SSYM:: Structure or union element | |
899bafeb | 3425 | * N_LSYM:: Automatic variable |
899bafeb | 3426 | * N_ENTRY:: Alternate entry point |
899bafeb | 3427 | * N_SCOPE:: Modula2 scope information (Sun only) |
899bafeb RP |
3428 | * Gould:: non-base register symbols used on Gould systems |
3429 | * N_LENG:: Length of preceding entry | |
3430 | @end menu | |
3431 | ||
3432 | @node N_GSYM | |
139741da | 3433 | @section 32 - 0x20 - N_GYSM |
899bafeb RP |
3434 | |
3435 | @display | |
e505224d PB |
3436 | Global variable. |
3437 | ||
3438 | .stabs "name", N_GSYM, NIL, NIL, NIL | |
899bafeb | 3439 | @end display |
e505224d | 3440 | |
899bafeb | 3441 | @example |
e505224d | 3442 | "name" -> "symbol_name:#type" |
139741da | 3443 | # -> G |
899bafeb | 3444 | @end example |
e505224d | 3445 | |
4d7f562d | 3446 | Only the "name" field is significant. The location of the variable is |
e505224d PB |
3447 | obtained from the corresponding external symbol. |
3448 | ||
899bafeb RP |
3449 | @node N_FNAME |
3450 | @section 34 - 0x22 - N_FNAME | |
e505224d PB |
3451 | Function name (for BSD Fortran) |
3452 | ||
899bafeb | 3453 | @display |
e505224d | 3454 | .stabs "name", N_FNAME, NIL, NIL, NIL |
899bafeb | 3455 | @end display |
e505224d | 3456 | |
899bafeb | 3457 | @example |
e505224d | 3458 | "name" -> "function_name" |
899bafeb | 3459 | @end example |
e505224d PB |
3460 | |
3461 | Only the "name" field is significant. The location of the symbol is | |
3462 | obtained from the corresponding extern symbol. | |
3463 | ||
899bafeb | 3464 | @node N_FUN |
6897f9ec | 3465 | @section 36 - 0x24 - N_FUN |
e505224d | 3466 | |
6897f9ec JK |
3467 | Function name (@pxref{Procedures}) or text segment variable |
3468 | (@pxref{Variables}). | |
899bafeb RP |
3469 | @example |
3470 | @exdent @emph{For functions:} | |
e505224d | 3471 | "name" -> "proc_name:#return_type" |
139741da RP |
3472 | # -> F (global function) |
3473 | f (local function) | |
e505224d PB |
3474 | desc -> line num for proc start. (GCC doesn't set and DBX doesn't miss it.) |
3475 | value -> Code address of proc start. | |
3476 | ||
899bafeb | 3477 | @exdent @emph{For text segment variables:} |
e505224d | 3478 | <<How to create one?>> |
899bafeb | 3479 | @end example |
e505224d | 3480 | |
899bafeb RP |
3481 | @node N_STSYM |
3482 | @section 38 - 0x26 - N_STSYM | |
e505224d PB |
3483 | Initialized static symbol (data segment w/internal linkage). |
3484 | ||
899bafeb | 3485 | @display |
e505224d | 3486 | .stabs "name", N_STSYM, NIL, NIL, value |
899bafeb | 3487 | @end display |
e505224d | 3488 | |
899bafeb | 3489 | @example |
e505224d | 3490 | "name" -> "symbol_name#type" |
139741da RP |
3491 | # -> S (scope global to compilation unit) |
3492 | -> V (scope local to a procedure) | |
e505224d | 3493 | value -> Data Address |
899bafeb | 3494 | @end example |
e505224d | 3495 | |
899bafeb RP |
3496 | @node N_LCSYM |
3497 | @section 40 - 0x28 - N_LCSYM | |
e505224d PB |
3498 | Unitialized static (.lcomm) symbol(BSS segment w/internal linkage). |
3499 | ||
899bafeb | 3500 | @display |
e505224d | 3501 | .stabs "name", N_LCLSYM, NIL, NIL, value |
899bafeb | 3502 | @end display |
e505224d | 3503 | |
899bafeb | 3504 | @example |
e505224d | 3505 | "name" -> "symbol_name#type" |
139741da RP |
3506 | # -> S (scope global to compilation unit) |
3507 | -> V (scope local to procedure) | |
e505224d | 3508 | value -> BSS Address |
899bafeb | 3509 | @end example |
e505224d | 3510 | |
899bafeb | 3511 | @node N_MAIN |
139741da | 3512 | @section 42 - 0x2a - N_MAIN |
e505224d PB |
3513 | Name of main routine (not used in C) |
3514 | ||
899bafeb | 3515 | @display |
e505224d | 3516 | .stabs "name", N_MAIN, NIL, NIL, NIL |
899bafeb | 3517 | @end display |
e505224d | 3518 | |
899bafeb | 3519 | @example |
e505224d | 3520 | "name" -> "name_of_main_routine" |
899bafeb | 3521 | @end example |
e505224d | 3522 | |
899bafeb | 3523 | @node N_PC |
139741da | 3524 | @section 48 - 0x30 - N_PC |
e505224d PB |
3525 | Global symbol (for Pascal) |
3526 | ||
899bafeb | 3527 | @display |
e505224d | 3528 | .stabs "name", N_PC, NIL, NIL, value |
899bafeb | 3529 | @end display |
e505224d | 3530 | |
899bafeb | 3531 | @example |
e505224d PB |
3532 | "name" -> "symbol_name" <<?>> |
3533 | value -> supposedly the line number (stab.def is skeptical) | |
899bafeb | 3534 | @end example |
e505224d | 3535 | |
899bafeb | 3536 | @display |
e505224d PB |
3537 | stabdump.c says: |
3538 | ||
3539 | global pascal symbol: name,,0,subtype,line | |
3540 | << subtype? >> | |
899bafeb | 3541 | @end display |
e505224d | 3542 | |
899bafeb | 3543 | @node N_NSYMS |
139741da | 3544 | @section 50 - 0x32 - N_NSYMS |
e505224d PB |
3545 | Number of symbols (according to Ultrix V4.0) |
3546 | ||
899bafeb | 3547 | @display |
139741da | 3548 | 0, files,,funcs,lines (stab.def) |
899bafeb | 3549 | @end display |
e505224d | 3550 | |
899bafeb RP |
3551 | @node N_NOMAP |
3552 | @section 52 - 0x34 - N_NOMAP | |
e505224d PB |
3553 | no DST map for sym (according to Ultrix V4.0) |
3554 | ||
899bafeb | 3555 | @display |
139741da | 3556 | name, ,0,type,ignored (stab.def) |
899bafeb RP |
3557 | @end display |
3558 | ||
3559 | @node N_RSYM | |
139741da | 3560 | @section 64 - 0x40 - N_RSYM |
e505224d PB |
3561 | register variable |
3562 | ||
899bafeb | 3563 | @display |
e505224d | 3564 | .stabs "name:type",N_RSYM,0,RegSize,RegNumber (Sun doc) |
899bafeb | 3565 | @end display |
e505224d | 3566 | |
899bafeb | 3567 | @node N_M2C |
139741da | 3568 | @section 66 - 0x42 - N_M2C |
e505224d PB |
3569 | Modula-2 compilation unit |
3570 | ||
899bafeb | 3571 | @display |
e505224d | 3572 | .stabs "name", N_M2C, 0, desc, value |
899bafeb | 3573 | @end display |
e505224d | 3574 | |
899bafeb | 3575 | @example |
e505224d PB |
3576 | "name" -> "unit_name,unit_time_stamp[,code_time_stamp] |
3577 | desc -> unit_number | |
3578 | value -> 0 (main unit) | |
139741da | 3579 | 1 (any other unit) |
899bafeb | 3580 | @end example |
e505224d | 3581 | |
899bafeb | 3582 | @node N_BROWS |
139741da | 3583 | @section 72 - 0x48 - N_BROWS |
e505224d PB |
3584 | Sun source code browser, path to .cb file |
3585 | ||
3586 | <<?>> | |
3587 | "path to associated .cb file" | |
3588 | ||
3589 | Note: type field value overlaps with N_BSLINE | |
3590 | ||
899bafeb | 3591 | @node N_DEFD |
139741da | 3592 | @section 74 - 0x4a - N_DEFD |
612dbd4c | 3593 | GNU Modula2 definition module dependency |
e505224d PB |
3594 | |
3595 | GNU Modula-2 definition module dependency. Value is the modification | |
3596 | time of the definition file. Other is non-zero if it is imported with | |
3597 | the GNU M2 keyword %INITIALIZE. Perhaps N_M2C can be used if there | |
3598 | are enough empty fields? | |
3599 | ||
899bafeb RP |
3600 | @node N_EHDECL |
3601 | @section 80 - 0x50 - N_EHDECL | |
612dbd4c | 3602 | GNU C++ exception variable <<?>> |
e505224d PB |
3603 | |
3604 | "name is variable name" | |
3605 | ||
3606 | Note: conflicts with N_MOD2. | |
3607 | ||
899bafeb RP |
3608 | @node N_MOD2 |
3609 | @section 80 - 0x50 - N_MOD2 | |
3610 | Modula2 info "for imc" (according to Ultrix V4.0) | |
e505224d PB |
3611 | |
3612 | Note: conflicts with N_EHDECL <<?>> | |
3613 | ||
899bafeb RP |
3614 | @node N_CATCH |
3615 | @section 84 - 0x54 - N_CATCH | |
3616 | GNU C++ "catch" clause | |
e505224d PB |
3617 | |
3618 | GNU C++ `catch' clause. Value is its address. Desc is nonzero if | |
3619 | this entry is immediately followed by a CAUGHT stab saying what | |
3620 | exception was caught. Multiple CAUGHT stabs means that multiple | |
3621 | exceptions can be caught here. If Desc is 0, it means all exceptions | |
3622 | are caught here. | |
3623 | ||
899bafeb | 3624 | @node N_SSYM |
139741da | 3625 | @section 96 - 0x60 - N_SSYM |
e505224d PB |
3626 | Structure or union element |
3627 | ||
899bafeb RP |
3628 | Value is offset in the structure. |
3629 | ||
3630 | <<?looking at structs and unions in C I didn't see these>> | |
e505224d | 3631 | |
899bafeb | 3632 | @node N_LSYM |
139741da | 3633 | @section 128 - 0x80 - N_LSYM |
e505224d PB |
3634 | Automatic var in the stack (also used for type descriptors.) |
3635 | ||
899bafeb | 3636 | @display |
e505224d | 3637 | .stabs "name" N_LSYM, NIL, NIL, value |
899bafeb | 3638 | @end display |
e505224d | 3639 | |
899bafeb RP |
3640 | @example |
3641 | @exdent @emph{For stack based local variables:} | |
e505224d PB |
3642 | |
3643 | "name" -> name of the variable | |
3644 | value -> offset from frame pointer (negative) | |
3645 | ||
899bafeb | 3646 | @exdent @emph{For type descriptors:} |
e505224d PB |
3647 | |
3648 | "name" -> "name_of_the_type:#type" | |
139741da | 3649 | # -> t |
e505224d | 3650 | |
139741da | 3651 | type -> type_ref (or) type_def |
e505224d PB |
3652 | |
3653 | type_ref -> type_number | |
3654 | type_def -> type_number=type_desc etc. | |
899bafeb | 3655 | @end example |
e505224d PB |
3656 | |
3657 | Type may be either a type reference or a type definition. A type | |
3658 | reference is a number that refers to a previously defined type. A | |
3659 | type definition is the number that will refer to this type, followed | |
3660 | by an equals sign, a type descriptor and the additional data that | |
3661 | defines the type. See the Table D for type descriptors and the | |
3662 | section on types for what data follows each type descriptor. | |
3663 | ||
899bafeb RP |
3664 | @node N_ENTRY |
3665 | @section 164 - 0xa4 - N_ENTRY | |
e505224d PB |
3666 | |
3667 | Alternate entry point. | |
3668 | Value is its address. | |
3669 | <<?>> | |
3670 | ||
899bafeb RP |
3671 | @node N_SCOPE |
3672 | @section 196 - 0xc4 - N_SCOPE | |
e505224d PB |
3673 | |
3674 | Modula2 scope information (Sun linker) | |
3675 | <<?>> | |
3676 | ||
899bafeb RP |
3677 | @node Gould |
3678 | @section Non-base registers on Gould systems | |
ded6bcab JK |
3679 | |
3680 | These are used on Gould systems for non-base registers syms. | |
3681 | ||
3682 | However, the following values are not the values used by Gould; they are | |
3683 | the values which GNU has been documenting for these values for a long | |
3684 | time, without actually checking what Gould uses. I include these values | |
3685 | only because perhaps some someone actually did something with the GNU | |
3686 | information (I hope not, why GNU knowingly assigned wrong values to | |
3687 | these in the header file is a complete mystery to me). | |
e505224d | 3688 | |
899bafeb | 3689 | @example |
139741da RP |
3690 | 240 0xf0 N_NBTEXT ?? |
3691 | 242 0xf2 N_NBDATA ?? | |
3692 | 244 0xf4 N_NBBSS ?? | |
3693 | 246 0xf6 N_NBSTS ?? | |
3694 | 248 0xf8 N_NBLCS ?? | |
899bafeb | 3695 | @end example |
e505224d | 3696 | |
899bafeb RP |
3697 | @node N_LENG |
3698 | @section - 0xfe - N_LENG | |
e505224d PB |
3699 | |
3700 | Second symbol entry containing a length-value for the preceding entry. | |
3701 | The value is the length. | |
3702 | ||
899bafeb RP |
3703 | @node Questions |
3704 | @appendix Questions and anomalies | |
e505224d PB |
3705 | |
3706 | @itemize @bullet | |
3707 | @item | |
3708 | For GNU C stabs defining local and global variables (N_LSYM and | |
3709 | N_GSYM), the desc field is supposed to contain the source line number | |
3710 | on which the variable is defined. In reality the desc field is always | |
3711 | 0. (This behavour is defined in dbxout.c and putting a line number in | |
3712 | desc is controlled by #ifdef WINNING_GDB which defaults to false). Gdb | |
3713 | supposedly uses this information if you say 'list var'. In reality | |
3714 | var can be a variable defined in the program and gdb says `function | |
3715 | var not defined' | |
3716 | ||
3717 | @item | |
612dbd4c | 3718 | In GNU C stabs there seems to be no way to differentiate tag types: |
e505224d PB |
3719 | structures, unions, and enums (symbol descriptor T) and typedefs |
3720 | (symbol descriptor t) defined at file scope from types defined locally | |
3721 | to a procedure or other more local scope. They all use the N_LSYM | |
3722 | stab type. Types defined at procedure scope are emited after the | |
139741da | 3723 | N_RBRAC of the preceding function and before the code of the |
e505224d PB |
3724 | procedure in which they are defined. This is exactly the same as |
3725 | types defined in the source file between the two procedure bodies. | |
4d7f562d | 3726 | GDB overcompensates by placing all types in block #1, the block for |
e505224d | 3727 | symbols of file scope. This is true for default, -ansi and |
4d7f562d | 3728 | -traditional compiler options. (Bugs gcc/1063, gdb/1066.) |
e505224d PB |
3729 | |
3730 | @item | |
3731 | What ends the procedure scope? Is it the proc block's N_RBRAC or the | |
3732 | next N_FUN? (I believe its the first.) | |
3733 | ||
3734 | @item | |
3735 | The comment in xcoff.h says DBX_STATIC_CONST_VAR_CODE is used for | |
3736 | static const variables. DBX_STATIC_CONST_VAR_CODE is set to N_FUN by | |
3737 | default, in dbxout.c. If included, xcoff.h redefines it to N_STSYM. | |
3738 | But testing the default behaviour, my Sun4 native example shows | |
3739 | N_STSYM not N_FUN is used to describe file static initialized | |
3740 | variables. (the code tests for TREE_READONLY(decl) && | |
3741 | !TREE_THIS_VOLATILE(decl) and if true uses DBX_STATIC_CONST_VAR_CODE). | |
3742 | ||
3743 | @item | |
3744 | Global variable stabs don't have location information. This comes | |
3745 | from the external symbol for the same variable. The external symbol | |
3746 | has a leading underbar on the _name of the variable and the stab does | |
3747 | not. How do we know these two symbol table entries are talking about | |
3748 | the same symbol when their names are different? | |
3749 | ||
3750 | @item | |
3751 | Can gcc be configured to output stabs the way the Sun compiler | |
3752 | does, so that their native debugging tools work? <NO?> It doesn't by | |
3753 | default. GDB reads either format of stab. (gcc or SunC). How about | |
3754 | dbx? | |
3755 | @end itemize | |
3756 | ||
899bafeb | 3757 | @node xcoff-differences |
e505224d PB |
3758 | @appendix Differences between GNU stabs in a.out and GNU stabs in xcoff |
3759 | ||
497e44a5 JK |
3760 | @c FIXME: Merge *all* these into the main body of the document. |
3761 | (The AIX/RS6000 native object file format is xcoff with stabs). This | |
3762 | appendix only covers those differences which are not covered in the main | |
3763 | body of this document. | |
e505224d PB |
3764 | |
3765 | @itemize @bullet | |
e505224d | 3766 | @item |
5bc927fb | 3767 | BSD a.out stab types correspond to AIX xcoff storage classes. In general the |
e505224d PB |
3768 | mapping is N_STABTYPE becomes C_STABTYPE. Some stab types in a.out |
3769 | are not supported in xcoff. See Table E. for full mappings. | |
3770 | ||
3771 | exception: | |
3772 | initialised static N_STSYM and un-initialized static N_LCSYM both map | |
3773 | to the C_STSYM storage class. But the destinction is preserved | |
3774 | because in xcoff N_STSYM and N_LCSYM must be emited in a named static | |
3775 | block. Begin the block with .bs s[RW] data_section_name for N_STSYM | |
3776 | or .bs s bss_section_name for N_LCSYM. End the block with .es | |
3777 | ||
e505224d PB |
3778 | @item |
3779 | If the xcoff stab is a N_FUN (C_FUN) then follow the string field with | |
3780 | ,. instead of just , | |
e505224d PB |
3781 | @end itemize |
3782 | ||
3783 | ||
3784 | (I think that's it for .s file differences. They could stand to be | |
3785 | better presented. This is just a list of what I have noticed so far. | |
3786 | There are a *lot* of differences in the information in the symbol | |
3787 | tables of the executable and object files.) | |
3788 | ||
3789 | Table E: mapping a.out stab types to xcoff storage classes | |
3790 | ||
3791 | @example | |
139741da | 3792 | stab type storage class |
e505224d | 3793 | ------------------------------- |
139741da RP |
3794 | N_GSYM C_GSYM |
3795 | N_FNAME unknown | |
3796 | N_FUN C_FUN | |
3797 | N_STSYM C_STSYM | |
3798 | N_LCSYM C_STSYM | |
3799 | N_MAIN unkown | |
3800 | N_PC unknown | |
3801 | N_RSYM C_RSYM | |
3802 | N_RPSYM (0x8e) C_RPSYM | |
3803 | N_M2C unknown | |
3804 | N_SLINE unknown | |
3805 | N_DSLINE unknown | |
3806 | N_BSLINE unknown | |
3807 | N_BROWSE unchanged | |
3808 | N_CATCH unknown | |
3809 | N_SSYM unknown | |
3810 | N_SO unknown | |
3811 | N_LSYM C_LSYM | |
3812 | N_DECL (0x8c) C_DECL | |
3813 | N_BINCL unknown | |
3814 | N_SOL unknown | |
3815 | N_PSYM C_PSYM | |
3816 | N_EINCL unknown | |
3817 | N_ENTRY C_ENTRY | |
3818 | N_LBRAC unknown | |
3819 | N_EXCL unknown | |
3820 | N_SCOPE unknown | |
3821 | N_RBRAC unknown | |
3822 | N_BCOMM C_BCOMM | |
3823 | N_ECOMM C_ECOMM | |
3824 | N_ECOML C_ECOML | |
3825 | ||
3826 | N_LENG unknown | |
e505224d PB |
3827 | @end example |
3828 | ||
899bafeb | 3829 | @node Sun-differences |
e505224d PB |
3830 | @appendix Differences between GNU stabs and Sun native stabs. |
3831 | ||
497e44a5 JK |
3832 | @c FIXME: Merge all this stuff into the main body of the document. |
3833 | ||
e505224d PB |
3834 | @itemize @bullet |
3835 | @item | |
612dbd4c | 3836 | GNU C stabs define *all* types, file or procedure scope, as |
e505224d PB |
3837 | N_LSYM. Sun doc talks about using N_GSYM too. |
3838 | ||
e505224d PB |
3839 | @item |
3840 | Sun C stabs use type number pairs in the format (a,b) where a is a | |
3841 | number starting with 1 and incremented for each sub-source file in the | |
3842 | compilation. b is a number starting with 1 and incremented for each | |
612dbd4c | 3843 | new type defined in the compilation. GNU C stabs use the type number |
e505224d PB |
3844 | alone, with no source file number. |
3845 | @end itemize | |
3846 | ||
807e8368 | 3847 | @node Stabs-in-elf |
cc4fb848 FF |
3848 | @appendix Using stabs with the ELF object file format. |
3849 | ||
3850 | The ELF object file format allows tools to create object files with custom | |
3851 | sections containing any arbitrary data. To use stabs in ELF object files, | |
3852 | the tools create two custom sections, a ".stab" section which contains | |
3853 | an array of fixed length structures, one struct per stab, and a ".stabstr" | |
3854 | section containing all the variable length strings that are referenced by | |
5e27ed65 FF |
3855 | stabs in the ".stab" section. The byte order of the stabs binary data |
3856 | matches the byte order of the ELF file itself, as determined from the | |
3857 | EI_DATA field in the e_ident member of the ELF header. | |
cc4fb848 FF |
3858 | |
3859 | The first stab in the ".stab" section for each object file is a "synthetic | |
3860 | stab", generated entirely by the assembler, with no corresponding ".stab" | |
3861 | directive as input to the assembler. This stab contains the following | |
3862 | fields: | |
3863 | ||
3864 | @itemize @bullet | |
3865 | @item | |
3866 | Offset in the ".stabstr" section to the source filename. | |
3867 | ||
3868 | @item | |
3869 | N_UNDF | |
3870 | ||
3871 | @item | |
3872 | Unused field, always zero. | |
3873 | ||
3874 | @item | |
3875 | Count of upcoming symbols. I.E. the number of remaining stabs for this | |
3876 | object module. | |
3877 | ||
3878 | @item | |
3879 | Size of the string table fragment associated with this object module, in | |
3880 | bytes. | |
3881 | ||
3882 | @end itemize | |
3883 | ||
3884 | The ".stabstr" section always starts with a null byte (so that string | |
3885 | offsets of zero reference a null string), followed by random length strings, | |
3886 | each of which is null byte terminated. | |
3887 | ||
3888 | The ELF section header for the ".stab" section has it's sh_link member set | |
3889 | to the section number of the ".stabstr" section, and the ".stabstr" section | |
3890 | has it's ELF section header sh_type member set to SHT_STRTAB to mark it as | |
3891 | a string table. | |
3892 | ||
e505224d PB |
3893 | @contents |
3894 | @bye |