Commit | Line | Data |
---|---|---|
e505224d PB |
1 | \input texinfo |
2 | @setfilename stabs.info | |
3 | ||
4 | @ifinfo | |
5 | @format | |
6 | START-INFO-DIR-ENTRY | |
139741da | 7 | * Stabs: (stabs). The "stabs" debugging information format. |
e505224d PB |
8 | END-INFO-DIR-ENTRY |
9 | @end format | |
10 | @end ifinfo | |
11 | ||
12 | @ifinfo | |
612dbd4c | 13 | This document describes GNU stabs (debugging symbol tables) in a.out files. |
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 | |
612dbd4c | 65 | This document describes the GNU stabs debugging format in a.out files. |
e505224d PB |
66 | |
67 | @menu | |
139741da RP |
68 | * Overview:: Overview of stabs |
69 | * Program structure:: Encoding of the structure of the program | |
e505224d | 70 | * Simple types:: |
139741da | 71 | * Example:: A comprehensive example in C |
e505224d PB |
72 | * Variables:: |
73 | * Aggregate types:: | |
139741da | 74 | * Symbol tables:: Symbol information in symbol tables |
e505224d PB |
75 | * GNU C++ stabs:: |
76 | ||
77 | Appendixes: | |
139741da RP |
78 | * Example2.c:: Source code for extended example |
79 | * Example2.s:: Assembly code for extended example | |
80 | * Quick reference:: Various refernce tables | |
81 | * Expanded reference:: Reference information by stab type | |
82 | * Questions:: Questions and anomolies | |
83 | * xcoff-differences:: Differences between GNU stabs in a.out | |
84 | and GNU stabs in xcoff | |
85 | * Sun-differences:: Differences between GNU stabs and Sun | |
86 | native stabs | |
e505224d | 87 | @end menu |
899bafeb | 88 | @end ifinfo |
e505224d PB |
89 | |
90 | ||
899bafeb | 91 | @node Overview |
e505224d PB |
92 | @chapter Overview of stabs |
93 | ||
139741da RP |
94 | @dfn{Stabs} refers to a format for information that describes a program |
95 | to a debugger. This format was apparently invented by | |
96 | @c FIXME! <<name of inventor>> at | |
97 | the University of California at Berkeley, for the @code{pdx} Pascal | |
98 | debugger; the format has spread widely since then. | |
99 | ||
e505224d PB |
100 | @menu |
101 | * Flow:: Overview of debugging information flow | |
102 | * Stabs format:: Overview of stab format | |
103 | * C example:: A simple example in C source | |
104 | * Assembly code:: The simple example at the assembly level | |
105 | @end menu | |
106 | ||
899bafeb | 107 | @node Flow |
e505224d PB |
108 | @section Overview of debugging information flow |
109 | ||
139741da RP |
110 | The GNU C compiler compiles C source in a @file{.c} file into assembly |
111 | language in a @file{.s} file, which is translated by the assembler into | |
112 | a @file{.o} file, and then linked with other @file{.o} files and | |
113 | libraries to produce an executable file. | |
e505224d | 114 | |
139741da RP |
115 | With the @samp{-g} option, GCC puts additional debugging information in |
116 | the @file{.s} file, which is slightly transformed by the assembler and | |
e505224d PB |
117 | linker, and carried through into the final executable. This debugging |
118 | information describes features of the source file like line numbers, | |
119 | the types and scopes of variables, and functions, their parameters and | |
120 | their scopes. | |
121 | ||
122 | For some object file formats, the debugging information is | |
139741da | 123 | encapsulated in assembler directives known collectively as `stab' (symbol |
e505224d PB |
124 | table) directives, interspersed with the generated code. Stabs are |
125 | the native format for debugging information in the a.out and xcoff | |
126 | object file formats. The GNU tools can also emit stabs in the coff | |
127 | and ecoff object file formats. | |
128 | ||
139741da RP |
129 | The assembler adds the information from stabs to the symbol information |
130 | it places by default in the symbol table and the string table of the | |
131 | @file{.o} file it is building. The linker consolidates the @file{.o} | |
132 | files into one executable file, with one symbol table and one string | |
133 | table. Debuggers use the symbol and string tables in the executable as | |
134 | a source of debugging information about the program. | |
e505224d | 135 | |
899bafeb | 136 | @node Stabs format |
e505224d PB |
137 | @section Overview of stab format |
138 | ||
139 | There are three overall formats for stab assembler directives | |
139741da RP |
140 | differentiated by the first word of the stab. The name of the directive |
141 | describes what combination of four possible data fields will follow. It | |
142 | is either @code{.stabs} (string), @code{.stabn} (number), or | |
143 | @code{.stabd} (dot). | |
e505224d PB |
144 | |
145 | The overall format of each class of stab is: | |
146 | ||
147 | @example | |
139741da RP |
148 | .stabs "@var{string}",@var{type},0,@var{desc},@var{value} |
149 | .stabn @var{type},0,@var{desc},@var{value} | |
150 | .stabd @var{type},0,@var{desc} | |
e505224d PB |
151 | @end example |
152 | ||
139741da RP |
153 | In general, in @code{.stabs} the @var{string} field contains name and type |
154 | information. For @code{.stabd} the value field is implicit and has the value | |
e505224d PB |
155 | of the current file location. Otherwise the value field often |
156 | contains a relocatable address, frame pointer offset, or register | |
157 | number, that maps to the source code element described by the stab. | |
158 | ||
139741da RP |
159 | The real key to decoding the meaning of a stab is the number in its type |
160 | field. Each possible type number defines a different stab type. The | |
161 | stab type further defines the exact interpretation of, and possible | |
162 | values for, any remaining @code{"@var{string}"}, @var{desc}, or | |
163 | @var{value} fields present in the stab. Table A (@pxref{Stab | |
164 | types,,Table A: Symbol types from stabs}) lists in numeric order | |
165 | the possible type field values for stab directives. The reference | |
166 | section that follows Table A describes the meaning of the fields for | |
167 | each stab type in detail. The examples that follow this overview | |
168 | introduce the stab types in terms of the source code elements they | |
169 | describe. | |
e505224d | 170 | |
139741da RP |
171 | For @code{.stabs} the @code{"@var{string}"} field holds the meat of the |
172 | debugging information. The generally unstructured nature of this field | |
173 | is what makes stabs extensible. For some stab types the string field | |
174 | contains only a name. For other stab types the contents can be a great | |
175 | deal more complex. | |
e505224d | 176 | |
139741da | 177 | The overall format is of the @code{"@var{string}"} field is: |
e505224d PB |
178 | |
179 | @example | |
139741da RP |
180 | "@var{name}@r{[}:@var{symbol_descriptor}@r{]} |
181 | @r{[}@var{type_number}@r{[}=@var{type_descriptor} @r{@dots{}]]}" | |
e505224d PB |
182 | @end example |
183 | ||
139741da | 184 | @var{name} is the name of the symbol represented by the stab. |
e505224d | 185 | |
139741da RP |
186 | The @var{symbol_descriptor} following the @samp{:} is an alphabetic |
187 | character that tells more specifically what kind of symbol the stab | |
188 | represents. If the @var{symbol_descriptor} is omitted, but type | |
189 | information follows, then the stab represents a local variable. For a | |
190 | list of symbol_descriptors, see @ref{Symbol descriptors,,Table C: Symbol | |
191 | descriptors}. | |
e505224d | 192 | |
139741da RP |
193 | Type information is either a @var{type_number}, or a |
194 | @samp{@var{type_number}=}. The @var{type_number} alone is a type | |
195 | reference, referring directly to a type that has already been defined. | |
e505224d | 196 | |
139741da RP |
197 | The @samp{@var{type_number}=} is a type definition, where the number |
198 | represents a new type which is about to be defined. The type definition | |
199 | may refer to other types by number, and those type numbers may be | |
200 | followed by @samp{=} and nested definitions. | |
e505224d PB |
201 | |
202 | In a type definition, if the character that follows the equals sign is | |
139741da RP |
203 | non-numeric then it is a @var{type_descriptor}, and tells what kind of |
204 | type is about to be defined. Any other values following the | |
205 | @var{type_descriptor} vary, depending on the @var{type_descriptor}. If | |
206 | a number follows the @samp{=} then the number is a @var{type_reference}. | |
207 | This is described more thoroughly in the section on types. @xref{Type | |
208 | Descriptors,,Table D: Type Descriptors}, for a list of | |
209 | @var{type_descriptor} values. | |
210 | ||
211 | @c FIXME! "too long" below introduced at J Gilmore's request; used to | |
212 | @c say "more than 80 chars". Why is vaguer better? | |
213 | All this can make the @code{"@var{string}"} field quite long. When the | |
214 | @code{"@var{string}"} part of a stab is too long, the compiler splits | |
215 | the @code{.stabs} directive into two @code{.stabs} directives. Both | |
216 | stabs duplicate exactly all but the @code{"@var{string}"} field. The | |
217 | @code{"@var{string}"} field of the first stab contains the first part of | |
218 | the overlong string, marked as continued with a double-backslash at the | |
219 | end. The @code{"@var{string}"} field of the second stab holds the | |
220 | second half of the overlong string. | |
e505224d | 221 | |
899bafeb | 222 | @node C example |
e505224d PB |
223 | @section A simple example in C source |
224 | ||
225 | To get the flavor of how stabs describe source information for a C | |
226 | program, let's look at the simple program: | |
227 | ||
228 | @example | |
229 | main() | |
230 | @{ | |
139741da | 231 | printf("Hello world"); |
e505224d PB |
232 | @} |
233 | @end example | |
234 | ||
139741da RP |
235 | When compiled with @samp{-g}, the program above yields the following |
236 | @file{.s} file. Line numbers have been added to make it easier to refer | |
237 | to parts of the @file{.s} file in the description of the stabs that | |
238 | follows. | |
e505224d | 239 | |
899bafeb | 240 | @node Assembly code |
e505224d PB |
241 | @section The simple example at the assembly level |
242 | ||
243 | @example | |
244 | 1 gcc2_compiled.: | |
245 | 2 .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 | |
246 | 3 .stabs "hello.c",100,0,0,Ltext0 | |
247 | 4 .text | |
248 | 5 Ltext0: | |
249 | 6 .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 | |
250 | 7 .stabs "char:t2=r2;0;127;",128,0,0,0 | |
251 | 8 .stabs "long int:t3=r1;-2147483648;2147483647;",128,0,0,0 | |
252 | 9 .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0 | |
253 | 10 .stabs "long unsigned int:t5=r1;0;-1;",128,0,0,0 | |
254 | 11 .stabs "short int:t6=r1;-32768;32767;",128,0,0,0 | |
255 | 12 .stabs "long long int:t7=r1;0;-1;",128,0,0,0 | |
256 | 13 .stabs "short unsigned int:t8=r1;0;65535;",128,0,0,0 | |
257 | 14 .stabs "long long unsigned int:t9=r1;0;-1;",128,0,0,0 | |
258 | 15 .stabs "signed char:t10=r1;-128;127;",128,0,0,0 | |
259 | 16 .stabs "unsigned char:t11=r1;0;255;",128,0,0,0 | |
260 | 17 .stabs "float:t12=r1;4;0;",128,0,0,0 | |
261 | 18 .stabs "double:t13=r1;8;0;",128,0,0,0 | |
262 | 19 .stabs "long double:t14=r1;8;0;",128,0,0,0 | |
263 | 20 .stabs "void:t15=15",128,0,0,0 | |
139741da | 264 | 21 .align 4 |
e505224d | 265 | 22 LC0: |
139741da RP |
266 | 23 .ascii "Hello, world!\12\0" |
267 | 24 .align 4 | |
268 | 25 .global _main | |
269 | 26 .proc 1 | |
e505224d PB |
270 | 27 _main: |
271 | 28 .stabn 68,0,4,LM1 | |
272 | 29 LM1: | |
139741da RP |
273 | 30 !#PROLOGUE# 0 |
274 | 31 save %sp,-136,%sp | |
275 | 32 !#PROLOGUE# 1 | |
276 | 33 call ___main,0 | |
277 | 34 nop | |
e505224d PB |
278 | 35 .stabn 68,0,5,LM2 |
279 | 36 LM2: | |
280 | 37 LBB2: | |
139741da RP |
281 | 38 sethi %hi(LC0),%o1 |
282 | 39 or %o1,%lo(LC0),%o0 | |
283 | 40 call _printf,0 | |
284 | 41 nop | |
e505224d PB |
285 | 42 .stabn 68,0,6,LM3 |
286 | 43 LM3: | |
287 | 44 LBE2: | |
288 | 45 .stabn 68,0,6,LM4 | |
289 | 46 LM4: | |
290 | 47 L1: | |
139741da RP |
291 | 48 ret |
292 | 49 restore | |
e505224d PB |
293 | 50 .stabs "main:F1",36,0,0,_main |
294 | 51 .stabn 192,0,0,LBB2 | |
295 | 52 .stabn 224,0,0,LBE2 | |
296 | @end example | |
297 | ||
139741da | 298 | This simple ``hello world'' example demonstrates several of the stab |
e505224d PB |
299 | types used to describe C language source files. |
300 | ||
899bafeb | 301 | @node Program structure |
139741da | 302 | @chapter Encoding for the structure of the program |
e505224d PB |
303 | |
304 | @menu | |
305 | * Source file:: The path and name of the source file | |
306 | * Line numbers:: | |
307 | * Procedures:: | |
308 | * Block structure:: | |
309 | @end menu | |
310 | ||
899bafeb | 311 | @node Source file |
e505224d PB |
312 | @section The path and name of the source file |
313 | ||
139741da RP |
314 | @table @strong |
315 | @item Directive: | |
316 | @code{.stabs} | |
317 | @item Type: | |
318 | @code{N_SO} | |
319 | @end table | |
e505224d PB |
320 | |
321 | The first stabs in the .s file contain the name and path of the source | |
322 | file that was compiled to produce the .s file. This information is | |
323 | contained in two records of stab type N_SO (100). | |
324 | ||
325 | @example | |
326 | .stabs "path_name", N_SO, NIL, NIL, Code_address_of_program_start | |
327 | .stabs "file_name:", N_SO, NIL, NIL, Code_address_of_program_start | |
328 | @end example | |
329 | ||
330 | @example | |
331 | 2 .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 | |
332 | 3 .stabs "hello.c",100,0,0,Ltext0 | |
139741da | 333 | 4 .text |
e505224d PB |
334 | 5 Ltext0: |
335 | @end example | |
336 | ||
899bafeb | 337 | @node Line numbers |
e505224d PB |
338 | @section Line Numbers |
339 | ||
139741da RP |
340 | @table @strong |
341 | @item Directive: | |
342 | @code{.stabn} | |
343 | @item Type: | |
344 | @code{N_SLINE} | |
345 | @end table | |
e505224d | 346 | |
139741da | 347 | The start of source lines is represented by the @code{N_SLINE} (68) stab |
e505224d PB |
348 | type. |
349 | ||
350 | @example | |
139741da | 351 | .stabn N_SLINE, NIL, @var{line}, @var{address} |
e505224d PB |
352 | @end example |
353 | ||
139741da RP |
354 | @var{line} is a source line number; @var{address} represents the code |
355 | address for the start of that source line. | |
356 | ||
e505224d PB |
357 | @example |
358 | 27 _main: | |
359 | 28 .stabn 68,0,4,LM1 | |
360 | 29 LM1: | |
139741da | 361 | 30 !#PROLOGUE# 0 |
e505224d PB |
362 | @end example |
363 | ||
899bafeb | 364 | @node Procedures |
e505224d PB |
365 | @section Procedures |
366 | ||
139741da RP |
367 | @table @strong |
368 | @item Directive: | |
369 | @code{.stabs} | |
370 | @item Type: | |
371 | @code{N_FUN} | |
372 | @item Symbol Descriptors: | |
373 | @code{f} (local), @code{F} (global) | |
374 | @end table | |
e505224d | 375 | |
139741da RP |
376 | Procedures are described by the @code{N_FUN} stab type. The symbol |
377 | descriptor for a procedure is @samp{F} if the procedure is globally | |
378 | scoped and @samp{f} if the procedure is static (locally scoped). | |
e505224d | 379 | |
139741da RP |
380 | The @code{N_FUN} stab representing a procedure is located immediately |
381 | following the code of the procedure. The @code{N_FUN} stab is in turn | |
e505224d PB |
382 | directly followed by a group of other stabs describing elements of the |
383 | procedure. These other stabs describe the procedure's parameters, its | |
384 | block local variables and its block structure. | |
385 | ||
386 | @example | |
139741da RP |
387 | 48 ret |
388 | 49 restore | |
e505224d PB |
389 | @end example |
390 | ||
139741da RP |
391 | The @code{.stabs} entry after this code fragment shows the @var{name} of |
392 | the procedure (@code{main}); the type descriptor @var{desc} (@code{F}, | |
393 | for a global procedure); a reference to the predefined type @code{int} | |
394 | for the return type; and the starting @var{address} of the procedure. | |
395 | ||
396 | Here is an exploded summary (with whitespace introduced for clarity), | |
397 | followed by line 50 of our sample assembly output, which has this form: | |
398 | ||
e505224d | 399 | @example |
139741da RP |
400 | .stabs "@var{name}: |
401 | @var{desc} @r{(global proc @samp{F})} | |
402 | @var{return_type_ref} @r{(int)} | |
403 | ",N_FUN, NIL, NIL, | |
404 | @var{address} | |
e505224d PB |
405 | @end example |
406 | ||
407 | @example | |
408 | 50 .stabs "main:F1",36,0,0,_main | |
409 | @end example | |
410 | ||
899bafeb | 411 | @node Block Structure |
e505224d PB |
412 | @section Block Structure |
413 | ||
139741da RP |
414 | @table @strong |
415 | @item Directive: | |
416 | @code{.stabn} | |
417 | @item Types: | |
418 | @code{N_LBRAC}, @code{N_RBRAC} | |
419 | @end table | |
e505224d | 420 | |
139741da RP |
421 | The program's block structure is represented by the @code{N_LBRAC} (left |
422 | brace) and the @code{N_RBRAC} (right brace) stab types. The following code | |
423 | range, which is the body of @code{main}, is labeled with @samp{LBB2:} at the | |
424 | beginning and @samp{LBE2:} at the end. | |
e505224d PB |
425 | |
426 | @example | |
427 | 37 LBB2: | |
139741da RP |
428 | 38 sethi %hi(LC0),%o1 |
429 | 39 or %o1,%lo(LC0),%o0 | |
430 | 40 call _printf,0 | |
431 | 41 nop | |
e505224d PB |
432 | 42 .stabn 68,0,6,LM3 |
433 | 43 LM3: | |
434 | 44 LBE2: | |
435 | @end example | |
436 | ||
139741da RP |
437 | The @code{N_LBRAC} and @code{N_RBRAC} stabs that describe the block |
438 | scope of the procedure are located after the @code{N_FUNC} stab that | |
439 | represents the procedure itself. The @code{N_LBRAC} uses the | |
440 | @code{LBB2} label as the code address in its value field, and the | |
441 | @code{N_RBRAC} uses @code{LBE2}. | |
e505224d PB |
442 | |
443 | @example | |
444 | 50 .stabs "main:F1",36,0,0,_main | |
445 | @end example | |
446 | ||
447 | @example | |
139741da RP |
448 | .stabn N_LBRAC, NIL, NIL, @var{left-brace-address} |
449 | .stabn N_RBRAC, NIL, NIL, @var{right-brace-address} | |
e505224d PB |
450 | @end example |
451 | ||
452 | @example | |
453 | 51 .stabn 192,0,0,LBB2 | |
454 | 52 .stabn 224,0,0,LBE2 | |
455 | @end example | |
456 | ||
899bafeb | 457 | @node Simple types |
e505224d PB |
458 | @chapter Simple types |
459 | ||
460 | @menu | |
139741da | 461 | * Basic types:: Basic type definitions |
e505224d PB |
462 | * Range types:: Range types defined by min and max value |
463 | * Bit-ranges:: Range type defined by number of bits | |
464 | @end menu | |
465 | ||
899bafeb | 466 | @node Basic types |
e505224d PB |
467 | @section Basic type definitions |
468 | ||
139741da RP |
469 | @table @strong |
470 | @item Directive: | |
471 | @code{.stabs} | |
472 | @item Type: | |
473 | @code{N_LSYM} | |
474 | @item Symbol Descriptor: | |
475 | @code{t} | |
476 | @end table | |
e505224d | 477 | |
139741da | 478 | The basic types for the language are described using the @code{N_LSYM} stab |
e505224d PB |
479 | type. They are boilerplate and are emited by the compiler for each |
480 | compilation unit. Basic type definitions are not always a complete | |
481 | description of the type and are sometimes circular. The debugger | |
482 | recognizes the type anyway, and knows how to read bits as that type. | |
483 | ||
484 | Each language and compiler defines a slightly different set of basic | |
485 | types. In this example we are looking at the basic types for C emited | |
486 | by the GNU compiler targeting the Sun4. Here the basic types are | |
487 | mostly defined as range types. | |
488 | ||
489 | ||
899bafeb | 490 | @node Range types |
e505224d PB |
491 | @section Range types defined by min and max value |
492 | ||
139741da RP |
493 | @table @strong |
494 | @item Type Descriptor: | |
495 | @code{r} | |
496 | @end table | |
e505224d PB |
497 | |
498 | When defining a range type, if the number after the first semicolon is | |
499 | smaller than the number after the second one, then the two numbers | |
500 | represent the smallest and the largest values in the range. | |
501 | ||
502 | @example | |
503 | 4 .text | |
504 | 5 Ltext0: | |
505 | ||
139741da RP |
506 | .stabs "@var{name}: |
507 | @var{descriptor} @r{(type)} | |
508 | @var{type-def}= | |
509 | @var{type-desc} | |
510 | @var{type-ref}; | |
511 | @var{low-bound}; | |
512 | @var{high-bound}; | |
513 | ", | |
514 | N_LSYM, NIL, NIL, NIL | |
e505224d PB |
515 | |
516 | 6 .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 | |
517 | 7 .stabs "char:t2=r2;0;127;",128,0,0,0 | |
518 | @end example | |
519 | ||
139741da RP |
520 | Here the integer type (@code{1}) is defined as a range of the integer |
521 | type (@code{1}). Likewise @code{char} is a range of @code{char}. This | |
522 | part of the definition is circular, but at least the high and low bound | |
523 | values of the range hold more information about the type. | |
e505224d PB |
524 | |
525 | Here short unsigned int is defined as type number 8 and described as a | |
139741da | 526 | range of type @code{int}, with a minimum value of 0 and a maximum of 65535. |
e505224d PB |
527 | |
528 | @example | |
529 | 13 .stabs "short unsigned int:t8=r1;0;65535;",128,0,0,0 | |
530 | @end example | |
531 | ||
899bafeb | 532 | @node Bit-ranges |
e505224d PB |
533 | @section Range type defined by number of bits |
534 | ||
139741da RP |
535 | @table @strong |
536 | @item Type Descriptor: | |
537 | @code{r} | |
538 | @end table | |
e505224d PB |
539 | |
540 | In a range definition, if the number after the second semicolon is 0, | |
541 | then the number after the first semicolon is the number of bits needed | |
542 | to represent the type. | |
543 | ||
544 | @example | |
139741da RP |
545 | .stabs "@var{name}: |
546 | @var{desc} | |
547 | @var{type-def}= | |
548 | @var{type-desc} | |
549 | @var{type-ref}; | |
550 | @var{bit-count}; | |
551 | 0; | |
552 | ", | |
553 | N_LSYM, NIL, NIL, NIL | |
e505224d PB |
554 | |
555 | 17 .stabs "float:t12=r1;4;0;",128,0,0,0 | |
556 | 18 .stabs "double:t13=r1;8;0;",128,0,0,0 | |
557 | 19 .stabs "long double:t14=r1;8;0;",128,0,0,0 | |
558 | @end example | |
559 | ||
139741da | 560 | Cosmically enough, the @code{void} type is defined directly in terms of |
e505224d PB |
561 | itself. |
562 | ||
563 | @example | |
139741da RP |
564 | .stabs "@var{name}: |
565 | @var{symbol-desc} | |
566 | @var{type-def}= | |
567 | @var{type-ref} | |
568 | ",N_LSYM,NIL,NIL,NIL | |
e505224d | 569 | |
e505224d PB |
570 | 20 .stabs "void:t15=15",128,0,0,0 |
571 | @end example | |
572 | ||
573 | ||
899bafeb | 574 | @node Example |
e505224d PB |
575 | @chapter A Comprehensive Example in C |
576 | ||
139741da | 577 | Now we'll examine a second program, @code{example2}, which builds on the |
e505224d PB |
578 | first example to introduce the rest of the stab types, symbol |
579 | descriptors, and type descriptors used in C. | |
139741da RP |
580 | @xref{Example2.c} for the complete @file{.c} source, |
581 | and @pxref{Example2.s} for the @file{.s} assembly code. | |
e505224d PB |
582 | This description includes parts of those files. |
583 | ||
584 | @section Flow of control and nested scopes | |
585 | ||
9cd64d11 | 586 | @table @strong |
139741da RP |
587 | @item Directive: |
588 | @code{.stabn} | |
589 | @item Types: | |
590 | @code{N_SLINE}, @code{N_LBRAC}, @code{N_RBRAC} (cont.) | |
591 | @end table | |
e505224d | 592 | |
899bafeb RP |
593 | Consider the body of @code{main}, from @file{example2.c}. It shows more |
594 | about how @code{N_SLINE}, @code{N_RBRAC}, and @code{N_LBRAC} stabs are used. | |
e505224d PB |
595 | |
596 | @example | |
597 | 20 @{ | |
598 | 21 static float s_flap; | |
139741da RP |
599 | 22 int times; |
600 | 23 for (times=0; times < s_g_repeat; times++)@{ | |
601 | 24 int inner; | |
602 | 25 printf ("Hello world\n"); | |
603 | 26 @} | |
e505224d PB |
604 | 27 @}; |
605 | @end example | |
606 | ||
899bafeb | 607 | Here we have a single source line, the @samp{for} line, that generates |
e505224d | 608 | non-linear flow of control, and non-contiguous code. In this case, an |
899bafeb | 609 | @code{N_SLINE} stab with the same line number proceeds each block of |
e505224d PB |
610 | non-contiguous code generated from the same source line. |
611 | ||
139741da RP |
612 | The example also shows nested scopes. The @code{N_LBRAC} and |
613 | @code{N_LBRAC} stabs that describe block structure are nested in the | |
614 | same order as the corresponding code blocks, those of the for loop | |
615 | inside those for the body of main. | |
e505224d | 616 | |
139741da RP |
617 | @noindent |
618 | This is the label for the @code{N_LBRAC} (left brace) stab marking the | |
619 | start of @code{main}. | |
e505224d | 620 | |
139741da | 621 | @example |
e505224d | 622 | 57 LBB2: |
139741da RP |
623 | @end example |
624 | ||
625 | @noindent | |
626 | In the first code range for C source line 23, the @code{for} loop | |
627 | initialize and test, @code{N_SLINE} (68) records the line number: | |
e505224d | 628 | |
139741da RP |
629 | @example |
630 | .stabn N_SLINE, NIL, | |
631 | @var{line}, | |
632 | @var{address} | |
e505224d | 633 | |
e505224d PB |
634 | 58 .stabn 68,0,23,LM2 |
635 | 59 LM2: | |
139741da | 636 | 60 st %g0,[%fp-20] |
e505224d | 637 | 61 L2: |
139741da RP |
638 | 62 sethi %hi(_s_g_repeat),%o0 |
639 | 63 ld [%fp-20],%o1 | |
640 | 64 ld [%o0+%lo(_s_g_repeat)],%o0 | |
641 | 65 cmp %o1,%o0 | |
642 | 66 bge L3 | |
643 | 67 nop | |
e505224d | 644 | |
139741da | 645 | @exdent label for the @code{N_LBRAC} (start block) marking the start of @code{for} loop |
e505224d | 646 | |
e505224d PB |
647 | 68 LBB3: |
648 | 69 .stabn 68,0,25,LM3 | |
649 | 70 LM3: | |
139741da RP |
650 | 71 sethi %hi(LC0),%o1 |
651 | 72 or %o1,%lo(LC0),%o0 | |
652 | 73 call _printf,0 | |
653 | 74 nop | |
e505224d PB |
654 | 75 .stabn 68,0,26,LM4 |
655 | 76 LM4: | |
e505224d | 656 | |
139741da | 657 | @exdent label for the @code{N_RBRAC} (end block) stab marking the end of the @code{for} loop |
e505224d | 658 | |
e505224d | 659 | 77 LBE3: |
139741da | 660 | @end example |
e505224d | 661 | |
139741da RP |
662 | @noindent |
663 | Now we come to the second code range for source line 23, the @code{for} | |
664 | loop increment and return. Once again, @code{N_SLINE} (68) records the | |
665 | source line number: | |
612dbd4c | 666 | |
139741da RP |
667 | @example |
668 | .stabn, N_SLINE, NIL, | |
669 | @var{line}, | |
670 | @var{address} | |
e505224d | 671 | |
e505224d PB |
672 | 78 .stabn 68,0,23,LM5 |
673 | 79 LM5: | |
674 | 80 L4: | |
139741da RP |
675 | 81 ld [%fp-20],%o0 |
676 | 82 add %o0,1,%o1 | |
677 | 83 st %o1,[%fp-20] | |
678 | 84 b,a L2 | |
e505224d PB |
679 | 85 L3: |
680 | 86 .stabn 68,0,27,LM6 | |
681 | 87 LM6: | |
e505224d | 682 | |
139741da | 683 | @exdent label for the @code{N_RBRAC} (end block) stab marking the end of the @code{for} loop |
e505224d | 684 | |
e505224d PB |
685 | 88 LBE2: |
686 | 89 .stabn 68,0,27,LM7 | |
687 | 90 LM7: | |
688 | 91 L1: | |
139741da RP |
689 | 92 ret |
690 | 93 restore | |
e505224d PB |
691 | 94 .stabs "main:F1",36,0,0,_main |
692 | 95 .stabs "argc:p1",160,0,0,68 | |
693 | 96 .stabs "argv:p20=*21=*2",160,0,0,72 | |
694 | 97 .stabs "s_flap:V12",40,0,0,_s_flap.0 | |
695 | 98 .stabs "times:1",128,0,0,-20 | |
139741da RP |
696 | @end example |
697 | ||
698 | @noindent | |
699 | Here is an illustration of stabs describing nested scopes. The scope | |
700 | nesting is reflected in the nested bracketing stabs (@code{N_LBRAC}, | |
701 | 192, appears here). | |
e505224d | 702 | |
139741da RP |
703 | @example |
704 | .stabn N_LBRAC,NIL,NIL, | |
705 | @var{block-start-address} | |
e505224d PB |
706 | |
707 | 99 .stabn 192,0,0,LBB2 ## begin proc label | |
708 | 100 .stabs "inner:1",128,0,0,-24 | |
709 | 101 .stabn 192,0,0,LBB3 ## begin for label | |
139741da | 710 | @end example |
e505224d | 711 | |
139741da RP |
712 | @noindent |
713 | @code{N_RBRAC} (224), ``right brace'' ends a lexical block (scope). | |
714 | ||
715 | @example | |
716 | .stabn N_RBRAC,NIL,NIL, | |
717 | @var{block-end-address} | |
e505224d PB |
718 | |
719 | 102 .stabn 224,0,0,LBE3 ## end for label | |
720 | 103 .stabn 224,0,0,LBE2 ## end proc label | |
721 | @end example | |
722 | ||
899bafeb | 723 | @node Variables |
e505224d PB |
724 | @chapter Variables |
725 | ||
726 | @menu | |
727 | * Automatic variables:: locally scoped | |
728 | * Global variables:: | |
729 | * Register variables:: | |
730 | * Initialized statics:: | |
731 | * Un-initialized statics:: | |
732 | * Parameters:: | |
733 | @end menu | |
734 | ||
899bafeb | 735 | @node Automatic variables |
e505224d PB |
736 | @section Locally scoped automatic variables |
737 | ||
139741da RP |
738 | @table @strong |
739 | @item Directive: | |
740 | @code{.stabs} | |
741 | @item Type: | |
742 | @code{N_LSYM} | |
743 | @item Symbol Descriptor: | |
744 | none | |
745 | @end table | |
e505224d PB |
746 | |
747 | ||
139741da RP |
748 | In addition to describing types, the @code{N_LSYM} stab type also |
749 | describes locally scoped automatic variables. Refer again to the body | |
750 | of @code{main} in @file{example2.c}. It allocates two automatic | |
751 | variables: @samp{times} is scoped to the body of @code{main}, and | |
752 | @samp{inner} is scoped to the body of the @code{for} loop. | |
753 | @samp{s_flap} is locally scoped but not automatic, and will be discussed | |
754 | later. | |
e505224d PB |
755 | |
756 | @example | |
757 | 20 @{ | |
758 | 21 static float s_flap; | |
139741da RP |
759 | 22 int times; |
760 | 23 for (times=0; times < s_g_repeat; times++)@{ | |
761 | 24 int inner; | |
762 | 25 printf ("Hello world\n"); | |
763 | 26 @} | |
e505224d PB |
764 | 27 @}; |
765 | @end example | |
766 | ||
139741da RP |
767 | The @code{N_LSYM} stab for an automatic variable is located just before the |
768 | @code{N_LBRAC} stab describing the open brace of the block to which it is | |
e505224d PB |
769 | scoped. |
770 | ||
771 | @example | |
139741da RP |
772 | @exdent @code{N_LSYM} (128): automatic variable, scoped locally to @code{main} |
773 | ||
774 | .stabs "@var{name}: | |
775 | @var{type-ref}", | |
776 | N_LSYM, NIL, NIL, | |
777 | @var{frame-pointer-offset} | |
e505224d PB |
778 | |
779 | 98 .stabs "times:1",128,0,0,-20 | |
780 | 99 .stabn 192,0,0,LBB2 ## begin `main' N_LBRAC | |
781 | ||
139741da RP |
782 | @exdent @code{N_LSYM} (128): automatic variable, scoped locally to the @code{for} loop |
783 | ||
784 | .stabs "@var{name}: | |
785 | @var{type-ref}", | |
786 | N_LSYM, NIL, NIL, | |
787 | @var{frame-pointer-offset} | |
e505224d PB |
788 | |
789 | 100 .stabs "inner:1",128,0,0,-24 | |
790 | 101 .stabn 192,0,0,LBB3 ## begin `for' loop N_LBRAC | |
791 | @end example | |
792 | ||
793 | Since the character in the string field following the colon is not a | |
794 | letter, there is no symbol descriptor. This means that the stab | |
795 | describes a local variable, and that the number after the colon is a | |
139741da | 796 | type reference. In this case it a a reference to the basic type @code{int}. |
e505224d PB |
797 | Notice also that the frame pointer offset is negative number for |
798 | automatic variables. | |
799 | ||
800 | ||
899bafeb | 801 | @node Global Variables |
e505224d PB |
802 | @section Global Variables |
803 | ||
139741da RP |
804 | @table @strong |
805 | @item Directive: | |
806 | @code{.stabs} | |
807 | @item Type: | |
808 | @code{N_GSYM} | |
809 | @item Symbol Descriptor: | |
810 | @code{G} | |
811 | @end table | |
e505224d | 812 | |
139741da RP |
813 | Global variables are represented by the @code{N_GSYM} stab type. The symbol |
814 | descriptor, following the colon in the string field, is @samp{G}. Following | |
815 | the @samp{G} is a type reference or type definition. In this example it is a | |
816 | type reference to the basic C type, @code{char}. The first source line in | |
817 | @file{example2.c}, | |
e505224d PB |
818 | |
819 | @example | |
820 | 1 char g_foo = 'c'; | |
821 | @end example | |
822 | ||
139741da RP |
823 | @noindent |
824 | yields the following stab. The stab immediately precedes the code that | |
e505224d PB |
825 | allocates storage for the variable it describes. |
826 | ||
827 | @example | |
139741da RP |
828 | @exdent @code{N_GSYM} (32): global symbol |
829 | ||
830 | .stabs "@var{name}: | |
831 | @var{descriptor} | |
832 | @var{type-ref}", | |
833 | N_GSYM, NIL, NIL, NIL | |
e505224d | 834 | |
e505224d | 835 | 21 .stabs "g_foo:G2",32,0,0,0 |
139741da RP |
836 | 22 .global _g_foo |
837 | 23 .data | |
e505224d | 838 | 24 _g_foo: |
139741da | 839 | 25 .byte 99 |
e505224d PB |
840 | @end example |
841 | ||
139741da RP |
842 | The address of the variable represented by the @code{N_GSYM} is not contained |
843 | in the @code{N_GSYM} stab. The debugger gets this information from the | |
e505224d PB |
844 | external symbol for the global variable. |
845 | ||
899bafeb | 846 | @node Register variables |
139741da RP |
847 | @section Global register variables |
848 | ||
849 | @table @strong | |
850 | @item Directive: | |
851 | @code{.stabs} | |
852 | @item Type: | |
853 | @code{N_RSYM} | |
854 | @item Symbol Descriptor: | |
855 | @code{r} | |
856 | @end table | |
e505224d | 857 | |
139741da RP |
858 | The following source line defines a global variable, @code{g_bar}, which is |
859 | explicitly allocated in global register @code{%g5}. | |
e505224d PB |
860 | |
861 | @example | |
862 | 2 register int g_bar asm ("%g5"); | |
863 | @end example | |
864 | ||
139741da RP |
865 | Register variables have their own stab type, @code{N_RSYM}, and their own |
866 | symbol descriptor, @code{r}. The stab's value field contains the number of | |
e505224d PB |
867 | the register where the variable data will be stored. Since the |
868 | variable was not initialized in this compilation unit, the stab is | |
869 | emited at the end of the object file, with the stabs for other | |
139741da | 870 | uninitialized globals (@code{bcc}). |
e505224d PB |
871 | |
872 | @example | |
139741da RP |
873 | @exdent @code{N_RSYM} (64): register variable |
874 | ||
875 | .stabs "@var{name}: | |
876 | @var{descriptor} | |
877 | @var{type-ref}", | |
878 | N_RSYM, NIL, NIL, | |
879 | @var{register} | |
e505224d PB |
880 | |
881 | 133 .stabs "g_bar:r1",64,0,0,5 | |
882 | @end example | |
883 | ||
884 | ||
899bafeb | 885 | @node Initialized statics |
e505224d PB |
886 | @section Initialized static variables |
887 | ||
139741da RP |
888 | @table @strong |
889 | @item Directive: | |
890 | @code{.stabs} | |
891 | @item Type: | |
892 | @code{N_STSYM} | |
893 | @item Symbol Descriptors: | |
894 | @code{S} (file scope), @code{V} (procedure scope) | |
895 | @end table | |
e505224d | 896 | |
139741da RP |
897 | Initialized static variables are represented by the @code{N_STSYM} stab |
898 | type. The symbol descriptor part of the string field shows if the | |
899 | variable is file scope static (@samp{S}) or procedure scope static | |
900 | (@samp{V}). The source line | |
e505224d PB |
901 | |
902 | @example | |
903 | 3 static int s_g_repeat = 2; | |
904 | @end example | |
905 | ||
139741da RP |
906 | @noindent |
907 | yields the following code. The stab is located immediately preceding | |
e505224d | 908 | the storage for the variable it represents. Since the variable in |
139741da | 909 | this example is file scope static the symbol descriptor is @samp{S}. |
e505224d PB |
910 | |
911 | @example | |
139741da RP |
912 | @exdent @code{N_STSYM} (38): initialized static variable (data seg w/internal linkage) |
913 | ||
914 | .stabs "@var{name}: | |
915 | @var{descriptor} | |
916 | @var{type-ref}", | |
917 | N_STSYM,NIL,NIL, | |
918 | @var{address} | |
919 | ||
e505224d | 920 | 26 .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat |
139741da | 921 | 27 .align 4 |
e505224d | 922 | 28 _s_g_repeat: |
139741da | 923 | 29 .word 2 |
e505224d PB |
924 | @end example |
925 | ||
926 | ||
899bafeb | 927 | @node Un-initialized statics |
e505224d PB |
928 | @section Un-initialized static variables |
929 | ||
139741da RP |
930 | @table @strong |
931 | @item Directive: | |
932 | @code{.stabs} | |
933 | @item Type: | |
934 | @code{N_LCSYM} | |
935 | @item Symbol Descriptors: | |
936 | @code{S} (file scope), @code{V} (procedure scope) | |
937 | @end table | |
e505224d | 938 | |
139741da RP |
939 | Un-initialized static variables are represented by the @code{N_LCSYM} |
940 | stab type. The symbol descriptor part of the string shows if the | |
941 | variable is file scope static (@samp{S}) or procedure scope static | |
942 | (@samp{V}). In this example it is procedure scope static. The source | |
943 | line allocating @code{s_flap} immediately follows the open brace for the | |
944 | procedure @code{main}. | |
e505224d PB |
945 | |
946 | @example | |
947 | 20 @{ | |
948 | 21 static float s_flap; | |
949 | @end example | |
950 | ||
139741da RP |
951 | The code that reserves storage for the variable @code{s_flap} precedes the |
952 | body of body of @code{main}. | |
e505224d PB |
953 | |
954 | @example | |
139741da | 955 | 39 .reserve _s_flap.0,4,"bss",4 |
e505224d PB |
956 | @end example |
957 | ||
139741da RP |
958 | But since @code{s_flap} is scoped locally to @code{main}, its stab is |
959 | located with the other stabs representing symbols local to @code{main}. | |
960 | The stab for @code{s_flap} is located just before the @code{N_LBRAC} for | |
961 | @code{main}. | |
e505224d PB |
962 | |
963 | @example | |
139741da RP |
964 | @exdent @code{N_LCSYM} (40): uninitialized static var (BSS seg w/internal linkage) |
965 | ||
966 | .stabs "@var{name}: | |
967 | @var{descriptor} | |
968 | @var{type-ref}", | |
969 | N_LCSYM, NIL, NIL, | |
970 | @var{address} | |
e505224d | 971 | |
e505224d PB |
972 | 97 .stabs "s_flap:V12",40,0,0,_s_flap.0 |
973 | 98 .stabs "times:1",128,0,0,-20 | |
139741da | 974 | 99 .stabn 192,0,0,LBB2 # N_LBRAC for main. |
e505224d PB |
975 | @end example |
976 | ||
139741da RP |
977 | @c ............................................................ |
978 | ||
899bafeb | 979 | @node Parameters |
e505224d PB |
980 | @section Parameters |
981 | ||
139741da RP |
982 | @table @strong |
983 | @item Directive: | |
984 | @code{.stabs} | |
985 | @item Type: | |
986 | @code{N_PSYM} | |
987 | @item Symbol Descriptor: | |
988 | @code{p} | |
989 | @end table | |
e505224d PB |
990 | |
991 | Procedure parameters are represented by the N_PSYM stab type. The | |
992 | following source lines show the parameters of the main routine. | |
993 | ||
994 | @example | |
995 | 17 main (argc, argv) | |
996 | 18 int argc; | |
997 | 19 char* argv[]; | |
998 | 20 @{ | |
999 | @end example | |
1000 | ||
1001 | The N_PSYM stabs describing parameters to a function directly follow | |
1002 | the N_FUN stab that represents the procedure itself. The N_FUN stab | |
139741da | 1003 | immediately follows the code of the procedure it describes. Following |
e505224d PB |
1004 | the N_PSYM parameter stabs are any N_LSYM stabs representing local |
1005 | variables. | |
1006 | ||
e505224d | 1007 | @example |
899bafeb RP |
1008 | @exdent <36> N_FUN - describing the procedure main |
1009 | ||
e505224d PB |
1010 | 94 .stabs "main:F1",36,0,0,_main |
1011 | ||
899bafeb RP |
1012 | @exdent <160> N_PSYM - parameters |
1013 | @exdent .stabs "name:sym_desc(value_param)type_ref(int)", N_PSYM, | |
1014 | @exdent NIL, NIL, frame_ptr_offset | |
1015 | ||
e505224d PB |
1016 | 95 .stabs "argc:p1",160,0,0,68 |
1017 | ||
899bafeb RP |
1018 | @exdent <160> N_PSYM - parameter |
1019 | @exdent .stabs "name:sym_desc(value_param)type_def(20)=ptr_to type_def(21)= | |
1020 | @exdent ptr_to type_ref(char) | |
1021 | ||
e505224d PB |
1022 | 96 .stabs "argv:p20=*21=*2",160,0,0,72 |
1023 | @end example | |
1024 | ||
1025 | The type definition of argv is interesting because it defines two new | |
1026 | types in terms of an existing one. The array argv contains character | |
1027 | pointers. The type of the array name is a pointer to the type the | |
1028 | array holds. Thus the type of argv is ptr to ptr to char. The stab | |
1029 | for argv contains nested type_definitions. Type 21 is ptr to type 2 | |
1030 | (char) and argv (type 20) is ptr to type 21. | |
1031 | ||
899bafeb | 1032 | @node Aggregate Types |
e505224d PB |
1033 | @chapter Aggregate Types |
1034 | ||
612dbd4c | 1035 | Now let's look at some variable definitions involving complex types. |
e505224d PB |
1036 | This involves understanding better how types are described. In the |
1037 | examples so far types have been described as references to previously | |
1038 | defined types or defined in terms of subranges of or pointers to | |
1039 | previously defined types. The section that follows will talk about | |
1040 | the various other type descriptors that may follow the = sign in a | |
1041 | type definition. | |
1042 | ||
1043 | @menu | |
1044 | * Arrays:: | |
1045 | * Enumerations:: | |
1046 | * Structure tags:: | |
1047 | * Typedefs:: | |
1048 | * Unions:: | |
1049 | * Function types:: | |
1050 | @end menu | |
1051 | ||
899bafeb RP |
1052 | @node Arrays |
1053 | @section Array types | |
e505224d | 1054 | |
139741da RP |
1055 | @table @strong |
1056 | @item Directive: | |
1057 | @code{.stabs} | |
1058 | @item Types: | |
1059 | @code{N_GSYM}, @code{N_LSYM} | |
1060 | @item Symbol Descriptor: | |
1061 | @code{T} | |
1062 | @item Type Descriptor: | |
1063 | @code{ar} | |
1064 | @end table | |
e505224d PB |
1065 | |
1066 | As an example of an array type consider the global variable below. | |
1067 | ||
1068 | @example | |
1069 | 15 char char_vec[3] = @{'a','b','c'@}; | |
1070 | @end example | |
1071 | ||
1072 | Since the array is a global variable, it is described by the N_GSYM | |
1073 | stab type. The symbol descriptor G, following the colon in stab's | |
1074 | string field, also says the array is a global variable. Following the | |
1075 | G is a definition for type (19) as shown by the equals sign after the | |
1076 | type number. | |
1077 | ||
1078 | After the equals sign is a type descriptor, ar, which says that the | |
1079 | type being defined is an array. Following the type descriptor for an | |
1080 | array is the type of the index, a null field, the upper bound of the | |
1081 | array indexing, and the type of the array elements. | |
1082 | ||
1083 | The array definition above generates the assembly language that | |
1084 | follows. | |
1085 | ||
1086 | @example | |
899bafeb RP |
1087 | @exdent <32> N_GSYM - global variable |
1088 | @exdent .stabs "name:sym_desc(global)type_def(19)=type_desc(array) | |
1089 | @exdent index_type_ref(int);NIL;high_bound(2);element_type_ref(char)"; | |
1090 | @exdent N_GSYM, NIL, NIL, NIL | |
e505224d PB |
1091 | |
1092 | 32 .stabs "char_vec:G19=ar1;0;2;2",32,0,0,0 | |
139741da RP |
1093 | 33 .global _char_vec |
1094 | 34 .align 4 | |
e505224d | 1095 | 35 _char_vec: |
139741da RP |
1096 | 36 .byte 97 |
1097 | 37 .byte 98 | |
1098 | 38 .byte 99 | |
e505224d PB |
1099 | @end example |
1100 | ||
899bafeb | 1101 | @node Enumerations |
e505224d PB |
1102 | @section Enumerations |
1103 | ||
139741da RP |
1104 | @table @strong |
1105 | @item Directive: | |
1106 | @code{.stabs} | |
1107 | @item Type: | |
1108 | @code{N_LSYM} | |
1109 | @item Symbol Descriptor: | |
1110 | @code{T} | |
1111 | @item Type Descriptor: | |
1112 | @code{e} | |
1113 | @end table | |
e505224d PB |
1114 | |
1115 | The source line below declares an enumeration type. It is defined at | |
1116 | file scope between the bodies of main and s_proc in example2.c. | |
1117 | Because the N_LSYM is located after the N_RBRAC that marks the end of | |
1118 | the previous procedure's block scope, and before the N_FUN that marks | |
1119 | the beginning of the next procedure's block scope, the N_LSYM does not | |
1120 | describe a block local symbol, but a file local one. The source line: | |
1121 | ||
1122 | @example | |
1123 | 29 enum e_places @{first,second=3,last@}; | |
1124 | @end example | |
1125 | ||
899bafeb | 1126 | @noindent |
e505224d PB |
1127 | generates the following stab, located just after the N_RBRAC (close |
1128 | brace stab) for main. The type definition is in an N_LSYM stab | |
1129 | because type definitions are file scope not global scope. | |
1130 | ||
899bafeb | 1131 | @display |
e505224d PB |
1132 | <128> N_LSYM - local symbol |
1133 | .stab "name:sym_dec(type)type_def(22)=sym_desc(enum) | |
1134 | enum_name:value(0),enum_name:value(3),enum_name:value(4),;", | |
139741da | 1135 | N_LSYM, NIL, NIL, NIL |
899bafeb | 1136 | @end display |
e505224d | 1137 | |
899bafeb | 1138 | @example |
e505224d | 1139 | 104 .stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0 |
899bafeb | 1140 | @end example |
e505224d PB |
1141 | |
1142 | The symbol descriptor (T) says that the stab describes a structure, | |
1143 | enumeration, or type tag. The type descriptor e, following the 22= of | |
1144 | the type definition narrows it down to an enumeration type. Following | |
1145 | the e is a list of the elements of the enumeration. The format is | |
1146 | name:value,. The list of elements ends with a ;. | |
1147 | ||
899bafeb | 1148 | @node Structure tags |
e505224d PB |
1149 | @section Structure Tags |
1150 | ||
139741da RP |
1151 | @table @strong |
1152 | @item Directive: | |
1153 | @code{.stabs} | |
1154 | @item Type: | |
1155 | @code{N_LSYM} | |
1156 | @item Symbol Descriptor: | |
1157 | @code{T} | |
1158 | @item Type Descriptor: | |
1159 | @code{s} | |
1160 | @end table | |
e505224d PB |
1161 | |
1162 | The following source code declares a structure tag and defines an | |
1163 | instance of the structure in global scope. Then a typedef equates the | |
1164 | structure tag with a new type. A seperate stab is generated for the | |
1165 | structure tag, the structure typedef, and the structure instance. The | |
1166 | stabs for the tag and the typedef are emited when the definitions are | |
1167 | encountered. Since the structure elements are not initialized, the | |
1168 | stab and code for the structure variable itself is located at the end | |
1169 | of the program in .common. | |
1170 | ||
1171 | @example | |
1172 | 6 struct s_tag @{ | |
1173 | 7 int s_int; | |
1174 | 8 float s_float; | |
1175 | 9 char s_char_vec[8]; | |
1176 | 10 struct s_tag* s_next; | |
1177 | 11 @} g_an_s; | |
1178 | 12 | |
1179 | 13 typedef struct s_tag s_typedef; | |
1180 | @end example | |
1181 | ||
1182 | The structure tag is an N_LSYM stab type because, like the enum, the | |
1183 | symbol is file scope. Like the enum, the symbol descriptor is T, for | |
1184 | enumeration, struct or tag type. The symbol descriptor s following | |
1185 | the 16= of the type definition narrows the symbol type to struct. | |
1186 | ||
1187 | Following the struct symbol descriptor is the number of bytes the | |
1188 | struct occupies, followed by a description of each structure element. | |
1189 | The structure element descriptions are of the form name:type, bit | |
1190 | offset from the start of the struct, and number of bits in the | |
1191 | element. | |
1192 | ||
1193 | ||
612dbd4c | 1194 | @example |
e505224d PB |
1195 | <128> N_LSYM - type definition |
1196 | .stabs "name:sym_desc(struct tag) Type_def(16)=type_desc(struct type) | |
139741da | 1197 | struct_bytes |
e505224d | 1198 | elem_name:type_ref(int),bit_offset,field_bits; |
139741da RP |
1199 | elem_name:type_ref(float),bit_offset,field_bits; |
1200 | elem_name:type_def(17)=type_desc(dynamic array) index_type(int);NIL; | |
1201 | high_bound(7);element_type(char),bit_offset,field_bits;;", | |
1202 | N_LSYM,NIL,NIL,NIL | |
e505224d PB |
1203 | |
1204 | 30 .stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32; | |
139741da | 1205 | s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0 |
612dbd4c | 1206 | @end example |
e505224d PB |
1207 | |
1208 | In this example, two of the structure elements are previously defined | |
1209 | types. For these, the type following the name: part of the element | |
1210 | description is a simple type reference. The other two structure | |
1211 | elements are new types. In this case there is a type definition | |
1212 | embedded after the name:. The type definition for the array element | |
1213 | looks just like a type definition for a standalone array. The s_next | |
1214 | field is a pointer to the same kind of structure that the field is an | |
1215 | element of. So the definition of structure type 16 contains an type | |
1216 | definition for an element which is a pointer to type 16. | |
1217 | ||
899bafeb | 1218 | @node Typedefs |
e505224d PB |
1219 | @section Typedefs |
1220 | ||
139741da RP |
1221 | @table @strong |
1222 | @item Directive: | |
1223 | @code{.stabs} | |
1224 | @item Type: | |
1225 | @code{N_LSYM} | |
1226 | @item Symbol Descriptor: | |
1227 | @code{t} | |
1228 | @end table | |
e505224d PB |
1229 | |
1230 | Here is the stab for the typedef equating the structure tag with a | |
1231 | type. | |
1232 | ||
899bafeb | 1233 | @display |
e505224d PB |
1234 | <128> N_LSYM - type definition |
1235 | .stabs "name:sym_desc(type name)type_ref(struct_tag)",N_LSYM,NIL,NIL,NIL | |
899bafeb | 1236 | @end display |
e505224d | 1237 | |
899bafeb | 1238 | @example |
e505224d | 1239 | 31 .stabs "s_typedef:t16",128,0,0,0 |
899bafeb | 1240 | @end example |
e505224d PB |
1241 | |
1242 | And here is the code generated for the structure variable. | |
1243 | ||
899bafeb | 1244 | @display |
e505224d PB |
1245 | <32> N_GSYM - global symbol |
1246 | .stabs "name:sym_desc(global)type_ref(struct_tag)",N_GSYM,NIL,NIL,NIL | |
899bafeb | 1247 | @end display |
e505224d PB |
1248 | |
1249 | @example | |
1250 | 136 .stabs "g_an_s:G16",32,0,0,0 | |
139741da | 1251 | 137 .common _g_an_s,20,"bss" |
e505224d PB |
1252 | @end example |
1253 | ||
1254 | Notice that the structure tag has the same type number as the typedef | |
1255 | for the structure tag. It is impossible to distinguish between a | |
1256 | variable of the struct type and one of its typedef by looking at the | |
1257 | debugging information. | |
1258 | ||
1259 | ||
899bafeb | 1260 | @node Unions |
e505224d PB |
1261 | @section Unions |
1262 | ||
139741da RP |
1263 | @table @strong |
1264 | @item Directive: | |
1265 | @code{.stabs} | |
1266 | @item Type: | |
1267 | @code{N_LSYM} | |
1268 | @item Symbol Descriptor: | |
1269 | @code{T} | |
1270 | @item Type Descriptor: | |
1271 | @code{u} | |
1272 | @end table | |
e505224d | 1273 | |
612dbd4c | 1274 | Next let's look at unions. In example2 this union type is declared |
e505224d PB |
1275 | locally to a procedure and an instance of the union is defined. |
1276 | ||
1277 | @example | |
1278 | 36 union u_tag @{ | |
1279 | 37 int u_int; | |
1280 | 38 float u_float; | |
1281 | 39 char* u_char; | |
1282 | 40 @} an_u; | |
1283 | @end example | |
1284 | ||
1285 | This code generates a stab for the union tag and a stab for the union | |
1286 | variable. Both use the N_LSYM stab type. Since the union variable is | |
1287 | scoped locally to the procedure in which it is defined, its stab is | |
139741da | 1288 | located immediately preceding the N_LBRAC for the procedure's block |
e505224d PB |
1289 | start. |
1290 | ||
139741da | 1291 | The stab for the union tag, however is located preceding the code for |
e505224d PB |
1292 | the procedure in which it is defined. The stab type is N_LSYM. This |
1293 | would seem to imply that the union type is file scope, like the struct | |
1294 | type s_tag. This is not true. The contents and position of the stab | |
1295 | for u_type do not convey any infomation about its procedure local | |
1296 | scope. | |
1297 | ||
899bafeb | 1298 | @display |
e505224d PB |
1299 | <128> N_LSYM - type |
1300 | .stabs "name:sym_desc(union tag)type_def(22)=type_desc(union) | |
1301 | byte_size(4) | |
1302 | elem_name:type_ref(int),bit_offset(0),bit_size(32); | |
1303 | elem_name:type_ref(float),bit_offset(0),bit_size(32); | |
1304 | elem_name:type_ref(ptr to char),bit_offset(0),bit_size(32);;" | |
1305 | N_LSYM, NIL, NIL, NIL | |
899bafeb | 1306 | @end display |
e505224d | 1307 | |
5bc927fb RP |
1308 | @smallexample |
1309 | 105 .stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;", | |
1310 | 128,0,0,0 | |
1311 | @end smallexample | |
e505224d PB |
1312 | |
1313 | The symbol descriptor, T, following the name: means that the stab | |
1314 | describes an enumeration struct or type tag. The type descriptor u, | |
1315 | following the 23= of the type definition, narrows it down to a union | |
1316 | type definition. Following the u is the number of bytes in the union. | |
1317 | After that is a list of union element descriptions. Their format is | |
1318 | name:type, bit offset into the union, and number of bytes for the | |
1319 | element;. | |
1320 | ||
1321 | The stab for the union variable follows. Notice that the frame | |
1322 | pointer offset for local variables is negative. | |
1323 | ||
899bafeb | 1324 | @display |
e505224d PB |
1325 | <128> N_LSYM - local variable (with no symbol descriptor) |
1326 | .stabs "name:type_ref(u_tag)", N_LSYM, NIL, NIL, frame_ptr_offset | |
899bafeb | 1327 | @end display |
e505224d | 1328 | |
899bafeb | 1329 | @example |
e505224d | 1330 | 130 .stabs "an_u:23",128,0,0,-20 |
899bafeb | 1331 | @end example |
e505224d | 1332 | |
899bafeb | 1333 | @node Function types |
e505224d PB |
1334 | @section Function types |
1335 | ||
899bafeb | 1336 | @display |
e505224d | 1337 | type descriptor f |
899bafeb | 1338 | @end display |
e505224d PB |
1339 | |
1340 | The last type descriptor in C which remains to be described is used | |
1341 | for function types. Consider the following source line defining a | |
1342 | global function pointer. | |
1343 | ||
1344 | @example | |
1345 | 4 int (*g_pf)(); | |
1346 | @end example | |
1347 | ||
1348 | It generates the following code. Since the variable is not | |
1349 | initialized, the code is located in the common area at the end of the | |
1350 | file. | |
1351 | ||
899bafeb | 1352 | @display |
e505224d PB |
1353 | <32> N_GSYM - global variable |
1354 | .stabs "name:sym_desc(global)type_def(24)=ptr_to(25)= | |
139741da | 1355 | type_def(func)type_ref(int) |
899bafeb | 1356 | @end display |
e505224d | 1357 | |
899bafeb | 1358 | @example |
e505224d | 1359 | 134 .stabs "g_pf:G24=*25=f1",32,0,0,0 |
139741da | 1360 | 135 .common _g_pf,4,"bss" |
899bafeb | 1361 | @end example |
e505224d PB |
1362 | |
1363 | Since the variable is global, the stab type is N_GSYM and the symbol | |
1364 | descriptor is G. The variable defines a new type, 24, which is a | |
1365 | pointer to another new type, 25, which is defined as a function | |
1366 | returning int. | |
1367 | ||
899bafeb | 1368 | @node Symbol tables |
e505224d PB |
1369 | @chapter Symbol information in symbol tables |
1370 | ||
1371 | This section examines more closely the format of symbol table entries | |
1372 | and how stab assembler directives map to them. It also describes what | |
1373 | transformations the assembler and linker make on data from stabs. | |
1374 | ||
1375 | Each time the assembler encounters a stab in its input file it puts | |
1376 | each field of the stab into corresponding fields in a symbol table | |
1377 | entry of its output file. If the stab contains a string field, the | |
1378 | symbol table entry for that stab points to a string table entry | |
1379 | containing the string data from the stab. Assembler labels become | |
1380 | relocatable addresses. Symbol table entries in a.out have the format: | |
1381 | ||
1382 | @example | |
1383 | struct internal_nlist @{ | |
139741da RP |
1384 | unsigned long n_strx; /* index into string table of name */ |
1385 | unsigned char n_type; /* type of symbol */ | |
1386 | unsigned char n_other; /* misc info (usually empty) */ | |
1387 | unsigned short n_desc; /* description field */ | |
1388 | bfd_vma n_value; /* value of symbol */ | |
e505224d PB |
1389 | @}; |
1390 | @end example | |
1391 | ||
1392 | For .stabs directives, the n_strx field holds the character offset | |
1393 | from the start of the string table to the string table entry | |
1394 | containing the "string" field. For other classes of stabs (.stabn and | |
1395 | .stabd) this field is null. | |
1396 | ||
1397 | Symbol table entries with n_type fields containing a value greater or | |
1398 | equal to 0x20 originated as stabs generated by the compiler (with one | |
1399 | random exception). Those with n_type values less than 0x20 were | |
1400 | placed in the symbol table of the executable by the assembler or the | |
1401 | linker. | |
1402 | ||
1403 | The linker concatenates object files and does fixups of externally | |
1404 | defined symbols. You can see the transformations made on stab data by | |
1405 | the assembler and linker by examining the symbol table after each pass | |
1406 | of the build, first the assemble and then the link. | |
1407 | ||
1408 | To do this use nm with the -ap options. This dumps the symbol table, | |
1409 | including debugging information, unsorted. For stab entries the | |
1410 | columns are: value, other, desc, type, string. For assembler and | |
1411 | linker symbols, the columns are: value, type, string. | |
1412 | ||
1413 | There are a few important things to notice about symbol tables. Where | |
1414 | the value field of a stab contains a frame pointer offset, or a | |
1415 | register number, that value is unchanged by the rest of the build. | |
1416 | ||
1417 | Where the value field of a stab contains an assembly language label, | |
1418 | it is transformed by each build step. The assembler turns it into a | |
1419 | relocatable address and the linker turns it into an absolute address. | |
1420 | This source line defines a static variable at file scope: | |
1421 | ||
899bafeb | 1422 | @example |
e505224d | 1423 | 3 static int s_g_repeat |
899bafeb | 1424 | @end example |
e505224d | 1425 | |
899bafeb | 1426 | @noindent |
e505224d PB |
1427 | The following stab describes the symbol. |
1428 | ||
899bafeb | 1429 | @example |
e505224d | 1430 | 26 .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat |
899bafeb | 1431 | @end example |
e505224d | 1432 | |
899bafeb | 1433 | @noindent |
e505224d | 1434 | The assembler transforms the stab into this symbol table entry in the |
899bafeb | 1435 | @file{.o} file. The location is expressed as a data segment offset. |
e505224d | 1436 | |
899bafeb | 1437 | @example |
e505224d | 1438 | 21 00000084 - 00 0000 STSYM s_g_repeat:S1 |
899bafeb | 1439 | @end example |
e505224d | 1440 | |
899bafeb | 1441 | @noindent |
e505224d PB |
1442 | in the symbol table entry from the executable, the linker has made the |
1443 | relocatable address absolute. | |
1444 | ||
899bafeb | 1445 | @example |
e505224d | 1446 | 22 0000e00c - 00 0000 STSYM s_g_repeat:S1 |
899bafeb | 1447 | @end example |
e505224d PB |
1448 | |
1449 | Stabs for global variables do not contain location information. In | |
1450 | this case the debugger finds location information in the assembler or | |
1451 | linker symbol table entry describing the variable. The source line: | |
1452 | ||
899bafeb | 1453 | @example |
e505224d | 1454 | 1 char g_foo = 'c'; |
899bafeb | 1455 | @end example |
e505224d | 1456 | |
899bafeb | 1457 | @noindent |
e505224d PB |
1458 | generates the stab: |
1459 | ||
899bafeb | 1460 | @example |
e505224d | 1461 | 21 .stabs "g_foo:G2",32,0,0,0 |
899bafeb | 1462 | @end example |
e505224d PB |
1463 | |
1464 | The variable is represented by the following two symbol table entries | |
1465 | in the object file. The first one originated as a stab. The second | |
1466 | one is an external symbol. The upper case D signifies that the n_type | |
1467 | field of the symbol table contains 7, N_DATA with local linkage (see | |
1468 | Table B). The value field following the file's line number is empty | |
1469 | for the stab entry. For the linker symbol it contains the | |
1470 | rellocatable address corresponding to the variable. | |
1471 | ||
899bafeb | 1472 | @example |
e505224d PB |
1473 | 19 00000000 - 00 0000 GSYM g_foo:G2 |
1474 | 20 00000080 D _g_foo | |
899bafeb | 1475 | @end example |
e505224d | 1476 | |
899bafeb | 1477 | @noindent |
e505224d PB |
1478 | These entries as transformed by the linker. The linker symbol table |
1479 | entry now holds an absolute address. | |
1480 | ||
899bafeb | 1481 | @example |
e505224d | 1482 | 21 00000000 - 00 0000 GSYM g_foo:G2 |
899bafeb | 1483 | @dots{} |
e505224d | 1484 | 215 0000e008 D _g_foo |
899bafeb | 1485 | @end example |
e505224d | 1486 | |
899bafeb | 1487 | @node GNU C++ stabs |
612dbd4c | 1488 | @chapter GNU C++ stabs |
e505224d PB |
1489 | |
1490 | @menu | |
1491 | * Basic C++ types:: | |
1492 | * Simple classes:: | |
1493 | * Class instance:: | |
1494 | * Methods:: Method definition | |
1495 | * Protections:: | |
2dd00294 JG |
1496 | * Method Modifiers:: (const, volatile, const volatile) |
1497 | * Virtual Methods:: | |
1498 | * Inheritence:: | |
1499 | * Virtual Base Classes:: | |
1500 | * Static Members:: | |
e505224d PB |
1501 | @end menu |
1502 | ||
1503 | ||
1504 | @subsection Symbol descriptors added for C++ descriptions: | |
1505 | ||
899bafeb | 1506 | @display |
e505224d | 1507 | P - register parameter. |
899bafeb | 1508 | @end display |
e505224d PB |
1509 | |
1510 | @subsection type descriptors added for C++ descriptions | |
1511 | ||
1512 | @table @code | |
1513 | @item # | |
1514 | method type (two ## if minimal debug) | |
1515 | ||
1516 | @item xs | |
1517 | cross-reference | |
1518 | @end table | |
1519 | ||
2dd00294 | 1520 | |
899bafeb | 1521 | @node Basic C++ types |
e505224d PB |
1522 | @section Basic types for C++ |
1523 | ||
1524 | << the examples that follow are based on a01.C >> | |
1525 | ||
1526 | ||
1527 | C++ adds two more builtin types to the set defined for C. These are | |
1528 | the unknown type and the vtable record type. The unknown type, type | |
1529 | 16, is defined in terms of itself like the void type. | |
1530 | ||
1531 | The vtable record type, type 17, is defined as a structure type and | |
1532 | then as a structure tag. The structure has four fields, delta, index, | |
1533 | pfn, and delta2. pfn is the function pointer. | |
1534 | ||
1535 | << In boilerplate $vtbl_ptr_type, what are the fields delta, | |
1536 | index, and delta2 used for? >> | |
1537 | ||
1538 | This basic type is present in all C++ programs even if there are no | |
1539 | virtual methods defined. | |
1540 | ||
899bafeb | 1541 | @display |
e505224d | 1542 | .stabs "struct_name:sym_desc(type)type_def(17)=type_desc(struct)struct_bytes(8) |
139741da RP |
1543 | elem_name(delta):type_ref(short int),bit_offset(0),field_bits(16); |
1544 | elem_name(index):type_ref(short int),bit_offset(16),field_bits(16); | |
1545 | elem_name(pfn):type_def(18)=type_desc(ptr to)type_ref(void), | |
1546 | bit_offset(32),field_bits(32); | |
1547 | elem_name(delta2):type_def(short int);bit_offset(32),field_bits(16);;" | |
1548 | N_LSYM, NIL, NIL | |
899bafeb | 1549 | @end display |
139741da | 1550 | |
899bafeb | 1551 | @smallexample |
e505224d | 1552 | .stabs "$vtbl_ptr_type:t17=s8 |
139741da RP |
1553 | delta:6,0,16;index:6,16,16;pfn:18=*15,32,32;delta2:6,32,16;;" |
1554 | ,128,0,0,0 | |
899bafeb | 1555 | @end smallexample |
e505224d | 1556 | |
899bafeb | 1557 | @display |
e505224d | 1558 | .stabs "name:sym_dec(struct tag)type_ref($vtbl_ptr_type)",N_LSYM,NIL,NIL,NIL |
899bafeb | 1559 | @end display |
e505224d | 1560 | |
899bafeb | 1561 | @example |
e505224d | 1562 | .stabs "$vtbl_ptr_type:T17",128,0,0,0 |
899bafeb | 1563 | @end example |
e505224d | 1564 | |
899bafeb | 1565 | @node Simple classes |
e505224d PB |
1566 | @section Simple class definition |
1567 | ||
1568 | The stabs describing C++ language features are an extension of the | |
1569 | stabs describing C. Stabs representing C++ class types elaborate | |
1570 | extensively on the stab format used to describe structure types in C. | |
1571 | Stabs representing class type variables look just like stabs | |
1572 | representing C language variables. | |
1573 | ||
1574 | Consider the following very simple class definition. | |
1575 | ||
1576 | @example | |
1577 | class baseA @{ | |
1578 | public: | |
139741da RP |
1579 | int Adat; |
1580 | int Ameth(int in, char other); | |
e505224d PB |
1581 | @}; |
1582 | @end example | |
1583 | ||
1584 | The class baseA is represented by two stabs. The first stab describes | |
1585 | the class as a structure type. The second stab describes a structure | |
1586 | tag of the class type. Both stabs are of stab type N_LSYM. Since the | |
1587 | stab is not located between an N_FUN and a N_LBRAC stab this indicates | |
1588 | that the class is defined at file scope. If it were, then the N_LSYM | |
1589 | would signify a local variable. | |
1590 | ||
1591 | A stab describing a C++ class type is similar in format to a stab | |
1592 | describing a C struct, with each class member shown as a field in the | |
1593 | structure. The part of the struct format describing fields is | |
1594 | expanded to include extra information relevent to C++ class members. | |
1595 | In addition, if the class has multiple base classes or virtual | |
1596 | functions the struct format outside of the field parts is also | |
1597 | augmented. | |
1598 | ||
1599 | In this simple example the field part of the C++ class stab | |
1600 | representing member data looks just like the field part of a C struct | |
1601 | stab. The section on protections describes how its format is | |
1602 | sometimes extended for member data. | |
1603 | ||
1604 | The field part of a C++ class stab representing a member function | |
1605 | differs substantially from the field part of a C struct stab. It | |
1606 | still begins with `name:' but then goes on to define a new type number | |
1607 | for the member function, describe its return type, its argument types, | |
1608 | its protection level, any qualifiers applied to the method definition, | |
1609 | and whether the method is virtual or not. If the method is virtual | |
1610 | then the method description goes on to give the vtable index of the | |
1611 | method, and the type number of the first base class defining the | |
1612 | method. | |
1613 | ||
1614 | When the field name is a method name it is followed by two colons | |
1615 | rather than one. This is followed by a new type definition for the | |
1616 | method. This is a number followed by an equal sign and then the | |
1617 | symbol descriptor `##', indicating a method type. This is followed by | |
1618 | a type reference showing the return type of the method and a | |
1619 | semi-colon. | |
1620 | ||
1621 | The format of an overloaded operator method name differs from that | |
1622 | of other methods. It is "op$::XXXX." where XXXX is the operator name | |
612dbd4c JG |
1623 | such as + or +=. The name ends with a period, and any characters except |
1624 | the period can occur in the XXXX string. | |
e505224d PB |
1625 | |
1626 | The next part of the method description represents the arguments to | |
1627 | the method, preceeded by a colon and ending with a semi-colon. The | |
1628 | types of the arguments are expressed in the same way argument types | |
1629 | are expressed in C++ name mangling. In this example an int and a char | |
1630 | map to `ic'. | |
1631 | ||
1632 | This is followed by a number, a letter, and an asterisk or period, | |
1633 | followed by another semicolon. The number indicates the protections | |
1634 | that apply to the member function. Here the 2 means public. The | |
1635 | letter encodes any qualifier applied to the method definition. In | |
1636 | this case A means that it is a normal function definition. The dot | |
1637 | shows that the method is not virtual. The sections that follow | |
1638 | elaborate further on these fields and describe the additional | |
1639 | information present for virtual methods. | |
1640 | ||
1641 | ||
899bafeb | 1642 | @display |
e505224d | 1643 | .stabs "class_name:sym_desc(type)type_def(20)=type_desc(struct)struct_bytes(4) |
139741da | 1644 | field_name(Adat):type(int),bit_offset(0),field_bits(32); |
e505224d | 1645 | |
139741da RP |
1646 | method_name(Ameth)::type_def(21)=type_desc(method)return_type(int); |
1647 | :arg_types(int char); | |
1648 | protection(public)qualifier(normal)virtual(no);;" | |
1649 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 1650 | @end display |
e505224d | 1651 | |
899bafeb | 1652 | @smallexample |
e505224d PB |
1653 | .stabs "baseA:t20=s4Adat:1,0,32;Ameth::21=##1;:ic;2A.;;",128,0,0,0 |
1654 | ||
1655 | .stabs "class_name:sym_desc(struct tag)",N_LSYM,NIL,NIL,NIL | |
1656 | ||
1657 | .stabs "baseA:T20",128,0,0,0 | |
899bafeb | 1658 | @end smallexample |
e505224d | 1659 | |
899bafeb | 1660 | @node Class instance |
e505224d PB |
1661 | @section Class instance |
1662 | ||
1663 | As shown above, describing even a simple C++ class definition is | |
1664 | accomplished by massively extending the stab format used in C to | |
1665 | describe structure types. However, once the class is defined, C stabs | |
1666 | with no modifications can be used to describe class instances. The | |
1667 | following source: | |
1668 | ||
1669 | @example | |
1670 | main () @{ | |
139741da | 1671 | baseA AbaseA; |
e505224d PB |
1672 | @} |
1673 | @end example | |
1674 | ||
899bafeb RP |
1675 | @noindent |
1676 | yields the following stab describing the class instance. It looks no | |
e505224d PB |
1677 | different from a standard C stab describing a local variable. |
1678 | ||
899bafeb | 1679 | @display |
e505224d | 1680 | .stabs "name:type_ref(baseA)", N_LSYM, NIL, NIL, frame_ptr_offset |
899bafeb | 1681 | @end display |
e505224d | 1682 | |
899bafeb | 1683 | @example |
e505224d | 1684 | .stabs "AbaseA:20",128,0,0,-20 |
899bafeb | 1685 | @end example |
e505224d | 1686 | |
899bafeb | 1687 | @node Methods |
e505224d PB |
1688 | @section Method defintion |
1689 | ||
1690 | The class definition shown above declares Ameth. The C++ source below | |
1691 | defines Ameth: | |
1692 | ||
1693 | @example | |
1694 | int | |
1695 | baseA::Ameth(int in, char other) | |
1696 | @{ | |
139741da | 1697 | return in; |
e505224d PB |
1698 | @}; |
1699 | @end example | |
1700 | ||
1701 | ||
1702 | This method definition yields three stabs following the code of the | |
1703 | method. One stab describes the method itself and following two | |
1704 | describe its parameters. Although there is only one formal argument | |
1705 | all methods have an implicit argument which is the `this' pointer. | |
1706 | The `this' pointer is a pointer to the object on which the method was | |
1707 | called. Note that the method name is mangled to encode the class name | |
1708 | and argument types. << Name mangling is not described by this | |
1709 | document - Is there already such a doc? >> | |
1710 | ||
612dbd4c | 1711 | @example |
e505224d | 1712 | .stabs "name:symbol_desriptor(global function)return_type(int)", |
139741da | 1713 | N_FUN, NIL, NIL, code_addr_of_method_start |
e505224d PB |
1714 | |
1715 | .stabs "Ameth__5baseAic:F1",36,0,0,_Ameth__5baseAic | |
612dbd4c | 1716 | @end example |
e505224d PB |
1717 | |
1718 | Here is the stab for the `this' pointer implicit argument. The name | |
1719 | of the `this' pointer is always $t. Type 19, the `this' pointer is | |
1720 | defined as a pointer to type 20, baseA, but a stab defining baseA has | |
1721 | not yet been emited. Since the compiler knows it will be emited | |
1722 | shortly, here it just outputs a cross reference to the undefined | |
1723 | symbol, by prefixing the symbol name with xs. | |
1724 | ||
612dbd4c | 1725 | @example |
e505224d | 1726 | .stabs "name:sym_desc(register param)type_def(19)= |
139741da | 1727 | type_desc(ptr to)type_ref(baseA)= |
e505224d PB |
1728 | type_desc(cross-reference to)baseA:",N_RSYM,NIL,NIL,register_number |
1729 | ||
1730 | .stabs "$t:P19=*20=xsbaseA:",64,0,0,8 | |
612dbd4c | 1731 | @end example |
e505224d PB |
1732 | |
1733 | The stab for the explicit integer argument looks just like a parameter | |
1734 | to a C function. The last field of the stab is the offset from the | |
1735 | argument pointer, which in most systems is the same as the frame | |
1736 | pointer. | |
1737 | ||
612dbd4c | 1738 | @example |
e505224d | 1739 | .stabs "name:sym_desc(value parameter)type_ref(int)", |
139741da | 1740 | N_PSYM,NIL,NIL,offset_from_arg_ptr |
e505224d PB |
1741 | |
1742 | .stabs "in:p1",160,0,0,72 | |
612dbd4c | 1743 | @end example |
e505224d PB |
1744 | |
1745 | << The examples that follow are based on A1.C >> | |
1746 | ||
899bafeb | 1747 | @node Protections |
e505224d PB |
1748 | @section Protections |
1749 | ||
1750 | ||
1751 | In the simple class definition shown above all member data and | |
1752 | functions were publicly accessable. The example that follows | |
1753 | contrasts public, protected and privately accessable fields and shows | |
1754 | how these protections are encoded in C++ stabs. | |
1755 | ||
1756 | Protections for class member data are signified by two characters | |
1757 | embeded in the stab defining the class type. These characters are | |
1758 | located after the name: part of the string. /0 means private, /1 | |
1759 | means protected, and /2 means public. If these characters are omited | |
1760 | this means that the member is public. The following C++ source: | |
1761 | ||
1762 | @example | |
1763 | class all_data @{ | |
139741da RP |
1764 | private: |
1765 | int priv_dat; | |
e505224d | 1766 | protected: |
139741da | 1767 | char prot_dat; |
e505224d | 1768 | public: |
139741da | 1769 | float pub_dat; |
e505224d PB |
1770 | @}; |
1771 | @end example | |
1772 | ||
899bafeb | 1773 | @noindent |
e505224d PB |
1774 | generates the following stab to describe the class type all_data. |
1775 | ||
899bafeb | 1776 | @display |
e505224d | 1777 | .stabs "class_name:sym_desc(type)type_def(19)=type_desc(struct)struct_bytes |
139741da RP |
1778 | data_name:/protection(private)type_ref(int),bit_offset,num_bits; |
1779 | data_name:/protection(protected)type_ref(char),bit_offset,num_bits; | |
1780 | data_name:(/num omited, private)type_ref(float),bit_offset,num_bits;;" | |
1781 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 1782 | @end display |
e505224d | 1783 | |
899bafeb | 1784 | @smallexample |
e505224d | 1785 | .stabs "all_data:t19=s12 |
139741da | 1786 | priv_dat:/01,0,32;prot_dat:/12,32,8;pub_dat:12,64,32;;",128,0,0,0 |
899bafeb | 1787 | @end smallexample |
e505224d PB |
1788 | |
1789 | Protections for member functions are signified by one digit embeded in | |
1790 | the field part of the stab describing the method. The digit is 0 if | |
1791 | private, 1 if protected and 2 if public. Consider the C++ class | |
1792 | definition below: | |
1793 | ||
1794 | @example | |
1795 | class all_methods @{ | |
1796 | private: | |
139741da | 1797 | int priv_meth(int in)@{return in;@}; |
e505224d | 1798 | protected: |
139741da | 1799 | char protMeth(char in)@{return in;@}; |
e505224d | 1800 | public: |
139741da | 1801 | float pubMeth(float in)@{return in;@}; |
e505224d PB |
1802 | @}; |
1803 | @end example | |
1804 | ||
1805 | It generates the following stab. The digit in question is to the left | |
1806 | of an `A' in each case. Notice also that in this case two symbol | |
1807 | descriptors apply to the class name struct tag and struct type. | |
1808 | ||
899bafeb | 1809 | @display |
e505224d | 1810 | .stabs "class_name:sym_desc(struct tag&type)type_def(21)= |
139741da RP |
1811 | sym_desc(struct)struct_bytes(1) |
1812 | meth_name::type_def(22)=sym_desc(method)returning(int); | |
1813 | :args(int);protection(private)modifier(normal)virtual(no); | |
1814 | meth_name::type_def(23)=sym_desc(method)returning(char); | |
1815 | :args(char);protection(protected)modifier(normal)virual(no); | |
1816 | meth_name::type_def(24)=sym_desc(method)returning(float); | |
1817 | :args(float);protection(public)modifier(normal)virtual(no);;", | |
1818 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 1819 | @end display |
139741da | 1820 | |
899bafeb | 1821 | @smallexample |
e505224d | 1822 | .stabs "all_methods:Tt21=s1priv_meth::22=##1;:i;0A.;protMeth::23=##2;:c;1A.; |
139741da | 1823 | pubMeth::24=##12;:f;2A.;;",128,0,0,0 |
899bafeb | 1824 | @end smallexample |
e505224d | 1825 | |
899bafeb RP |
1826 | @node Method Modifiers |
1827 | @section Method Modifiers (const, volatile, const volatile) | |
e505224d PB |
1828 | |
1829 | << based on a6.C >> | |
1830 | ||
1831 | In the class example described above all the methods have the normal | |
1832 | modifier. This method modifier information is located just after the | |
1833 | protection information for the method. This field has four possible | |
1834 | character values. Normal methods use A, const methods use B, volatile | |
1835 | methods use C, and const volatile methods use D. Consider the class | |
1836 | definition below: | |
1837 | ||
1838 | @example | |
1839 | class A @{ | |
1840 | public: | |
139741da RP |
1841 | int ConstMeth (int arg) const @{ return arg; @}; |
1842 | char VolatileMeth (char arg) volatile @{ return arg; @}; | |
1843 | float ConstVolMeth (float arg) const volatile @{return arg; @}; | |
e505224d PB |
1844 | @}; |
1845 | @end example | |
1846 | ||
1847 | This class is described by the following stab: | |
1848 | ||
899bafeb | 1849 | @display |
e505224d | 1850 | .stabs "class(A):sym_desc(struct)type_def(20)=type_desc(struct)struct_bytes(1) |
139741da RP |
1851 | meth_name(ConstMeth)::type_def(21)sym_desc(method) |
1852 | returning(int);:arg(int);protection(public)modifier(const)virtual(no); | |
1853 | meth_name(VolatileMeth)::type_def(22)=sym_desc(method) | |
1854 | returning(char);:arg(char);protection(public)modifier(volatile)virt(no) | |
1855 | meth_name(ConstVolMeth)::type_def(23)=sym_desc(method) | |
1856 | returning(float);:arg(float);protection(public)modifer(const volatile) | |
1857 | virtual(no);;", @dots{} | |
899bafeb | 1858 | @end display |
139741da | 1859 | |
899bafeb | 1860 | @example |
e505224d | 1861 | .stabs "A:T20=s1ConstMeth::21=##1;:i;2B.;VolatileMeth::22=##2;:c;2C.; |
139741da | 1862 | ConstVolMeth::23=##12;:f;2D.;;",128,0,0,0 |
612dbd4c | 1863 | @end example |
e505224d | 1864 | |
899bafeb | 1865 | @node Virtual Methods |
e505224d PB |
1866 | @section Virtual Methods |
1867 | ||
1868 | << The following examples are based on a4.C >> | |
1869 | ||
1870 | The presence of virtual methods in a class definition adds additional | |
1871 | data to the class description. The extra data is appended to the | |
1872 | description of the virtual method and to the end of the class | |
1873 | description. Consider the class definition below: | |
1874 | ||
1875 | @example | |
1876 | class A @{ | |
1877 | public: | |
139741da RP |
1878 | int Adat; |
1879 | virtual int A_virt (int arg) @{ return arg; @}; | |
e505224d PB |
1880 | @}; |
1881 | @end example | |
1882 | ||
1883 | This results in the stab below describing class A. It defines a new | |
1884 | type (20) which is an 8 byte structure. The first field of the class | |
1885 | struct is Adat, an integer, starting at structure offset 0 and | |
1886 | occupying 32 bits. | |
1887 | ||
1888 | The second field in the class struct is not explicitly defined by the | |
1889 | C++ class definition but is implied by the fact that the class | |
1890 | contains a virtual method. This field is the vtable pointer. The | |
1891 | name of the vtable pointer field starts with $vf and continues with a | |
1892 | type reference to the class it is part of. In this example the type | |
1893 | reference for class A is 20 so the name of its vtable pointer field is | |
1894 | $vf20, followed by the usual colon. | |
1895 | ||
1896 | Next there is a type definition for the vtable pointer type (21). | |
1897 | This is in turn defined as a pointer to another new type (22). | |
1898 | ||
1899 | Type 22 is the vtable itself, which is defined as an array, indexed by | |
1900 | integers, with a high bound of 1, and elements of type 17. Type 17 | |
1901 | was the vtable record type defined by the boilerplate C++ type | |
1902 | definitions, as shown earlier. | |
1903 | ||
1904 | The bit offset of the vtable pointer field is 32. The number of bits | |
1905 | in the field are not specified when the field is a vtable pointer. | |
1906 | ||
1907 | Next is the method definition for the virtual member function A_virt. | |
1908 | Its description starts out using the same format as the non-virtual | |
1909 | member functions described above, except instead of a dot after the | |
1910 | `A' there is an asterisk, indicating that the function is virtual. | |
1911 | Since is is virtual some addition information is appended to the end | |
1912 | of the method description. | |
1913 | ||
1914 | The first number represents the vtable index of the method. This is a | |
1915 | 32 bit unsigned number with the high bit set, followed by a | |
1916 | semi-colon. | |
1917 | ||
1918 | The second number is a type reference to the first base class in the | |
1919 | inheritence hierarchy defining the virtual member function. In this | |
1920 | case the class stab describes a base class so the virtual function is | |
1921 | not overriding any other definition of the method. Therefore the | |
1922 | reference is to the type number of the class that the stab is | |
1923 | describing (20). | |
1924 | ||
1925 | This is followed by three semi-colons. One marks the end of the | |
1926 | current sub-section, one marks the end of the method field, and the | |
1927 | third marks the end of the struct definition. | |
1928 | ||
1929 | For classes containing virtual functions the very last section of the | |
1930 | string part of the stab holds a type reference to the first base | |
1931 | class. This is preceeded by `~%' and followed by a final semi-colon. | |
1932 | ||
899bafeb | 1933 | @display |
e505224d | 1934 | .stabs "class_name(A):type_def(20)=sym_desc(struct)struct_bytes(8) |
139741da RP |
1935 | field_name(Adat):type_ref(int),bit_offset(0),field_bits(32); |
1936 | field_name(A virt func ptr):type_def(21)=type_desc(ptr to)type_def(22)= | |
1937 | sym_desc(array)index_type_ref(int);NIL;elem_type_ref(vtbl elem type); | |
1938 | bit_offset(32); | |
1939 | meth_name(A_virt)::typedef(23)=sym_desc(method)returning(int); | |
1940 | :arg_type(int),protection(public)normal(yes)virtual(yes) | |
1941 | vtable_index(1);class_first_defining(A);;;~%first_base(A);", | |
1942 | N_LSYM,NIL,NIL,NIL | |
899bafeb | 1943 | @end display |
e505224d | 1944 | |
899bafeb | 1945 | @example |
e505224d | 1946 | .stabs "A:t20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32;A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0 |
612dbd4c | 1947 | @end example |
e505224d | 1948 | |
2dd00294 JG |
1949 | @node Inheritence |
1950 | @section Inheritence | |
e505224d PB |
1951 | |
1952 | Stabs describing C++ derived classes include additional sections that | |
1953 | describe the inheritence hierarchy of the class. A derived class stab | |
1954 | also encodes the number of base classes. For each base class it tells | |
1955 | if the base class is virtual or not, and if the inheritence is private | |
1956 | or public. It also gives the offset into the object of the portion of | |
1957 | the object corresponding to each base class. | |
1958 | ||
1959 | This additional information is embeded in the class stab following the | |
1960 | number of bytes in the struct. First the number of base classes | |
1961 | appears bracketed by an exclamation point and a comma. | |
1962 | ||
1963 | Then for each base type there repeats a series: two digits, a number, | |
1964 | a comma, another number, and a semi-colon. | |
1965 | ||
1966 | The first of the two digits is 1 if the base class is virtual and 0 if | |
1967 | not. The second digit is 2 if the derivation is public and 0 if not. | |
1968 | ||
1969 | The number following the first two digits is the offset from the start | |
1970 | of the object to the part of the object pertaining to the base class. | |
1971 | ||
1972 | After the comma, the second number is a type_descriptor for the base | |
1973 | type. Finally a semi-colon ends the series, which repeats for each | |
1974 | base class. | |
1975 | ||
1976 | The source below defines three base classes A, B, and C and the | |
1977 | derived class D. | |
1978 | ||
1979 | ||
1980 | @example | |
1981 | class A @{ | |
1982 | public: | |
139741da RP |
1983 | int Adat; |
1984 | virtual int A_virt (int arg) @{ return arg; @}; | |
e505224d PB |
1985 | @}; |
1986 | ||
1987 | class B @{ | |
1988 | public: | |
139741da RP |
1989 | int B_dat; |
1990 | virtual int B_virt (int arg) @{return arg; @}; | |
e505224d PB |
1991 | @}; |
1992 | ||
1993 | class C @{ | |
1994 | public: | |
139741da RP |
1995 | int Cdat; |
1996 | virtual int C_virt (int arg) @{return arg; @}; | |
e505224d PB |
1997 | @}; |
1998 | ||
1999 | class D : A, virtual B, public C @{ | |
2000 | public: | |
139741da RP |
2001 | int Ddat; |
2002 | virtual int A_virt (int arg ) @{ return arg+1; @}; | |
2003 | virtual int B_virt (int arg) @{ return arg+2; @}; | |
2004 | virtual int C_virt (int arg) @{ return arg+3; @}; | |
2005 | virtual int D_virt (int arg) @{ return arg; @}; | |
e505224d PB |
2006 | @}; |
2007 | @end example | |
2008 | ||
2009 | Class stabs similar to the ones described earlier are generated for | |
2010 | each base class. | |
2011 | ||
5bc927fb RP |
2012 | @c FIXME!!! the linebreaks in the following example probably make the |
2013 | @c examples literally unusable, but I don't know any other way to get | |
2014 | @c them on the page. | |
899bafeb | 2015 | @smallexample |
5bc927fb RP |
2016 | .stabs "A:T20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32; |
2017 | A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0 | |
e505224d | 2018 | |
5bc927fb RP |
2019 | .stabs "B:Tt25=s8Bdat:1,0,32;$vf25:21,32;B_virt::26=##1; |
2020 | :i;2A*-2147483647;25;;;~%25;",128,0,0,0 | |
e505224d | 2021 | |
5bc927fb RP |
2022 | .stabs "C:Tt28=s8Cdat:1,0,32;$vf28:21,32;C_virt::29=##1; |
2023 | :i;2A*-2147483647;28;;;~%28;",128,0,0,0 | |
899bafeb | 2024 | @end smallexample |
e505224d PB |
2025 | |
2026 | In the stab describing derived class D below, the information about | |
2027 | the derivation of this class is encoded as follows. | |
2028 | ||
899bafeb | 2029 | @display |
e505224d | 2030 | .stabs "derived_class_name:symbol_descriptors(struct tag&type)= |
139741da RP |
2031 | type_descriptor(struct)struct_bytes(32)!num_bases(3), |
2032 | base_virtual(no)inheritence_public(no)base_offset(0), | |
2033 | base_class_type_ref(A); | |
2034 | base_virtual(yes)inheritence_public(no)base_offset(NIL), | |
2035 | base_class_type_ref(B); | |
2036 | base_virtual(no)inheritence_public(yes)base_offset(64), | |
2037 | base_class_type_ref(C); @dots{} | |
899bafeb | 2038 | @end display |
139741da | 2039 | |
5bc927fb | 2040 | @c FIXME! fake linebreaks. |
899bafeb | 2041 | @smallexample |
5bc927fb RP |
2042 | .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat: |
2043 | 1,160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt: | |
2044 | :32:i;2A*-2147483647;25;;C_virt::32:i;2A*-2147483647; | |
2045 | 28;;D_virt::32:i;2A*-2147483646;31;;;~%20;",128,0,0,0 | |
899bafeb | 2046 | @end smallexample |
e505224d | 2047 | |
2dd00294 | 2048 | @node Virtual Base Classes |
e505224d PB |
2049 | @section Virtual Base Classes |
2050 | ||
2051 | A derived class object consists of a concatination in memory of the | |
2052 | data areas defined by each base class, starting with the leftmost and | |
2053 | ending with the rightmost in the list of base classes. The exception | |
2054 | to this rule is for virtual inheritence. In the example above, class | |
2055 | D inherits virtually from base class B. This means that an instance | |
2056 | of a D object will not contain it's own B part but merely a pointer to | |
2057 | a B part, known as a virtual base pointer. | |
2058 | ||
2059 | In a derived class stab, the base offset part of the derivation | |
2060 | information, described above, shows how the base class parts are | |
2061 | ordered. The base offset for a virtual base class is always given as | |
2062 | 0. Notice that the base offset for B is given as 0 even though B is | |
2063 | not the first base class. The first base class A starts at offset 0. | |
2064 | ||
2065 | The field information part of the stab for class D describes the field | |
2066 | which is the pointer to the virtual base class B. The vbase pointer | |
2067 | name is $vb followed by a type reference to the virtual base class. | |
2068 | Since the type id for B in this example is 25, the vbase pointer name | |
2069 | is $vb25. | |
2070 | ||
5bc927fb | 2071 | @c FIXME!! fake linebreaks below |
899bafeb | 2072 | @smallexample |
5bc927fb RP |
2073 | .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:1, |
2074 | 160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt::32:i; | |
2075 | 2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;28;;D_virt: | |
2076 | :32:i;2A*-2147483646;31;;;~%20;",128,0,0,0 | |
899bafeb | 2077 | @end smallexample |
e505224d PB |
2078 | |
2079 | Following the name and a semicolon is a type reference describing the | |
2080 | type of the virtual base class pointer, in this case 24. Type 24 was | |
2081 | defined earlier as the type of the B class `this` pointer, $t. The | |
2082 | `this' pointer for a class is a pointer to the class type. | |
2083 | ||
899bafeb | 2084 | @example |
e505224d | 2085 | .stabs "$t:P24=*25=xsB:",64,0,0,8 |
899bafeb | 2086 | @end example |
e505224d PB |
2087 | |
2088 | Finally the field offset part of the vbase pointer field description | |
2089 | shows that the vbase pointer is the first field in the D object, | |
2090 | before any data fields defined by the class. The layout of a D class | |
2091 | object is a follows, Adat at 0, the vtable pointer for A at 32, Cdat | |
2092 | at 64, the vtable pointer for C at 96, the virtual ase pointer for B | |
2093 | at 128, and Ddat at 160. | |
2094 | ||
2095 | ||
899bafeb | 2096 | @node Static Members |
e505224d PB |
2097 | @section Static Members |
2098 | ||
2dd00294 | 2099 | The data area for a class is a concatination of the space used by the |
e505224d PB |
2100 | data members of the class. If the class has virtual methods a vtable |
2101 | pointer follows the class data. The field offset part of each field | |
2dd00294 | 2102 | description in the class stab shows this ordering. |
e505224d PB |
2103 | |
2104 | << how is this reflected in stabs? >> | |
2105 | ||
899bafeb | 2106 | @node Example2.c |
e505224d PB |
2107 | @appendix Example2.c - source code for extended example |
2108 | ||
2109 | @example | |
2110 | 1 char g_foo = 'c'; | |
2111 | 2 register int g_bar asm ("%g5"); | |
2112 | 3 static int s_g_repeat = 2; | |
2113 | 4 int (*g_pf)(); | |
2114 | 5 | |
2115 | 6 struct s_tag @{ | |
2116 | 7 int s_int; | |
2117 | 8 float s_float; | |
2118 | 9 char s_char_vec[8]; | |
2119 | 10 struct s_tag* s_next; | |
2120 | 11 @} g_an_s; | |
2121 | 12 | |
2122 | 13 typedef struct s_tag s_typedef; | |
2123 | 14 | |
2124 | 15 char char_vec[3] = @{'a','b','c'@}; | |
2125 | 16 | |
2126 | 17 main (argc, argv) | |
2127 | 18 int argc; | |
2128 | 19 char* argv[]; | |
2129 | 20 @{ | |
2130 | 21 static float s_flap; | |
139741da RP |
2131 | 22 int times; |
2132 | 23 for (times=0; times < s_g_repeat; times++)@{ | |
2133 | 24 int inner; | |
2134 | 25 printf ("Hello world\n"); | |
2135 | 26 @} | |
e505224d PB |
2136 | 27 @}; |
2137 | 28 | |
2138 | 29 enum e_places @{first,second=3,last@}; | |
2139 | 30 | |
2140 | 31 static s_proc (s_arg, s_ptr_arg, char_vec) | |
2141 | 32 s_typedef s_arg; | |
2142 | 33 s_typedef* s_ptr_arg; | |
2143 | 34 char* char_vec; | |
2144 | 35 @{ | |
2145 | 36 union u_tag @{ | |
2146 | 37 int u_int; | |
2147 | 38 float u_float; | |
2148 | 39 char* u_char; | |
2149 | 40 @} an_u; | |
2150 | 41 @} | |
2151 | 42 | |
2152 | 43 | |
2153 | @end example | |
2154 | ||
899bafeb | 2155 | @node Example2.s |
e505224d PB |
2156 | @appendix Example2.s - assembly code for extended example |
2157 | ||
2158 | @example | |
2159 | 1 gcc2_compiled.: | |
2160 | 2 .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 | |
2161 | 3 .stabs "example2.c",100,0,0,Ltext0 | |
139741da | 2162 | 4 .text |
e505224d PB |
2163 | 5 Ltext0: |
2164 | 6 .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 | |
2165 | 7 .stabs "char:t2=r2;0;127;",128,0,0,0 | |
2166 | 8 .stabs "long int:t3=r1;-2147483648;2147483647;",128,0,0,0 | |
2167 | 9 .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0 | |
2168 | 10 .stabs "long unsigned int:t5=r1;0;-1;",128,0,0,0 | |
2169 | 11 .stabs "short int:t6=r1;-32768;32767;",128,0,0,0 | |
2170 | 12 .stabs "long long int:t7=r1;0;-1;",128,0,0,0 | |
2171 | 13 .stabs "short unsigned int:t8=r1;0;65535;",128,0,0,0 | |
2172 | 14 .stabs "long long unsigned int:t9=r1;0;-1;",128,0,0,0 | |
2173 | 15 .stabs "signed char:t10=r1;-128;127;",128,0,0,0 | |
2174 | 16 .stabs "unsigned char:t11=r1;0;255;",128,0,0,0 | |
2175 | 17 .stabs "float:t12=r1;4;0;",128,0,0,0 | |
2176 | 18 .stabs "double:t13=r1;8;0;",128,0,0,0 | |
2177 | 19 .stabs "long double:t14=r1;8;0;",128,0,0,0 | |
2178 | 20 .stabs "void:t15=15",128,0,0,0 | |
2179 | 21 .stabs "g_foo:G2",32,0,0,0 | |
139741da RP |
2180 | 22 .global _g_foo |
2181 | 23 .data | |
e505224d | 2182 | 24 _g_foo: |
139741da | 2183 | 25 .byte 99 |
e505224d | 2184 | 26 .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat |
139741da | 2185 | 27 .align 4 |
e505224d | 2186 | 28 _s_g_repeat: |
139741da | 2187 | 29 .word 2 |
5bc927fb RP |
2188 | @c FIXME! fake linebreak in line 30 |
2189 | 30 .stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;s_char_vec: | |
2190 | 17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0 | |
e505224d PB |
2191 | 31 .stabs "s_typedef:t16",128,0,0,0 |
2192 | 32 .stabs "char_vec:G19=ar1;0;2;2",32,0,0,0 | |
139741da RP |
2193 | 33 .global _char_vec |
2194 | 34 .align 4 | |
e505224d | 2195 | 35 _char_vec: |
139741da RP |
2196 | 36 .byte 97 |
2197 | 37 .byte 98 | |
2198 | 38 .byte 99 | |
2199 | 39 .reserve _s_flap.0,4,"bss",4 | |
2200 | 40 .text | |
2201 | 41 .align 4 | |
e505224d | 2202 | 42 LC0: |
139741da RP |
2203 | 43 .ascii "Hello world\12\0" |
2204 | 44 .align 4 | |
2205 | 45 .global _main | |
2206 | 46 .proc 1 | |
e505224d PB |
2207 | 47 _main: |
2208 | 48 .stabn 68,0,20,LM1 | |
2209 | 49 LM1: | |
139741da RP |
2210 | 50 !#PROLOGUE# 0 |
2211 | 51 save %sp,-144,%sp | |
2212 | 52 !#PROLOGUE# 1 | |
2213 | 53 st %i0,[%fp+68] | |
2214 | 54 st %i1,[%fp+72] | |
2215 | 55 call ___main,0 | |
2216 | 56 nop | |
e505224d PB |
2217 | 57 LBB2: |
2218 | 58 .stabn 68,0,23,LM2 | |
2219 | 59 LM2: | |
139741da | 2220 | 60 st %g0,[%fp-20] |
e505224d | 2221 | 61 L2: |
139741da RP |
2222 | 62 sethi %hi(_s_g_repeat),%o0 |
2223 | 63 ld [%fp-20],%o1 | |
2224 | 64 ld [%o0+%lo(_s_g_repeat)],%o0 | |
2225 | 65 cmp %o1,%o0 | |
2226 | 66 bge L3 | |
2227 | 67 nop | |
e505224d PB |
2228 | 68 LBB3: |
2229 | 69 .stabn 68,0,25,LM3 | |
2230 | 70 LM3: | |
139741da RP |
2231 | 71 sethi %hi(LC0),%o1 |
2232 | 72 or %o1,%lo(LC0),%o0 | |
2233 | 73 call _printf,0 | |
2234 | 74 nop | |
e505224d PB |
2235 | 75 .stabn 68,0,26,LM4 |
2236 | 76 LM4: | |
2237 | 77 LBE3: | |
2238 | 78 .stabn 68,0,23,LM5 | |
2239 | 79 LM5: | |
2240 | 80 L4: | |
139741da RP |
2241 | 81 ld [%fp-20],%o0 |
2242 | 82 add %o0,1,%o1 | |
2243 | 83 st %o1,[%fp-20] | |
2244 | 84 b,a L2 | |
e505224d PB |
2245 | 85 L3: |
2246 | 86 .stabn 68,0,27,LM6 | |
2247 | 87 LM6: | |
2248 | 88 LBE2: | |
2249 | 89 .stabn 68,0,27,LM7 | |
2250 | 90 LM7: | |
2251 | 91 L1: | |
139741da RP |
2252 | 92 ret |
2253 | 93 restore | |
e505224d PB |
2254 | 94 .stabs "main:F1",36,0,0,_main |
2255 | 95 .stabs "argc:p1",160,0,0,68 | |
2256 | 96 .stabs "argv:p20=*21=*2",160,0,0,72 | |
2257 | 97 .stabs "s_flap:V12",40,0,0,_s_flap.0 | |
2258 | 98 .stabs "times:1",128,0,0,-20 | |
2259 | 99 .stabn 192,0,0,LBB2 | |
2260 | 100 .stabs "inner:1",128,0,0,-24 | |
2261 | 101 .stabn 192,0,0,LBB3 | |
2262 | 102 .stabn 224,0,0,LBE3 | |
2263 | 103 .stabn 224,0,0,LBE2 | |
2264 | 104 .stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0 | |
5bc927fb RP |
2265 | @c FIXME: fake linebreak in line 105 |
2266 | 105 .stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;", | |
2267 | 128,0,0,0 | |
139741da RP |
2268 | 106 .align 4 |
2269 | 107 .proc 1 | |
e505224d PB |
2270 | 108 _s_proc: |
2271 | 109 .stabn 68,0,35,LM8 | |
2272 | 110 LM8: | |
139741da RP |
2273 | 111 !#PROLOGUE# 0 |
2274 | 112 save %sp,-120,%sp | |
2275 | 113 !#PROLOGUE# 1 | |
2276 | 114 mov %i0,%o0 | |
2277 | 115 st %i1,[%fp+72] | |
2278 | 116 st %i2,[%fp+76] | |
e505224d PB |
2279 | 117 LBB4: |
2280 | 118 .stabn 68,0,41,LM9 | |
2281 | 119 LM9: | |
2282 | 120 LBE4: | |
2283 | 121 .stabn 68,0,41,LM10 | |
2284 | 122 LM10: | |
2285 | 123 L5: | |
139741da RP |
2286 | 124 ret |
2287 | 125 restore | |
e505224d PB |
2288 | 126 .stabs "s_proc:f1",36,0,0,_s_proc |
2289 | 127 .stabs "s_arg:p16",160,0,0,0 | |
2290 | 128 .stabs "s_ptr_arg:p18",160,0,0,72 | |
2291 | 129 .stabs "char_vec:p21",160,0,0,76 | |
2292 | 130 .stabs "an_u:23",128,0,0,-20 | |
2293 | 131 .stabn 192,0,0,LBB4 | |
2294 | 132 .stabn 224,0,0,LBE4 | |
2295 | 133 .stabs "g_bar:r1",64,0,0,5 | |
2296 | 134 .stabs "g_pf:G24=*25=f1",32,0,0,0 | |
139741da | 2297 | 135 .common _g_pf,4,"bss" |
e505224d | 2298 | 136 .stabs "g_an_s:G16",32,0,0,0 |
139741da | 2299 | 137 .common _g_an_s,20,"bss" |
e505224d PB |
2300 | @end example |
2301 | ||
2302 | ||
899bafeb | 2303 | @node Quick reference |
e505224d PB |
2304 | @appendix Quick reference |
2305 | ||
2306 | @menu | |
2307 | * Stab types:: Table A: Symbol types from stabs | |
2308 | * Assembler types:: Table B: Symbol types from assembler and linker | |
2309 | * Symbol descriptors:: Table C | |
2310 | * Type Descriptors:: Table D | |
2311 | @end menu | |
2312 | ||
899bafeb | 2313 | @node Stab types |
e505224d PB |
2314 | @section Table A: Symbol types from stabs |
2315 | ||
2316 | Table A lists stab types sorted by type number. Stab type numbers are | |
2317 | 32 and greater. This is the full list of stab numbers, including stab | |
2318 | types that are used in languages other than C. | |
2319 | ||
2320 | The #define names for these stab types are defined in: | |
2321 | devo/include/aout/stab.def | |
2322 | ||
899bafeb | 2323 | @smallexample |
e505224d PB |
2324 | type type #define used to describe |
2325 | dec hex name source program feature | |
5bc927fb | 2326 | ------------------------------------------------ |
139741da RP |
2327 | 32 0x20 N_GYSM global symbol |
2328 | 34 0X22 N_FNAME function name (for BSD Fortran) | |
2329 | 36 0x24 N_FUN function name or text segment variable for C | |
2330 | 38 0x26 N_STSYM static symbol (data segment w/internal linkage) | |
2331 | 40 0x28 N_LCSYM .lcomm symbol(BSS-seg variable w/internal linkage) | |
2332 | 42 0x2a N_MAIN Name of main routine (not used in C) | |
2333 | 48 0x30 N_PC global symbol (for Pascal) | |
2334 | 50 0x32 N_NSYMS number of symbols (according to Ultrix V4.0) | |
2335 | 52 0x34 N_NOMAP no DST map for sym (according to Ultrix V4.0) | |
2336 | 64 0x40 N_RSYM register variable | |
2337 | 66 0x42 N_M2C Modula-2 compilation unit | |
2338 | 68 0x44 N_SLINE line number in text segment | |
2339 | 70 0x46 N_DSLINE line number in data segment | |
2340 | ||
2341 | 72 0x48 N_BSLINE line number in bss segment | |
2342 | 72 0x48 N_BROWS Sun source code browser, path to .cb file | |
2343 | ||
2344 | 74 0x4a N_DEFD GNU Modula2 definition module dependency | |
2345 | ||
2346 | 80 0x50 N_EHDECL GNU C++ exception variable | |
2347 | 80 0x50 N_MOD2 Modula2 info "for imc" (according to Ultrix V4.0) | |
2348 | ||
2349 | 84 0x54 N_CATCH GNU C++ "catch" clause | |
2350 | 96 0x60 N_SSYM structure of union element | |
2351 | 100 0x64 N_SO path and name of source file | |
2352 | 128 0x80 N_LSYM automatic var in the stack | |
2353 | (also used for type desc.) | |
2354 | 130 0x82 N_BINCL beginning of an include file (Sun only) | |
2355 | 132 0x84 N_SOL Name of sub-source (#include) file. | |
2356 | 160 0xa0 N_PSYM parameter variable | |
2357 | 162 0xa2 N_EINCL end of an include file | |
2358 | 164 0xa4 N_ENTRY alternate entry point | |
2359 | 192 0xc0 N_LBRAC beginning of a lexical block | |
2360 | 194 0xc2 N_EXCL place holder for a deleted include file | |
2361 | 196 0xc4 N_SCOPE modula2 scope information (Sun linker) | |
2362 | 224 0xe0 N_RBRAC end of a lexical block | |
2363 | 226 0xe2 N_BCOMM begin named common block | |
2364 | 228 0xe4 N_ECOMM end named common block | |
2365 | 232 0xe8 N_ECOML end common (local name) | |
e505224d PB |
2366 | |
2367 | << used on Gould systems for non-base registers syms >> | |
139741da RP |
2368 | 240 0xf0 N_NBTEXT ?? |
2369 | 242 0xf2 N_NBDATA ?? | |
2370 | 244 0xf4 N_NBBSS ?? | |
2371 | 246 0xf6 N_NBSTS ?? | |
2372 | 248 0xf8 N_NBLCS ?? | |
899bafeb | 2373 | @end smallexample |
e505224d | 2374 | |
899bafeb | 2375 | @node Assembler types |
e505224d PB |
2376 | @section Table B: Symbol types from assembler and linker |
2377 | ||
2378 | Table B shows the types of symbol table entries that hold assembler | |
2379 | and linker symbols. | |
2380 | ||
2381 | The #define names for these n_types values are defined in | |
2382 | /include/aout/aout64.h | |
2383 | ||
899bafeb | 2384 | @smallexample |
139741da RP |
2385 | dec hex #define |
2386 | n_type n_type name used to describe | |
5bc927fb | 2387 | ------------------------------------------ |
139741da RP |
2388 | 1 0x0 N_UNDF undefined symbol |
2389 | 2 0x2 N_ABS absolute symbol -- defined at a particular address | |
2390 | 3 0x3 extern " (vs. file scope) | |
2391 | 4 0x4 N_TEXT text symbol -- defined at offset in text segment | |
2392 | 5 0x5 extern " (vs. file scope) | |
2393 | 6 0x6 N_DATA data symbol -- defined at offset in data segment | |
2394 | 7 0x7 extern " (vs. file scope) | |
2395 | 8 0x8 N_BSS BSS symbol -- defined at offset in zero'd segment | |
2396 | 9 extern " (vs. file scope) | |
2397 | ||
2398 | 12 0x0C N_FN_SEQ func name for Sequent compilers (stab exception) | |
2399 | ||
2400 | 49 0x12 N_COMM common sym -- visable after shared lib dynamic link | |
2401 | 31 0x1f N_FN file name of a .o file | |
899bafeb | 2402 | @end smallexample |
e505224d | 2403 | |
899bafeb | 2404 | @node Symbol descriptors |
e505224d PB |
2405 | @section Table C: Symbol descriptors |
2406 | ||
2407 | @example | |
139741da | 2408 | descriptor meaning |
e505224d | 2409 | ------------------------------------------------- |
139741da RP |
2410 | (empty) local variable |
2411 | f local function | |
2412 | F global function | |
2413 | G global variable | |
2414 | p value parameter | |
2415 | r register variable | |
2416 | S static global variable | |
2417 | t type name | |
2418 | T enumeration, struct or type tag | |
2419 | V static local variable | |
e505224d PB |
2420 | @end example |
2421 | ||
899bafeb | 2422 | @node Type Descriptors |
e505224d PB |
2423 | @section Table D: Type Descriptors |
2424 | ||
2425 | @example | |
139741da | 2426 | descriptor meaning |
e505224d | 2427 | ------------------------------------- |
139741da RP |
2428 | (empty) type reference |
2429 | a array type | |
2430 | e enumeration type | |
2431 | f function type | |
2432 | r range type | |
2433 | s structure type | |
2434 | u union specifications | |
2435 | * pointer type | |
e505224d PB |
2436 | @end example |
2437 | ||
2438 | ||
899bafeb | 2439 | @node Expanded reference |
e505224d PB |
2440 | @appendix Expanded reference by stab type. |
2441 | ||
2442 | Format of an entry: | |
2443 | ||
2444 | The first line is the symbol type expressed in decimal, hexadecimal, | |
2445 | and as a #define (see devo/include/aout/stab.def). | |
2446 | ||
2447 | The second line describes the language constructs the symbol type | |
2448 | represents. | |
2449 | ||
2450 | The third line is the stab format with the significant stab fields | |
2451 | named and the rest NIL. | |
2452 | ||
2453 | Subsequent lines expand upon the meaning and possible values for each | |
2454 | significant stab field. # stands in for the type descriptor. | |
2455 | ||
2456 | Finally, any further information. | |
2457 | ||
899bafeb RP |
2458 | @menu |
2459 | * N_GSYM:: Global variable | |
2460 | * N_FNAME:: Function name (BSD Fortran) | |
2461 | * N_FUN:: C Function name or text segment variable | |
2462 | * N_STSYM:: Initialized static symbol | |
2463 | * N_LCSYM:: Uninitialized static symbol | |
2464 | * N_MAIN:: Name of main routine (not for C) | |
2465 | * N_PC:: Pascal global symbol | |
2466 | * N_NSYMS:: Number of symbols | |
2467 | * N_NOMAP:: No DST map | |
2468 | * N_RSYM:: Register variable | |
2469 | * N_M2C:: Modula-2 compilation unit | |
2470 | * N_SLINE:: Line number in text segment | |
2471 | * N_DSLINE:: Line number in data segment | |
2472 | * N_BSLINE:: Line number in bss segment | |
2473 | * N_BROWS:: Path to .cb file for Sun source code browser | |
2474 | * N_DEFD:: GNU Modula2 definition module dependency | |
2475 | * N_EHDECL:: GNU C++ exception variable | |
2476 | * N_MOD2:: Modula2 information "for imc" | |
2477 | * N_CATCH:: GNU C++ "catch" clause | |
2478 | * N_SSYM:: Structure or union element | |
2479 | * N_SO:: Source file containing main | |
2480 | * N_LSYM:: Automatic variable | |
2481 | * N_BINCL:: Beginning of include file (Sun only) | |
2482 | * N_SOL:: Name of include file | |
2483 | * N_PSYM:: Parameter variable | |
2484 | * N_EINCL:: End of include file | |
2485 | * N_ENTRY:: Alternate entry point | |
2486 | * N_LBRAC:: Beginning of lexical block | |
2487 | * N_EXCL:: Deleted include file | |
2488 | * N_SCOPE:: Modula2 scope information (Sun only) | |
2489 | * N_RBRAC:: End of lexical block | |
2490 | * N_BCOMM:: Begin named common block | |
2491 | * N_ECOMM:: End named common block | |
2492 | * N_ECOML:: End common | |
2493 | * Gould:: non-base register symbols used on Gould systems | |
2494 | * N_LENG:: Length of preceding entry | |
2495 | @end menu | |
2496 | ||
2497 | @node N_GSYM | |
139741da | 2498 | @section 32 - 0x20 - N_GYSM |
899bafeb RP |
2499 | |
2500 | @display | |
e505224d PB |
2501 | Global variable. |
2502 | ||
2503 | .stabs "name", N_GSYM, NIL, NIL, NIL | |
899bafeb | 2504 | @end display |
e505224d | 2505 | |
899bafeb | 2506 | @example |
e505224d | 2507 | "name" -> "symbol_name:#type" |
139741da | 2508 | # -> G |
899bafeb | 2509 | @end example |
e505224d PB |
2510 | |
2511 | Only the "name" field is significant. the location of the variable is | |
2512 | obtained from the corresponding external symbol. | |
2513 | ||
899bafeb RP |
2514 | @node N_FNAME |
2515 | @section 34 - 0x22 - N_FNAME | |
e505224d PB |
2516 | Function name (for BSD Fortran) |
2517 | ||
899bafeb | 2518 | @display |
e505224d | 2519 | .stabs "name", N_FNAME, NIL, NIL, NIL |
899bafeb | 2520 | @end display |
e505224d | 2521 | |
899bafeb | 2522 | @example |
e505224d | 2523 | "name" -> "function_name" |
899bafeb | 2524 | @end example |
e505224d PB |
2525 | |
2526 | Only the "name" field is significant. The location of the symbol is | |
2527 | obtained from the corresponding extern symbol. | |
2528 | ||
899bafeb | 2529 | @node N_FUN |
139741da | 2530 | @section 36 - 0x24 - N_FUN |
e505224d PB |
2531 | Function name or text segment variable for C. |
2532 | ||
899bafeb | 2533 | @display |
e505224d | 2534 | .stabs "name", N_FUN, NIL, desc, value |
899bafeb | 2535 | @end display |
e505224d | 2536 | |
899bafeb RP |
2537 | @example |
2538 | @exdent @emph{For functions:} | |
e505224d | 2539 | "name" -> "proc_name:#return_type" |
139741da RP |
2540 | # -> F (global function) |
2541 | f (local function) | |
e505224d PB |
2542 | desc -> line num for proc start. (GCC doesn't set and DBX doesn't miss it.) |
2543 | value -> Code address of proc start. | |
2544 | ||
899bafeb | 2545 | @exdent @emph{For text segment variables:} |
e505224d | 2546 | <<How to create one?>> |
899bafeb | 2547 | @end example |
e505224d | 2548 | |
899bafeb RP |
2549 | @node N_STSYM |
2550 | @section 38 - 0x26 - N_STSYM | |
e505224d PB |
2551 | Initialized static symbol (data segment w/internal linkage). |
2552 | ||
899bafeb | 2553 | @display |
e505224d | 2554 | .stabs "name", N_STSYM, NIL, NIL, value |
899bafeb | 2555 | @end display |
e505224d | 2556 | |
899bafeb | 2557 | @example |
e505224d | 2558 | "name" -> "symbol_name#type" |
139741da RP |
2559 | # -> S (scope global to compilation unit) |
2560 | -> V (scope local to a procedure) | |
e505224d | 2561 | value -> Data Address |
899bafeb | 2562 | @end example |
e505224d | 2563 | |
899bafeb RP |
2564 | @node N_LCSYM |
2565 | @section 40 - 0x28 - N_LCSYM | |
e505224d PB |
2566 | Unitialized static (.lcomm) symbol(BSS segment w/internal linkage). |
2567 | ||
899bafeb | 2568 | @display |
e505224d | 2569 | .stabs "name", N_LCLSYM, NIL, NIL, value |
899bafeb | 2570 | @end display |
e505224d | 2571 | |
899bafeb | 2572 | @example |
e505224d | 2573 | "name" -> "symbol_name#type" |
139741da RP |
2574 | # -> S (scope global to compilation unit) |
2575 | -> V (scope local to procedure) | |
e505224d | 2576 | value -> BSS Address |
899bafeb | 2577 | @end example |
e505224d | 2578 | |
899bafeb | 2579 | @node N_MAIN |
139741da | 2580 | @section 42 - 0x2a - N_MAIN |
e505224d PB |
2581 | Name of main routine (not used in C) |
2582 | ||
899bafeb | 2583 | @display |
e505224d | 2584 | .stabs "name", N_MAIN, NIL, NIL, NIL |
899bafeb | 2585 | @end display |
e505224d | 2586 | |
899bafeb | 2587 | @example |
e505224d | 2588 | "name" -> "name_of_main_routine" |
899bafeb | 2589 | @end example |
e505224d | 2590 | |
899bafeb | 2591 | @node N_PC |
139741da | 2592 | @section 48 - 0x30 - N_PC |
e505224d PB |
2593 | Global symbol (for Pascal) |
2594 | ||
899bafeb | 2595 | @display |
e505224d | 2596 | .stabs "name", N_PC, NIL, NIL, value |
899bafeb | 2597 | @end display |
e505224d | 2598 | |
899bafeb | 2599 | @example |
e505224d PB |
2600 | "name" -> "symbol_name" <<?>> |
2601 | value -> supposedly the line number (stab.def is skeptical) | |
899bafeb | 2602 | @end example |
e505224d | 2603 | |
899bafeb | 2604 | @display |
e505224d PB |
2605 | stabdump.c says: |
2606 | ||
2607 | global pascal symbol: name,,0,subtype,line | |
2608 | << subtype? >> | |
899bafeb | 2609 | @end display |
e505224d | 2610 | |
899bafeb | 2611 | @node N_NSYMS |
139741da | 2612 | @section 50 - 0x32 - N_NSYMS |
e505224d PB |
2613 | Number of symbols (according to Ultrix V4.0) |
2614 | ||
899bafeb | 2615 | @display |
139741da | 2616 | 0, files,,funcs,lines (stab.def) |
899bafeb | 2617 | @end display |
e505224d | 2618 | |
899bafeb RP |
2619 | @node N_NOMAP |
2620 | @section 52 - 0x34 - N_NOMAP | |
e505224d PB |
2621 | no DST map for sym (according to Ultrix V4.0) |
2622 | ||
899bafeb | 2623 | @display |
139741da | 2624 | name, ,0,type,ignored (stab.def) |
899bafeb RP |
2625 | @end display |
2626 | ||
2627 | @node N_RSYM | |
139741da | 2628 | @section 64 - 0x40 - N_RSYM |
e505224d PB |
2629 | register variable |
2630 | ||
899bafeb | 2631 | @display |
e505224d | 2632 | .stabs "name:type",N_RSYM,0,RegSize,RegNumber (Sun doc) |
899bafeb | 2633 | @end display |
e505224d | 2634 | |
899bafeb | 2635 | @node N_M2C |
139741da | 2636 | @section 66 - 0x42 - N_M2C |
e505224d PB |
2637 | Modula-2 compilation unit |
2638 | ||
899bafeb | 2639 | @display |
e505224d | 2640 | .stabs "name", N_M2C, 0, desc, value |
899bafeb | 2641 | @end display |
e505224d | 2642 | |
899bafeb | 2643 | @example |
e505224d PB |
2644 | "name" -> "unit_name,unit_time_stamp[,code_time_stamp] |
2645 | desc -> unit_number | |
2646 | value -> 0 (main unit) | |
139741da | 2647 | 1 (any other unit) |
899bafeb | 2648 | @end example |
e505224d | 2649 | |
899bafeb | 2650 | @node N_SLINE |
139741da | 2651 | @section 68 - 0x44 - N_SLINE |
e505224d PB |
2652 | Line number in text segment |
2653 | ||
899bafeb | 2654 | @display |
e505224d | 2655 | .stabn N_SLINE, 0, desc, value |
899bafeb | 2656 | @end display |
e505224d | 2657 | |
899bafeb | 2658 | @example |
e505224d PB |
2659 | desc -> line_number |
2660 | value -> code_address (relocatable addr where the corresponding code starts) | |
899bafeb | 2661 | @end example |
e505224d PB |
2662 | |
2663 | For single source lines that generate discontiguous code, such as flow | |
2664 | of control statements, there may be more than one N_SLINE stab for the | |
2665 | same source line. In this case there is a stab at the start of each | |
2666 | code range, each with the same line number. | |
2667 | ||
899bafeb RP |
2668 | @node N_DSLINE |
2669 | @section 70 - 0x46 - N_DSLINE | |
e505224d PB |
2670 | Line number in data segment |
2671 | ||
899bafeb | 2672 | @display |
e505224d | 2673 | .stabn N_DSLINE, 0, desc, value |
899bafeb | 2674 | @end display |
e505224d | 2675 | |
899bafeb | 2676 | @example |
e505224d | 2677 | desc -> line_number |
899bafeb RP |
2678 | value -> data_address (relocatable addr where the corresponding code |
2679 | starts) | |
2680 | @end example | |
e505224d PB |
2681 | |
2682 | See comment for N_SLINE above. | |
2683 | ||
899bafeb RP |
2684 | @node N_BSLINE |
2685 | @section 72 - 0x48 - N_BSLINE | |
e505224d PB |
2686 | Line number in bss segment |
2687 | ||
899bafeb | 2688 | @display |
e505224d | 2689 | .stabn N_BSLINE, 0, desc, value |
899bafeb | 2690 | @end display |
e505224d | 2691 | |
899bafeb | 2692 | @example |
e505224d | 2693 | desc -> line_number |
899bafeb RP |
2694 | value -> bss_address (relocatable addr where the corresponding code |
2695 | starts) | |
2696 | @end example | |
e505224d PB |
2697 | |
2698 | See comment for N_SLINE above. | |
2699 | ||
899bafeb | 2700 | @node N_BROWS |
139741da | 2701 | @section 72 - 0x48 - N_BROWS |
e505224d PB |
2702 | Sun source code browser, path to .cb file |
2703 | ||
2704 | <<?>> | |
2705 | "path to associated .cb file" | |
2706 | ||
2707 | Note: type field value overlaps with N_BSLINE | |
2708 | ||
899bafeb | 2709 | @node N_DEFD |
139741da | 2710 | @section 74 - 0x4a - N_DEFD |
612dbd4c | 2711 | GNU Modula2 definition module dependency |
e505224d PB |
2712 | |
2713 | GNU Modula-2 definition module dependency. Value is the modification | |
2714 | time of the definition file. Other is non-zero if it is imported with | |
2715 | the GNU M2 keyword %INITIALIZE. Perhaps N_M2C can be used if there | |
2716 | are enough empty fields? | |
2717 | ||
899bafeb RP |
2718 | @node N_EHDECL |
2719 | @section 80 - 0x50 - N_EHDECL | |
612dbd4c | 2720 | GNU C++ exception variable <<?>> |
e505224d PB |
2721 | |
2722 | "name is variable name" | |
2723 | ||
2724 | Note: conflicts with N_MOD2. | |
2725 | ||
899bafeb RP |
2726 | @node N_MOD2 |
2727 | @section 80 - 0x50 - N_MOD2 | |
2728 | Modula2 info "for imc" (according to Ultrix V4.0) | |
e505224d PB |
2729 | |
2730 | Note: conflicts with N_EHDECL <<?>> | |
2731 | ||
899bafeb RP |
2732 | @node N_CATCH |
2733 | @section 84 - 0x54 - N_CATCH | |
2734 | GNU C++ "catch" clause | |
e505224d PB |
2735 | |
2736 | GNU C++ `catch' clause. Value is its address. Desc is nonzero if | |
2737 | this entry is immediately followed by a CAUGHT stab saying what | |
2738 | exception was caught. Multiple CAUGHT stabs means that multiple | |
2739 | exceptions can be caught here. If Desc is 0, it means all exceptions | |
2740 | are caught here. | |
2741 | ||
899bafeb | 2742 | @node N_SSYM |
139741da | 2743 | @section 96 - 0x60 - N_SSYM |
e505224d PB |
2744 | Structure or union element |
2745 | ||
899bafeb RP |
2746 | Value is offset in the structure. |
2747 | ||
2748 | <<?looking at structs and unions in C I didn't see these>> | |
e505224d | 2749 | |
899bafeb | 2750 | @node N_SO |
139741da | 2751 | @section 100 - 0x64 - N_SO |
e505224d PB |
2752 | Path and name of source file containing main routine |
2753 | ||
899bafeb | 2754 | @display |
e505224d | 2755 | .stabs "name", N_SO, NIL, NIL, value |
899bafeb | 2756 | @end display |
e505224d | 2757 | |
899bafeb | 2758 | @example |
e505224d PB |
2759 | "name" -> /path/to/source/file |
2760 | -> source_file_terminal_name | |
2761 | ||
2762 | value -> the starting text address of the compilation. | |
899bafeb | 2763 | @end example |
e505224d PB |
2764 | |
2765 | These are found two in a row. The name field of the first N_SO | |
2766 | contains the path to the source file. The name field of the second | |
2767 | N_SO contains the terminal name of the source file itself. | |
2768 | ||
899bafeb | 2769 | @node N_LSYM |
139741da | 2770 | @section 128 - 0x80 - N_LSYM |
e505224d PB |
2771 | Automatic var in the stack (also used for type descriptors.) |
2772 | ||
899bafeb | 2773 | @display |
e505224d | 2774 | .stabs "name" N_LSYM, NIL, NIL, value |
899bafeb | 2775 | @end display |
e505224d | 2776 | |
899bafeb RP |
2777 | @example |
2778 | @exdent @emph{For stack based local variables:} | |
e505224d PB |
2779 | |
2780 | "name" -> name of the variable | |
2781 | value -> offset from frame pointer (negative) | |
2782 | ||
899bafeb | 2783 | @exdent @emph{For type descriptors:} |
e505224d PB |
2784 | |
2785 | "name" -> "name_of_the_type:#type" | |
139741da | 2786 | # -> t |
e505224d | 2787 | |
139741da | 2788 | type -> type_ref (or) type_def |
e505224d PB |
2789 | |
2790 | type_ref -> type_number | |
2791 | type_def -> type_number=type_desc etc. | |
899bafeb | 2792 | @end example |
e505224d PB |
2793 | |
2794 | Type may be either a type reference or a type definition. A type | |
2795 | reference is a number that refers to a previously defined type. A | |
2796 | type definition is the number that will refer to this type, followed | |
2797 | by an equals sign, a type descriptor and the additional data that | |
2798 | defines the type. See the Table D for type descriptors and the | |
2799 | section on types for what data follows each type descriptor. | |
2800 | ||
899bafeb | 2801 | @node N_BINCL |
139741da | 2802 | @section 130 - 0x82 - N_BINCL |
e505224d PB |
2803 | |
2804 | Beginning of an include file (Sun only) | |
2805 | ||
2806 | Beginning of an include file. Only Sun uses this. In an object file, | |
2807 | only the name is significant. The Sun linker puts data into some of | |
2808 | the other fields. | |
2809 | ||
899bafeb RP |
2810 | @node N_SOL |
2811 | @section 132 - 0x84 - N_SOL | |
e505224d PB |
2812 | |
2813 | Name of a sub-source file (#include file). Value is starting address | |
2814 | of the compilation. | |
2815 | <<?>> | |
2816 | ||
899bafeb | 2817 | @node N_PSYM |
139741da | 2818 | @section 160 - 0xa0 - N_PSYM |
e505224d PB |
2819 | |
2820 | Parameter variable | |
2821 | ||
899bafeb | 2822 | @display |
e505224d | 2823 | stabs. "name", N_PSYM, NIL, NIL, value |
899bafeb | 2824 | @end display |
e505224d | 2825 | |
899bafeb | 2826 | @example |
e505224d | 2827 | "name" -> "param_name:#type" |
139741da RP |
2828 | # -> p (value parameter) |
2829 | -> i (value parameter by reference, indirect access) | |
2830 | -> v (variable parameter by reference) | |
2831 | -> C ( read-only parameter, conformant array bound) | |
2832 | -> x (confomant array value parameter) | |
2833 | -> pP (<<??>>) | |
2834 | -> pF (<<??>>) | |
2835 | -> X (function result variable) | |
2836 | -> b (based variable) | |
e505224d PB |
2837 | |
2838 | value -> offset from the argument pointer (positive). | |
899bafeb | 2839 | @end example |
e505224d PB |
2840 | |
2841 | On most machines the argument pointer is the same as the frame | |
2842 | pointer. | |
2843 | ||
899bafeb RP |
2844 | @node N_EINCL |
2845 | @section 162 - 0xa2 - N_EINCL | |
e505224d PB |
2846 | |
2847 | End of an include file. This and N_BINCL act as brackets around the | |
2848 | file's output. In an ojbect file, there is no significant data in | |
899bafeb | 2849 | this entry. The Sun linker puts data into some of the fields. |
e505224d PB |
2850 | <<?>> |
2851 | ||
899bafeb RP |
2852 | @node N_ENTRY |
2853 | @section 164 - 0xa4 - N_ENTRY | |
e505224d PB |
2854 | |
2855 | Alternate entry point. | |
2856 | Value is its address. | |
2857 | <<?>> | |
2858 | ||
899bafeb RP |
2859 | @node N_LBRAC |
2860 | @section 192 - 0xc0 - N_LBRAC | |
e505224d PB |
2861 | |
2862 | Beginning of a lexical block (left brace). The variable defined | |
2863 | inside the block precede the N_LBRAC symbol. Or can they follow as | |
2864 | well as long as a new N_FUNC was not encountered. <<?>> | |
2865 | ||
899bafeb | 2866 | @display |
e505224d | 2867 | .stabn N_LBRAC, NIL, NIL, value |
899bafeb | 2868 | @end display |
e505224d | 2869 | |
899bafeb | 2870 | @example |
e505224d | 2871 | value -> code address of block start. |
899bafeb | 2872 | @end example |
e505224d | 2873 | |
899bafeb RP |
2874 | @node N_EXCL |
2875 | @section 194 - 0xc2 - N_EXCL | |
e505224d PB |
2876 | |
2877 | Place holder for a deleted include file. Replaces a N_BINCL and | |
2878 | everything up to the corresponding N_EINCL. The Sun linker generates | |
2879 | these when it finds multiple indentical copies of the symbols from an | |
2880 | included file. This appears only in output from the Sun linker. | |
2881 | <<?>> | |
2882 | ||
899bafeb RP |
2883 | @node N_SCOPE |
2884 | @section 196 - 0xc4 - N_SCOPE | |
e505224d PB |
2885 | |
2886 | Modula2 scope information (Sun linker) | |
2887 | <<?>> | |
2888 | ||
899bafeb | 2889 | @node N_RBRAC |
139741da | 2890 | @section 224 - 0xe0 - N_RBRAC |
e505224d PB |
2891 | |
2892 | End of a lexical block (right brace) | |
2893 | ||
899bafeb | 2894 | @display |
e505224d | 2895 | .stabn N_RBRAC, NIL, NIL, value |
899bafeb | 2896 | @end display |
e505224d | 2897 | |
899bafeb | 2898 | @example |
e505224d | 2899 | value -> code address of the end of the block. |
899bafeb | 2900 | @end example |
e505224d | 2901 | |
899bafeb | 2902 | @node N_BCOMM |
139741da | 2903 | @section 226 - 0xe2 - N_BCOMM |
e505224d PB |
2904 | |
2905 | Begin named common block. | |
2906 | ||
2907 | Only the name is significant. | |
2908 | <<?>> | |
2909 | ||
899bafeb | 2910 | @node N_ECOMM |
139741da | 2911 | @section 228 - 0xe4 - N_ECOMM |
e505224d PB |
2912 | |
2913 | End named common block. | |
2914 | ||
2915 | Only the name is significant and it should match the N_BCOMM | |
2916 | <<?>> | |
2917 | ||
899bafeb RP |
2918 | @node N_ECOML |
2919 | @section 232 - 0xe8 - N_ECOML | |
e505224d PB |
2920 | |
2921 | End common (local name) | |
2922 | ||
2923 | value is address. | |
2924 | <<?>> | |
2925 | ||
899bafeb RP |
2926 | @node Gould |
2927 | @section Non-base registers on Gould systems | |
e505224d PB |
2928 | << used on Gould systems for non-base registers syms, values assigned |
2929 | at random, need real info from Gould. >> | |
2930 | <<?>> | |
2931 | ||
899bafeb | 2932 | @example |
139741da RP |
2933 | 240 0xf0 N_NBTEXT ?? |
2934 | 242 0xf2 N_NBDATA ?? | |
2935 | 244 0xf4 N_NBBSS ?? | |
2936 | 246 0xf6 N_NBSTS ?? | |
2937 | 248 0xf8 N_NBLCS ?? | |
899bafeb | 2938 | @end example |
e505224d | 2939 | |
899bafeb RP |
2940 | @node N_LENG |
2941 | @section - 0xfe - N_LENG | |
e505224d PB |
2942 | |
2943 | Second symbol entry containing a length-value for the preceding entry. | |
2944 | The value is the length. | |
2945 | ||
899bafeb RP |
2946 | @node Questions |
2947 | @appendix Questions and anomalies | |
e505224d PB |
2948 | |
2949 | @itemize @bullet | |
2950 | @item | |
2951 | For GNU C stabs defining local and global variables (N_LSYM and | |
2952 | N_GSYM), the desc field is supposed to contain the source line number | |
2953 | on which the variable is defined. In reality the desc field is always | |
2954 | 0. (This behavour is defined in dbxout.c and putting a line number in | |
2955 | desc is controlled by #ifdef WINNING_GDB which defaults to false). Gdb | |
2956 | supposedly uses this information if you say 'list var'. In reality | |
2957 | var can be a variable defined in the program and gdb says `function | |
2958 | var not defined' | |
2959 | ||
2960 | @item | |
612dbd4c | 2961 | In GNU C stabs there seems to be no way to differentiate tag types: |
e505224d PB |
2962 | structures, unions, and enums (symbol descriptor T) and typedefs |
2963 | (symbol descriptor t) defined at file scope from types defined locally | |
2964 | to a procedure or other more local scope. They all use the N_LSYM | |
2965 | stab type. Types defined at procedure scope are emited after the | |
139741da | 2966 | N_RBRAC of the preceding function and before the code of the |
e505224d PB |
2967 | procedure in which they are defined. This is exactly the same as |
2968 | types defined in the source file between the two procedure bodies. | |
2969 | GDB overcompensates by placing all types in block #1 the block for | |
2970 | symbols of file scope. This is true for default, -ansi and | |
2971 | -traditional compiler options. (p0001063-gcc, p0001066-gdb) | |
2972 | ||
2973 | @item | |
2974 | What ends the procedure scope? Is it the proc block's N_RBRAC or the | |
2975 | next N_FUN? (I believe its the first.) | |
2976 | ||
2977 | @item | |
2978 | The comment in xcoff.h says DBX_STATIC_CONST_VAR_CODE is used for | |
2979 | static const variables. DBX_STATIC_CONST_VAR_CODE is set to N_FUN by | |
2980 | default, in dbxout.c. If included, xcoff.h redefines it to N_STSYM. | |
2981 | But testing the default behaviour, my Sun4 native example shows | |
2982 | N_STSYM not N_FUN is used to describe file static initialized | |
2983 | variables. (the code tests for TREE_READONLY(decl) && | |
2984 | !TREE_THIS_VOLATILE(decl) and if true uses DBX_STATIC_CONST_VAR_CODE). | |
2985 | ||
2986 | @item | |
2987 | Global variable stabs don't have location information. This comes | |
2988 | from the external symbol for the same variable. The external symbol | |
2989 | has a leading underbar on the _name of the variable and the stab does | |
2990 | not. How do we know these two symbol table entries are talking about | |
2991 | the same symbol when their names are different? | |
2992 | ||
2993 | @item | |
2994 | Can gcc be configured to output stabs the way the Sun compiler | |
2995 | does, so that their native debugging tools work? <NO?> It doesn't by | |
2996 | default. GDB reads either format of stab. (gcc or SunC). How about | |
2997 | dbx? | |
2998 | @end itemize | |
2999 | ||
899bafeb | 3000 | @node xcoff-differences |
e505224d PB |
3001 | @appendix Differences between GNU stabs in a.out and GNU stabs in xcoff |
3002 | ||
3003 | (The AIX/RS6000 native object file format is xcoff with stabs) | |
3004 | ||
3005 | @itemize @bullet | |
3006 | @item | |
3007 | Instead of .stabs, xcoff uses .stabx. | |
3008 | ||
3009 | @item | |
3010 | The data fields of an xcoff .stabx are in a different order than an | |
3011 | a.out .stabs. The order is: string, value, type. The desc and null | |
3012 | fields present in a.out stabs are missing in xcoff stabs. For N_GSYM | |
3013 | the value field is the name of the symbol. | |
3014 | ||
3015 | @item | |
5bc927fb | 3016 | BSD a.out stab types correspond to AIX xcoff storage classes. In general the |
e505224d PB |
3017 | mapping is N_STABTYPE becomes C_STABTYPE. Some stab types in a.out |
3018 | are not supported in xcoff. See Table E. for full mappings. | |
3019 | ||
3020 | exception: | |
3021 | initialised static N_STSYM and un-initialized static N_LCSYM both map | |
3022 | to the C_STSYM storage class. But the destinction is preserved | |
3023 | because in xcoff N_STSYM and N_LCSYM must be emited in a named static | |
3024 | block. Begin the block with .bs s[RW] data_section_name for N_STSYM | |
3025 | or .bs s bss_section_name for N_LCSYM. End the block with .es | |
3026 | ||
3027 | @item | |
3028 | xcoff stabs describing tags and typedefs use the N_DECL (0x8c)instead | |
3029 | of N_LSYM stab type. | |
3030 | ||
3031 | @item | |
3032 | xcoff uses N_RPSYM (0x8e) instead of the N_RSYM stab type for register | |
3033 | variables. If the register variable is also a value parameter, then | |
3034 | use R instead of P for the symbol descriptor. | |
3035 | ||
3036 | 6. | |
3037 | xcoff uses negative numbers as type references to the basic types. | |
3038 | There are no boilerplate type definitions emited for these basic | |
3039 | types. << make table of basic types and type numbers for C >> | |
3040 | ||
3041 | @item | |
3042 | xcoff .stabx sometimes don't have the name part of the string field. | |
3043 | ||
3044 | @item | |
3045 | xcoff uses a .file stab type to represent the source file name. There | |
3046 | is no stab for the path to the source file. | |
3047 | ||
3048 | @item | |
3049 | xcoff uses a .line stab type to represent source lines. The format | |
3050 | is: .line line_number. | |
3051 | ||
3052 | @item | |
3053 | xcoff emits line numbers relative to the start of the current | |
3054 | function. The start of a function is marked by .bf. If a function | |
3055 | includes lines from a seperate file, then those line numbers are | |
3056 | absolute line numbers in the <<sub-?>> file being compiled. | |
3057 | ||
3058 | @item | |
3059 | The start of current include file is marked with: .bi "filename" and | |
3060 | the end marked with .ei "filename" | |
3061 | ||
3062 | @item | |
3063 | If the xcoff stab is a N_FUN (C_FUN) then follow the string field with | |
3064 | ,. instead of just , | |
3065 | ||
3066 | @item | |
3067 | The symbol descriptor for register parameters is P for a.out and R for | |
3068 | xcoff. | |
3069 | @end itemize | |
3070 | ||
3071 | ||
3072 | (I think that's it for .s file differences. They could stand to be | |
3073 | better presented. This is just a list of what I have noticed so far. | |
3074 | There are a *lot* of differences in the information in the symbol | |
3075 | tables of the executable and object files.) | |
3076 | ||
3077 | Table E: mapping a.out stab types to xcoff storage classes | |
3078 | ||
3079 | @example | |
139741da | 3080 | stab type storage class |
e505224d | 3081 | ------------------------------- |
139741da RP |
3082 | N_GSYM C_GSYM |
3083 | N_FNAME unknown | |
3084 | N_FUN C_FUN | |
3085 | N_STSYM C_STSYM | |
3086 | N_LCSYM C_STSYM | |
3087 | N_MAIN unkown | |
3088 | N_PC unknown | |
3089 | N_RSYM C_RSYM | |
3090 | N_RPSYM (0x8e) C_RPSYM | |
3091 | N_M2C unknown | |
3092 | N_SLINE unknown | |
3093 | N_DSLINE unknown | |
3094 | N_BSLINE unknown | |
3095 | N_BROWSE unchanged | |
3096 | N_CATCH unknown | |
3097 | N_SSYM unknown | |
3098 | N_SO unknown | |
3099 | N_LSYM C_LSYM | |
3100 | N_DECL (0x8c) C_DECL | |
3101 | N_BINCL unknown | |
3102 | N_SOL unknown | |
3103 | N_PSYM C_PSYM | |
3104 | N_EINCL unknown | |
3105 | N_ENTRY C_ENTRY | |
3106 | N_LBRAC unknown | |
3107 | N_EXCL unknown | |
3108 | N_SCOPE unknown | |
3109 | N_RBRAC unknown | |
3110 | N_BCOMM C_BCOMM | |
3111 | N_ECOMM C_ECOMM | |
3112 | N_ECOML C_ECOML | |
3113 | ||
3114 | N_LENG unknown | |
e505224d PB |
3115 | @end example |
3116 | ||
899bafeb | 3117 | @node Sun-differences |
e505224d PB |
3118 | @appendix Differences between GNU stabs and Sun native stabs. |
3119 | ||
3120 | @itemize @bullet | |
3121 | @item | |
612dbd4c | 3122 | GNU C stabs define *all* types, file or procedure scope, as |
e505224d PB |
3123 | N_LSYM. Sun doc talks about using N_GSYM too. |
3124 | ||
3125 | @item | |
612dbd4c | 3126 | GNU C stabs use `ar' as type descriptor when defining arrays vs. just |
e505224d PB |
3127 | `a' in Sun doc. |
3128 | ||
3129 | @item | |
3130 | Stabs describing block scopes, N_LBRAC and N_RBRAC are supposed to | |
3131 | contain the nesting level of the block in the desc field, re Sun doc. | |
3132 | GNU stabs always have 0 in that field. | |
3133 | ||
3134 | @item | |
3135 | Sun C stabs use type number pairs in the format (a,b) where a is a | |
3136 | number starting with 1 and incremented for each sub-source file in the | |
3137 | compilation. b is a number starting with 1 and incremented for each | |
612dbd4c | 3138 | new type defined in the compilation. GNU C stabs use the type number |
e505224d PB |
3139 | alone, with no source file number. |
3140 | @end itemize | |
3141 | ||
3142 | @contents | |
3143 | @bye |