OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [gdb-5.0/] [gdb/] [doc/] [stabs.info-2] - Blame information for rev 107

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 106 markom
This is stabs.info, produced by Makeinfo version 3.12f from
2
./stabs.texinfo.
3
 
4
START-INFO-DIR-ENTRY
5
* Stabs: (stabs).                 The "stabs" debugging information format.
6
END-INFO-DIR-ENTRY
7
 
8
   This document describes the stabs debugging symbol tables.
9
 
10
   Copyright 1992, 93, 94, 95, 97, 1998 Free Software Foundation, Inc.
11
Contributed by Cygnus Support.  Written by Julia Menapace, Jim Kingdon,
12
and David MacKenzie.
13
 
14
   Permission is granted to make and distribute verbatim copies of this
15
manual provided the copyright notice and this permission notice are
16
preserved on all copies.
17
 
18
   Permission is granted to copy or distribute modified versions of this
19
manual under the terms of the GPL (for which purpose this text may be
20
regarded as a program in the language TeX).
21
 
22

23
File: stabs.info,  Node: Conformant Arrays,  Prev: Reference Parameters,  Up: Parameters
24
 
25
Passing Conformant Array Parameters
26
-----------------------------------
27
 
28
   Conformant arrays are a feature of Modula-2, and perhaps other
29
languages, in which the size of an array parameter is not known to the
30
called function until run-time.  Such parameters have two stabs: a `x'
31
for the array itself, and a `C', which represents the size of the
32
array.  The value of the `x' stab is the offset in the argument list
33
where the address of the array is stored (it this right?  it is a
34
guess); the value of the `C' stab is the offset in the argument list
35
where the size of the array (in elements? in bytes?) is stored.
36
 
37

38
File: stabs.info,  Node: Types,  Next: Symbol Tables,  Prev: Variables,  Up: Top
39
 
40
Defining Types
41
**************
42
 
43
   The examples so far have described types as references to previously
44
defined types, or defined in terms of subranges of or pointers to
45
previously defined types.  This chapter describes the other type
46
descriptors that may follow the `=' in a type definition.
47
 
48
* Menu:
49
 
50
* Builtin Types::               Integers, floating point, void, etc.
51
* Miscellaneous Types::         Pointers, sets, files, etc.
52
* Cross-References::            Referring to a type not yet defined.
53
* Subranges::                   A type with a specific range.
54
* Arrays::                      An aggregate type of same-typed elements.
55
* Strings::                     Like an array but also has a length.
56
* Enumerations::                Like an integer but the values have names.
57
* Structures::                  An aggregate type of different-typed elements.
58
* Typedefs::                    Giving a type a name.
59
* Unions::                      Different types sharing storage.
60
* Function Types::
61
 
62

63
File: stabs.info,  Node: Builtin Types,  Next: Miscellaneous Types,  Up: Types
64
 
65
Builtin Types
66
=============
67
 
68
   Certain types are built in (`int', `short', `void', `float', etc.);
69
the debugger recognizes these types and knows how to handle them.
70
Thus, don't be surprised if some of the following ways of specifying
71
builtin types do not specify everything that a debugger would need to
72
know about the type--in some cases they merely specify enough
73
information to distinguish the type from other types.
74
 
75
   The traditional way to define builtin types is convolunted, so new
76
ways have been invented to describe them.  Sun's `acc' uses special
77
builtin type descriptors (`b' and `R'), and IBM uses negative type
78
numbers.  GDB accepts all three ways, as of version 4.8; dbx just
79
accepts the traditional builtin types and perhaps one of the other two
80
formats.  The following sections describe each of these formats.
81
 
82
* Menu:
83
 
84
* Traditional Builtin Types::   Put on your seatbelts and prepare for kludgery
85
* Builtin Type Descriptors::    Builtin types with special type descriptors
86
* Negative Type Numbers::       Builtin types using negative type numbers
87
 
88

89
File: stabs.info,  Node: Traditional Builtin Types,  Next: Builtin Type Descriptors,  Up: Builtin Types
90
 
91
Traditional Builtin Types
92
-------------------------
93
 
94
   This is the traditional, convoluted method for defining builtin
95
types.  There are several classes of such type definitions: integer,
96
floating point, and `void'.
97
 
98
* Menu:
99
 
100
* Traditional Integer Types::
101
* Traditional Other Types::
102
 
103

104
File: stabs.info,  Node: Traditional Integer Types,  Next: Traditional Other Types,  Up: Traditional Builtin Types
105
 
106
Traditional Integer Types
107
.........................
108
 
109
   Often types are defined as subranges of themselves.  If the bounding
110
values fit within an `int', then they are given normally.  For example:
111
 
112
     .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0    # 128 is N_LSYM
113
     .stabs "char:t2=r2;0;127;",128,0,0,0
114
 
115
   Builtin types can also be described as subranges of `int':
116
 
117
     .stabs "unsigned short:t6=r1;0;65535;",128,0,0,0
118
 
119
   If the lower bound of a subrange is 0 and the upper bound is -1, the
120
type is an unsigned integral type whose bounds are too big to describe
121
in an `int'.  Traditionally this is only used for `unsigned int' and
122
`unsigned long':
123
 
124
     .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
125
 
126
   For larger types, GCC 2.4.5 puts out bounds in octal, with one or
127
more leading zeroes.  In this case a negative bound consists of a number
128
which is a 1 bit (for the sign bit) followed by a 0 bit for each bit in
129
the number (except the sign bit), and a positive bound is one which is a
130
1 bit for each bit in the number (except possibly the sign bit).  All
131
known versions of dbx and GDB version 4 accept this (at least in the
132
sense of not refusing to process the file), but GDB 3.5 refuses to read
133
the whole file containing such symbols.  So GCC 2.3.3 did not output the
134
proper size for these types.  As an example of octal bounds, the string
135
fields of the stabs for 64 bit integer types look like:
136
 
137
     long int:t3=r1;001000000000000000000000;000777777777777777777777;
138
     long unsigned int:t5=r1;000000000000000000000000;001777777777777777777777;
139
 
140
   If the lower bound of a subrange is 0 and the upper bound is
141
negative, the type is an unsigned integral type whose size in bytes is
142
the absolute value of the upper bound.  I believe this is a Convex
143
convention for `unsigned long long'.
144
 
145
   If the lower bound of a subrange is negative and the upper bound is
146
0, the type is a signed integral type whose size in bytes is the
147
absolute value of the lower bound.  I believe this is a Convex
148
convention for `long long'.  To distinguish this from a legitimate
149
subrange, the type should be a subrange of itself.  I'm not sure whether
150
this is the case for Convex.
151
 
152

153
File: stabs.info,  Node: Traditional Other Types,  Prev: Traditional Integer Types,  Up: Traditional Builtin Types
154
 
155
Traditional Other Types
156
.......................
157
 
158
   If the upper bound of a subrange is 0 and the lower bound is
159
positive, the type is a floating point type, and the lower bound of the
160
subrange indicates the number of bytes in the type:
161
 
162
     .stabs "float:t12=r1;4;0;",128,0,0,0
163
     .stabs "double:t13=r1;8;0;",128,0,0,0
164
 
165
   However, GCC writes `long double' the same way it writes `double',
166
so there is no way to distinguish.
167
 
168
     .stabs "long double:t14=r1;8;0;",128,0,0,0
169
 
170
   Complex types are defined the same way as floating-point types;
171
there is no way to distinguish a single-precision complex from a
172
double-precision floating-point type.
173
 
174
   The C `void' type is defined as itself:
175
 
176
     .stabs "void:t15=15",128,0,0,0
177
 
178
   I'm not sure how a boolean type is represented.
179
 
180

181
File: stabs.info,  Node: Builtin Type Descriptors,  Next: Negative Type Numbers,  Prev: Traditional Builtin Types,  Up: Builtin Types
182
 
183
Defining Builtin Types Using Builtin Type Descriptors
184
-----------------------------------------------------
185
 
186
   This is the method used by Sun's `acc' for defining builtin types.
187
These are the type descriptors to define builtin types:
188
 
189
`b SIGNED CHAR-FLAG WIDTH ; OFFSET ; NBITS ;'
190
     Define an integral type.  SIGNED is `u' for unsigned or `s' for
191
     signed.  CHAR-FLAG is `c' which indicates this is a character
192
     type, or is omitted.  I assume this is to distinguish an integral
193
     type from a character type of the same size, for example it might
194
     make sense to set it for the C type `wchar_t' so the debugger can
195
     print such variables differently (Solaris does not do this).  Sun
196
     sets it on the C types `signed char' and `unsigned char' which
197
     arguably is wrong.  WIDTH and OFFSET appear to be for small
198
     objects stored in larger ones, for example a `short' in an `int'
199
     register.  WIDTH is normally the number of bytes in the type.
200
     OFFSET seems to always be zero.  NBITS is the number of bits in
201
     the type.
202
 
203
     Note that type descriptor `b' used for builtin types conflicts with
204
     its use for Pascal space types (*note Miscellaneous Types::.);
205
     they can be distinguished because the character following the type
206
     descriptor will be a digit, `(', or `-' for a Pascal space type, or
207
     `u' or `s' for a builtin type.
208
 
209
`w'
210
     Documented by AIX to define a wide character type, but their
211
     compiler actually uses negative type numbers (*note Negative Type
212
     Numbers::.).
213
 
214
`R FP-TYPE ; BYTES ;'
215
     Define a floating point type.  FP-TYPE has one of the following
216
     values:
217
 
218
    `1 (NF_SINGLE)'
219
          IEEE 32-bit (single precision) floating point format.
220
 
221
    `2 (NF_DOUBLE)'
222
          IEEE 64-bit (double precision) floating point format.
223
 
224
    `3 (NF_COMPLEX)'
225
 
226
    `4 (NF_COMPLEX16)'
227
 
228
    `5 (NF_COMPLEX32)'
229
          These are for complex numbers.  A comment in the GDB source
230
          describes them as Fortran `complex', `double complex', and
231
          `complex*16', respectively, but what does that mean?  (i.e.,
232
          Single precision?  Double precison?).
233
 
234
    `6 (NF_LDOUBLE)'
235
          Long double.  This should probably only be used for Sun format
236
          `long double', and new codes should be used for other floating
237
          point formats (`NF_DOUBLE' can be used if a `long double' is
238
          really just an IEEE double, of course).
239
 
240
     BYTES is the number of bytes occupied by the type.  This allows a
241
     debugger to perform some operations with the type even if it
242
     doesn't understand FP-TYPE.
243
 
244
`g TYPE-INFORMATION ; NBITS'
245
     Documented by AIX to define a floating type, but their compiler
246
     actually uses negative type numbers (*note Negative Type
247
     Numbers::.).
248
 
249
`c TYPE-INFORMATION ; NBITS'
250
     Documented by AIX to define a complex type, but their compiler
251
     actually uses negative type numbers (*note Negative Type
252
     Numbers::.).
253
 
254
   The C `void' type is defined as a signed integral type 0 bits long:
255
     .stabs "void:t19=bs0;0;0",128,0,0,0
256
   The Solaris compiler seems to omit the trailing semicolon in this
257
case.  Getting sloppy in this way is not a swift move because if a type
258
is embedded in a more complex expression it is necessary to be able to
259
tell where it ends.
260
 
261
   I'm not sure how a boolean type is represented.
262
 
263

264
File: stabs.info,  Node: Negative Type Numbers,  Prev: Builtin Type Descriptors,  Up: Builtin Types
265
 
266
Negative Type Numbers
267
---------------------
268
 
269
   This is the method used in XCOFF for defining builtin types.  Since
270
the debugger knows about the builtin types anyway, the idea of negative
271
type numbers is simply to give a special type number which indicates
272
the builtin type.  There is no stab defining these types.
273
 
274
   There are several subtle issues with negative type numbers.
275
 
276
   One is the size of the type.  A builtin type (for example the C types
277
`int' or `long') might have different sizes depending on compiler
278
options, the target architecture, the ABI, etc.  This issue doesn't
279
come up for IBM tools since (so far) they just target the RS/6000; the
280
sizes indicated below for each size are what the IBM RS/6000 tools use.
281
To deal with differing sizes, either define separate negative type
282
numbers for each size (which works but requires changing the debugger,
283
and, unless you get both AIX dbx and GDB to accept the change,
284
introduces an incompatibility), or use a type attribute (*note String
285
Field::.) to define a new type with the appropriate size (which merely
286
requires a debugger which understands type attributes, like AIX dbx or
287
GDB).  For example,
288
 
289
     .stabs "boolean:t10=@s8;-16",128,0,0,0
290
 
291
   defines an 8-bit boolean type, and
292
 
293
     .stabs "boolean:t10=@s64;-16",128,0,0,0
294
 
295
   defines a 64-bit boolean type.
296
 
297
   A similar issue is the format of the type.  This comes up most often
298
for floating-point types, which could have various formats (particularly
299
extended doubles, which vary quite a bit even among IEEE systems).
300
Again, it is best to define a new negative type number for each
301
different format; changing the format based on the target system has
302
various problems.  One such problem is that the Alpha has both VAX and
303
IEEE floating types.  One can easily imagine one library using the VAX
304
types and another library in the same executable using the IEEE types.
305
Another example is that the interpretation of whether a boolean is true
306
or false can be based on the least significant bit, most significant
307
bit, whether it is zero, etc., and different compilers (or different
308
options to the same compiler) might provide different kinds of boolean.
309
 
310
   The last major issue is the names of the types.  The name of a given
311
type depends _only_ on the negative type number given; these do not
312
vary depending on the language, the target system, or anything else.
313
One can always define separate type numbers--in the following list you
314
will see for example separate `int' and `integer*4' types which are
315
identical except for the name.  But compatibility can be maintained by
316
not inventing new negative type numbers and instead just defining a new
317
type with a new name.  For example:
318
 
319
     .stabs "CARDINAL:t10=-8",128,0,0,0
320
 
321
   Here is the list of negative type numbers.  The phrase "integral
322
type" is used to mean twos-complement (I strongly suspect that all
323
machines which use stabs use twos-complement; most machines use
324
twos-complement these days).
325
 
326
`-1'
327
     `int', 32 bit signed integral type.
328
 
329
`-2'
330
     `char', 8 bit type holding a character.   Both GDB and dbx on AIX
331
     treat this as signed.  GCC uses this type whether `char' is signed
332
     or not, which seems like a bad idea.  The AIX compiler (`xlc')
333
     seems to avoid this type; it uses -5 instead for `char'.
334
 
335
`-3'
336
     `short', 16 bit signed integral type.
337
 
338
`-4'
339
     `long', 32 bit signed integral type.
340
 
341
`-5'
342
     `unsigned char', 8 bit unsigned integral type.
343
 
344
`-6'
345
     `signed char', 8 bit signed integral type.
346
 
347
`-7'
348
     `unsigned short', 16 bit unsigned integral type.
349
 
350
`-8'
351
     `unsigned int', 32 bit unsigned integral type.
352
 
353
`-9'
354
     `unsigned', 32 bit unsigned integral type.
355
 
356
`-10'
357
     `unsigned long', 32 bit unsigned integral type.
358
 
359
`-11'
360
     `void', type indicating the lack of a value.
361
 
362
`-12'
363
     `float', IEEE single precision.
364
 
365
`-13'
366
     `double', IEEE double precision.
367
 
368
`-14'
369
     `long double', IEEE double precision.  The compiler claims the size
370
     will increase in a future release, and for binary compatibility
371
     you have to avoid using `long double'.  I hope when they increase
372
     it they use a new negative type number.
373
 
374
`-15'
375
     `integer'.  32 bit signed integral type.
376
 
377
`-16'
378
     `boolean'.  32 bit type.  GDB and GCC assume that zero is false,
379
     one is true, and other values have unspecified meaning.  I hope
380
     this agrees with how the IBM tools use the type.
381
 
382
`-17'
383
     `short real'.  IEEE single precision.
384
 
385
`-18'
386
     `real'.  IEEE double precision.
387
 
388
`-19'
389
     `stringptr'.  *Note Strings::.
390
 
391
`-20'
392
     `character', 8 bit unsigned character type.
393
 
394
`-21'
395
     `logical*1', 8 bit type.  This Fortran type has a split
396
     personality in that it is used for boolean variables, but can also
397
     be used for unsigned integers.  0 is false, 1 is true, and other
398
     values are non-boolean.
399
 
400
`-22'
401
     `logical*2', 16 bit type.  This Fortran type has a split
402
     personality in that it is used for boolean variables, but can also
403
     be used for unsigned integers.  0 is false, 1 is true, and other
404
     values are non-boolean.
405
 
406
`-23'
407
     `logical*4', 32 bit type.  This Fortran type has a split
408
     personality in that it is used for boolean variables, but can also
409
     be used for unsigned integers.  0 is false, 1 is true, and other
410
     values are non-boolean.
411
 
412
`-24'
413
     `logical', 32 bit type.  This Fortran type has a split personality
414
     in that it is used for boolean variables, but can also be used for
415
     unsigned integers.  0 is false, 1 is true, and other values are
416
     non-boolean.
417
 
418
`-25'
419
     `complex'.  A complex type consisting of two IEEE single-precision
420
     floating point values.
421
 
422
`-26'
423
     `complex'.  A complex type consisting of two IEEE double-precision
424
     floating point values.
425
 
426
`-27'
427
     `integer*1', 8 bit signed integral type.
428
 
429
`-28'
430
     `integer*2', 16 bit signed integral type.
431
 
432
`-29'
433
     `integer*4', 32 bit signed integral type.
434
 
435
`-30'
436
     `wchar'.  Wide character, 16 bits wide, unsigned (what format?
437
     Unicode?).
438
 
439
`-31'
440
     `long long', 64 bit signed integral type.
441
 
442
`-32'
443
     `unsigned long long', 64 bit unsigned integral type.
444
 
445
`-33'
446
     `logical*8', 64 bit unsigned integral type.
447
 
448
`-34'
449
     `integer*8', 64 bit signed integral type.
450
 
451

452
File: stabs.info,  Node: Miscellaneous Types,  Next: Cross-References,  Prev: Builtin Types,  Up: Types
453
 
454
Miscellaneous Types
455
===================
456
 
457
`b TYPE-INFORMATION ; BYTES'
458
     Pascal space type.  This is documented by IBM; what does it mean?
459
 
460
     This use of the `b' type descriptor can be distinguished from its
461
     use for builtin integral types (*note Builtin Type Descriptors::.)
462
     because the character following the type descriptor is always a
463
     digit, `(', or `-'.
464
 
465
`B TYPE-INFORMATION'
466
     A volatile-qualified version of TYPE-INFORMATION.  This is a Sun
467
     extension.  References and stores to a variable with a
468
     volatile-qualified type must not be optimized or cached; they must
469
     occur as the user specifies them.
470
 
471
`d TYPE-INFORMATION'
472
     File of type TYPE-INFORMATION.  As far as I know this is only used
473
     by Pascal.
474
 
475
`k TYPE-INFORMATION'
476
     A const-qualified version of TYPE-INFORMATION.  This is a Sun
477
     extension.  A variable with a const-qualified type cannot be
478
     modified.
479
 
480
`M TYPE-INFORMATION ; LENGTH'
481
     Multiple instance type.  The type seems to composed of LENGTH
482
     repetitions of TYPE-INFORMATION, for example `character*3' is
483
     represented by `M-2;3', where `-2' is a reference to a character
484
     type (*note Negative Type Numbers::.).  I'm not sure how this
485
     differs from an array.  This appears to be a Fortran feature.
486
     LENGTH is a bound, like those in range types; see *Note
487
     Subranges::.
488
 
489
`S TYPE-INFORMATION'
490
     Pascal set type.  TYPE-INFORMATION must be a small type such as an
491
     enumeration or a subrange, and the type is a bitmask whose length
492
     is specified by the number of elements in TYPE-INFORMATION.
493
 
494
     In CHILL, if it is a bitstring instead of a set, also use the `S'
495
     type attribute (*note String Field::.).
496
 
497
`* TYPE-INFORMATION'
498
     Pointer to TYPE-INFORMATION.
499
 
500

501
File: stabs.info,  Node: Cross-References,  Next: Subranges,  Prev: Miscellaneous Types,  Up: Types
502
 
503
Cross-References to Other Types
504
===============================
505
 
506
   A type can be used before it is defined; one common way to deal with
507
that situation is just to use a type reference to a type which has not
508
yet been defined.
509
 
510
   Another way is with the `x' type descriptor, which is followed by
511
`s' for a structure tag, `u' for a union tag, or `e' for a enumerator
512
tag, followed by the name of the tag, followed by `:'.  If the name
513
contains `::' between a `<' and `>' pair (for C++ templates), such a
514
`::' does not end the name--only a single `:' ends the name; see *Note
515
Nested Symbols::.
516
 
517
   For example, the following C declarations:
518
 
519
     struct foo;
520
     struct foo *bar;
521
 
522
produce:
523
 
524
     .stabs "bar:G16=*17=xsfoo:",32,0,0,0
525
 
526
   Not all debuggers support the `x' type descriptor, so on some
527
machines GCC does not use it.  I believe that for the above example it
528
would just emit a reference to type 17 and never define it, but I
529
haven't verified that.
530
 
531
   Modula-2 imported types, at least on AIX, use the `i' type
532
descriptor, which is followed by the name of the module from which the
533
type is imported, followed by `:', followed by the name of the type.
534
There is then optionally a comma followed by type information for the
535
type.  This differs from merely naming the type (*note Typedefs::.) in
536
that it identifies the module; I don't understand whether the name of
537
the type given here is always just the same as the name we are giving
538
it, or whether this type descriptor is used with a nameless stab (*note
539
String Field::.), or what.  The symbol ends with `;'.
540
 
541

542
File: stabs.info,  Node: Subranges,  Next: Arrays,  Prev: Cross-References,  Up: Types
543
 
544
Subrange Types
545
==============
546
 
547
   The `r' type descriptor defines a type as a subrange of another
548
type.  It is followed by type information for the type of which it is a
549
subrange, a semicolon, an integral lower bound, a semicolon, an
550
integral upper bound, and a semicolon.  The AIX documentation does not
551
specify the trailing semicolon, in an effort to specify array indexes
552
more cleanly, but a subrange which is not an array index has always
553
included a trailing semicolon (*note Arrays::.).
554
 
555
   Instead of an integer, either bound can be one of the following:
556
 
557
`A OFFSET'
558
     The bound is passed by reference on the stack at offset OFFSET
559
     from the argument list.  *Note Parameters::, for more information
560
     on such offsets.
561
 
562
`T OFFSET'
563
     The bound is passed by value on the stack at offset OFFSET from
564
     the argument list.
565
 
566
`a REGISTER-NUMBER'
567
     The bound is pased by reference in register number REGISTER-NUMBER.
568
 
569
`t REGISTER-NUMBER'
570
     The bound is passed by value in register number REGISTER-NUMBER.
571
 
572
`J'
573
     There is no bound.
574
 
575
   Subranges are also used for builtin types; see *Note Traditional
576
Builtin Types::.
577
 
578

579
File: stabs.info,  Node: Arrays,  Next: Strings,  Prev: Subranges,  Up: Types
580
 
581
Array Types
582
===========
583
 
584
   Arrays use the `a' type descriptor.  Following the type descriptor
585
is the type of the index and the type of the array elements.  If the
586
index type is a range type, it ends in a semicolon; otherwise (for
587
example, if it is a type reference), there does not appear to be any
588
way to tell where the types are separated.  In an effort to clean up
589
this mess, IBM documents the two types as being separated by a
590
semicolon, and a range type as not ending in a semicolon (but this is
591
not right for range types which are not array indexes, *note
592
Subranges::.).  I think probably the best solution is to specify that a
593
semicolon ends a range type, and that the index type and element type
594
of an array are separated by a semicolon, but that if the index type is
595
a range type, the extra semicolon can be omitted.  GDB (at least
596
through version 4.9) doesn't support any kind of index type other than a
597
range anyway; I'm not sure about dbx.
598
 
599
   It is well established, and widely used, that the type of the index,
600
unlike most types found in the stabs, is merely a type definition, not
601
type information (*note String Field::.) (that is, it need not start
602
with `TYPE-NUMBER=' if it is defining a new type).  According to a
603
comment in GDB, this is also true of the type of the array elements; it
604
gives `ar1;1;10;ar1;1;10;4' as a legitimate way to express a two
605
dimensional array.  According to AIX documentation, the element type
606
must be type information.  GDB accepts either.
607
 
608
   The type of the index is often a range type, expressed as the type
609
descriptor `r' and some parameters.  It defines the size of the array.
610
In the example below, the range `r1;0;2;' defines an index type which
611
is a subrange of type 1 (integer), with a lower bound of 0 and an upper
612
bound of 2.  This defines the valid range of subscripts of a
613
three-element C array.
614
 
615
   For example, the definition:
616
 
617
     char char_vec[3] = {'a','b','c'};
618
 
619
produces the output:
620
 
621
     .stabs "char_vec:G19=ar1;0;2;2",32,0,0,0
622
          .global _char_vec
623
          .align 4
624
     _char_vec:
625
          .byte 97
626
          .byte 98
627
          .byte 99
628
 
629
   If an array is "packed", the elements are spaced more closely than
630
normal, saving memory at the expense of speed.  For example, an array
631
of 3-byte objects might, if unpacked, have each element aligned on a
632
4-byte boundary, but if packed, have no padding.  One way to specify
633
that something is packed is with type attributes (*note String
634
Field::.).  In the case of arrays, another is to use the `P' type
635
descriptor instead of `a'.  Other than specifying a packed array, `P'
636
is identical to `a'.
637
 
638
   An open array is represented by the `A' type descriptor followed by
639
type information specifying the type of the array elements.
640
 
641
   An N-dimensional dynamic array is represented by
642
 
643
     D DIMENSIONS ; TYPE-INFORMATION
644
 
645
   DIMENSIONS is the number of dimensions; TYPE-INFORMATION specifies
646
the type of the array elements.
647
 
648
   A subarray of an N-dimensional array is represented by
649
 
650
     E DIMENSIONS ; TYPE-INFORMATION
651
 
652
   DIMENSIONS is the number of dimensions; TYPE-INFORMATION specifies
653
the type of the array elements.
654
 
655

656
File: stabs.info,  Node: Strings,  Next: Enumerations,  Prev: Arrays,  Up: Types
657
 
658
Strings
659
=======
660
 
661
   Some languages, like C or the original Pascal, do not have string
662
types, they just have related things like arrays of characters.  But
663
most Pascals and various other languages have string types, which are
664
indicated as follows:
665
 
666
`n TYPE-INFORMATION ; BYTES'
667
     BYTES is the maximum length.  I'm not sure what TYPE-INFORMATION
668
     is; I suspect that it means that this is a string of
669
     TYPE-INFORMATION (thus allowing a string of integers, a string of
670
     wide characters, etc., as well as a string of characters).  Not
671
     sure what the format of this type is.  This is an AIX feature.
672
 
673
`z TYPE-INFORMATION ; BYTES'
674
     Just like `n' except that this is a gstring, not an ordinary
675
     string.  I don't know the difference.
676
 
677
`N'
678
     Pascal Stringptr.  What is this?  This is an AIX feature.
679
 
680
   Languages, such as CHILL which have a string type which is basically
681
just an array of characters use the `S' type attribute (*note String
682
Field::.).
683
 
684

685
File: stabs.info,  Node: Enumerations,  Next: Structures,  Prev: Strings,  Up: Types
686
 
687
Enumerations
688
============
689
 
690
   Enumerations are defined with the `e' type descriptor.
691
 
692
   The source line below declares an enumeration type at file scope.
693
The type definition is located after the `N_RBRAC' that marks the end of
694
the previous procedure's block scope, and before the `N_FUN' that marks
695
the beginning of the next procedure's block scope.  Therefore it does
696
not describe a block local symbol, but a file local one.
697
 
698
   The source line:
699
 
700
     enum e_places {first,second=3,last};
701
 
702
generates the following stab:
703
 
704
     .stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0
705
 
706
   The symbol descriptor (`T') says that the stab describes a
707
structure, enumeration, or union tag.  The type descriptor `e',
708
following the `22=' of the type definition narrows it down to an
709
enumeration type.  Following the `e' is a list of the elements of the
710
enumeration.  The format is `NAME:VALUE,'.  The list of elements ends
711
with `;'.  The fact that VALUE is specified as an integer can cause
712
problems if the value is large.  GCC 2.5.2 tries to output it in octal
713
in that case with a leading zero, which is probably a good thing,
714
although GDB 4.11 supports octal only in cases where decimal is
715
perfectly good.  Negative decimal values are supported by both GDB and
716
dbx.
717
 
718
   There is no standard way to specify the size of an enumeration type;
719
it is determined by the architecture (normally all enumerations types
720
are 32 bits).  Type attributes can be used to specify an enumeration
721
type of another size for debuggers which support them; see *Note String
722
Field::.
723
 
724
   Enumeration types are unusual in that they define symbols for the
725
enumeration values (`first', `second', and `third' in the above
726
example), and even though these symbols are visible in the file as a
727
whole (rather than being in a more local namespace like structure
728
member names), they are defined in the type definition for the
729
enumeration type rather than each having their own symbol.  In order to
730
be fast, GDB will only get symbols from such types (in its initial scan
731
of the stabs) if the type is the first thing defined after a `T' or `t'
732
symbol descriptor (the above example fulfills this requirement).  If
733
the type does not have a name, the compiler should emit it in a
734
nameless stab (*note String Field::.); GCC does this.
735
 
736

737
File: stabs.info,  Node: Structures,  Next: Typedefs,  Prev: Enumerations,  Up: Types
738
 
739
Structures
740
==========
741
 
742
   The encoding of structures in stabs can be shown with an example.
743
 
744
   The following source code declares a structure tag and defines an
745
instance of the structure in global scope. Then a `typedef' equates the
746
structure tag with a new type.  Seperate stabs are generated for the
747
structure tag, the structure `typedef', and the structure instance.  The
748
stabs for the tag and the `typedef' are emited when the definitions are
749
encountered.  Since the structure elements are not initialized, the
750
stab and code for the structure variable itself is located at the end
751
of the program in the bss section.
752
 
753
     struct s_tag {
754
       int   s_int;
755
       float s_float;
756
       char  s_char_vec[8];
757
       struct s_tag* s_next;
758
     } g_an_s;
759
 
760
     typedef struct s_tag s_typedef;
761
 
762
   The structure tag has an `N_LSYM' stab type because, like the
763
enumeration, the symbol has file scope.  Like the enumeration, the
764
symbol descriptor is `T', for enumeration, structure, or tag type.  The
765
type descriptor `s' following the `16=' of the type definition narrows
766
the symbol type to structure.
767
 
768
   Following the `s' type descriptor is the number of bytes the
769
structure occupies, followed by a description of each structure element.
770
The structure element descriptions are of the form NAME:TYPE, BIT
771
OFFSET FROM THE START OF THE STRUCT, NUMBER OF BITS IN THE ELEMENT.
772
 
773
     # 128 is N_LSYM
774
     .stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;
775
             s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0
776
 
777
   In this example, the first two structure elements are previously
778
defined types.  For these, the type following the `NAME:' part of the
779
element description is a simple type reference.  The other two structure
780
elements are new types.  In this case there is a type definition
781
embedded after the `NAME:'.  The type definition for the array element
782
looks just like a type definition for a standalone array.  The `s_next'
783
field is a pointer to the same kind of structure that the field is an
784
element of.  So the definition of structure type 16 contains a type
785
definition for an element which is a pointer to type 16.
786
 
787
   If a field is a static member (this is a C++ feature in which a
788
single variable appears to be a field of every structure of a given
789
type) it still starts out with the field name, a colon, and the type,
790
but then instead of a comma, bit position, comma, and bit size, there
791
is a colon followed by the name of the variable which each such field
792
refers to.
793
 
794
   If the structure has methods (a C++ feature), they follow the
795
non-method fields; see *Note Cplusplus::.
796
 
797

798
File: stabs.info,  Node: Typedefs,  Next: Unions,  Prev: Structures,  Up: Types
799
 
800
Giving a Type a Name
801
====================
802
 
803
   To give a type a name, use the `t' symbol descriptor.  The type is
804
specified by the type information (*note String Field::.) for the stab.
805
For example,
806
 
807
     .stabs "s_typedef:t16",128,0,0,0     # 128 is N_LSYM
808
 
809
   specifies that `s_typedef' refers to type number 16.  Such stabs
810
have symbol type `N_LSYM' (or `C_DECL' for XCOFF).  (The Sun
811
documentation mentions using `N_GSYM' in some cases).
812
 
813
   If you are specifying the tag name for a structure, union, or
814
enumeration, use the `T' symbol descriptor instead.  I believe C is the
815
only language with this feature.
816
 
817
   If the type is an opaque type (I believe this is a Modula-2 feature),
818
AIX provides a type descriptor to specify it.  The type descriptor is
819
`o' and is followed by a name.  I don't know what the name means--is it
820
always the same as the name of the type, or is this type descriptor
821
used with a nameless stab (*note String Field::.)?  There optionally
822
follows a comma followed by type information which defines the type of
823
this type.  If omitted, a semicolon is used in place of the comma and
824
the type information, and the type is much like a generic pointer
825
type--it has a known size but little else about it is specified.
826
 
827

828
File: stabs.info,  Node: Unions,  Next: Function Types,  Prev: Typedefs,  Up: Types
829
 
830
Unions
831
======
832
 
833
     union u_tag {
834
       int  u_int;
835
       float u_float;
836
       char* u_char;
837
     } an_u;
838
 
839
   This code generates a stab for a union tag and a stab for a union
840
variable.  Both use the `N_LSYM' stab type.  If a union variable is
841
scoped locally to the procedure in which it is defined, its stab is
842
located immediately preceding the `N_LBRAC' for the procedure's block
843
start.
844
 
845
   The stab for the union tag, however, is located preceding the code
846
for the procedure in which it is defined.  The stab type is `N_LSYM'.
847
This would seem to imply that the union type is file scope, like the
848
struct type `s_tag'.  This is not true.  The contents and position of
849
the stab for `u_type' do not convey any infomation about its procedure
850
local scope.
851
 
852
     # 128 is N_LSYM
853
     .stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;",
854
            128,0,0,0
855
 
856
   The symbol descriptor `T', following the `name:' means that the stab
857
describes an enumeration, structure, or union tag.  The type descriptor
858
`u', following the `23=' of the type definition, narrows it down to a
859
union type definition.  Following the `u' is the number of bytes in the
860
union.  After that is a list of union element descriptions.  Their
861
format is NAME:TYPE, BIT OFFSET INTO THE UNION, NUMBER OF BYTES FOR THE
862
ELEMENT;.
863
 
864
   The stab for the union variable is:
865
 
866
     .stabs "an_u:23",128,0,0,-20     # 128 is N_LSYM
867
 
868
   `-20' specifies where the variable is stored (*note Stack
869
Variables::.).
870
 
871

872
File: stabs.info,  Node: Function Types,  Prev: Unions,  Up: Types
873
 
874
Function Types
875
==============
876
 
877
   Various types can be defined for function variables.  These types are
878
not used in defining functions (*note Procedures::.); they are used for
879
things like pointers to functions.
880
 
881
   The simple, traditional, type is type descriptor `f' is followed by
882
type information for the return type of the function, followed by a
883
semicolon.
884
 
885
   This does not deal with functions for which the number and types of
886
the parameters are part of the type, as in Modula-2 or ANSI C.  AIX
887
provides extensions to specify these, using the `f', `F', `p', and `R'
888
type descriptors.
889
 
890
   First comes the type descriptor.  If it is `f' or `F', this type
891
involves a function rather than a procedure, and the type information
892
for the return type of the function follows, followed by a comma.  Then
893
comes the number of parameters to the function and a semicolon.  Then,
894
for each parameter, there is the name of the parameter followed by a
895
colon (this is only present for type descriptors `R' and `F' which
896
represent Pascal function or procedure parameters), type information
897
for the parameter, a comma, 0 if passed by reference or 1 if passed by
898
value, and a semicolon.  The type definition ends with a semicolon.
899
 
900
   For example, this variable definition:
901
 
902
     int (*g_pf)();
903
 
904
generates the following code:
905
 
906
     .stabs "g_pf:G24=*25=f1",32,0,0,0
907
         .common _g_pf,4,"bss"
908
 
909
   The variable defines a new type, 24, which is a pointer to another
910
new type, 25, which is a function returning `int'.
911
 
912

913
File: stabs.info,  Node: Symbol Tables,  Next: Cplusplus,  Prev: Types,  Up: Top
914
 
915
Symbol Information in Symbol Tables
916
***********************************
917
 
918
   This chapter describes the format of symbol table entries and how
919
stab assembler directives map to them.  It also describes the
920
transformations that the assembler and linker make on data from stabs.
921
 
922
* Menu:
923
 
924
* Symbol Table Format::
925
* Transformations On Symbol Tables::
926
 
927

928
File: stabs.info,  Node: Symbol Table Format,  Next: Transformations On Symbol Tables,  Up: Symbol Tables
929
 
930
Symbol Table Format
931
===================
932
 
933
   Each time the assembler encounters a stab directive, it puts each
934
field of the stab into a corresponding field in a symbol table entry of
935
its output file.  If the stab contains a string field, the symbol table
936
entry for that stab points to a string table entry containing the
937
string data from the stab.  Assembler labels become relocatable
938
addresses.  Symbol table entries in a.out have the format:
939
 
940
     struct internal_nlist {
941
       unsigned long n_strx;         /* index into string table of name */
942
       unsigned char n_type;         /* type of symbol */
943
       unsigned char n_other;        /* misc info (usually empty) */
944
       unsigned short n_desc;        /* description field */
945
       bfd_vma n_value;              /* value of symbol */
946
     };
947
 
948
   If the stab has a string, the `n_strx' field holds the offset in
949
bytes of the string within the string table.  The string is terminated
950
by a NUL character.  If the stab lacks a string (for example, it was
951
produced by a `.stabn' or `.stabd' directive), the `n_strx' field is
952
zero.
953
 
954
   Symbol table entries with `n_type' field values greater than 0x1f
955
originated as stabs generated by the compiler (with one random
956
exception).  The other entries were placed in the symbol table of the
957
executable by the assembler or the linker.
958
 
959

960
File: stabs.info,  Node: Transformations On Symbol Tables,  Prev: Symbol Table Format,  Up: Symbol Tables
961
 
962
Transformations on Symbol Tables
963
================================
964
 
965
   The linker concatenates object files and does fixups of externally
966
defined symbols.
967
 
968
   You can see the transformations made on stab data by the assembler
969
and linker by examining the symbol table after each pass of the build.
970
To do this, use `nm -ap', which dumps the symbol table, including
971
debugging information, unsorted.  For stab entries the columns are:
972
VALUE, OTHER, DESC, TYPE, STRING.  For assembler and linker symbols,
973
the columns are: VALUE, TYPE, STRING.
974
 
975
   The low 5 bits of the stab type tell the linker how to relocate the
976
value of the stab.  Thus for stab types like `N_RSYM' and `N_LSYM',
977
where the value is an offset or a register number, the low 5 bits are
978
`N_ABS', which tells the linker not to relocate the value.
979
 
980
   Where the value of a stab contains an assembly language label, it is
981
transformed by each build step.  The assembler turns it into a
982
relocatable address and the linker turns it into an absolute address.
983
 
984
* Menu:
985
 
986
* Transformations On Static Variables::
987
* Transformations On Global Variables::
988
* Stab Section Transformations::           For some object file formats,
989
                                           things are a bit different.
990
 
991

992
File: stabs.info,  Node: Transformations On Static Variables,  Next: Transformations On Global Variables,  Up: Transformations On Symbol Tables
993
 
994
Transformations on Static Variables
995
-----------------------------------
996
 
997
   This source line defines a static variable at file scope:
998
 
999
     static int s_g_repeat
1000
 
1001
The following stab describes the symbol:
1002
 
1003
     .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat
1004
 
1005
The assembler transforms the stab into this symbol table entry in the
1006
`.o' file.  The location is expressed as a data segment offset.
1007
 
1008
     00000084 - 00 0000 STSYM s_g_repeat:S1
1009
 
1010
In the symbol table entry from the executable, the linker has made the
1011
relocatable address absolute.
1012
 
1013
     0000e00c - 00 0000 STSYM s_g_repeat:S1
1014
 
1015

1016
File: stabs.info,  Node: Transformations On Global Variables,  Next: Stab Section Transformations,  Prev: Transformations On Static Variables,  Up: Transformations On Symbol Tables
1017
 
1018
Transformations on Global Variables
1019
-----------------------------------
1020
 
1021
   Stabs for global variables do not contain location information. In
1022
this case, the debugger finds location information in the assembler or
1023
linker symbol table entry describing the variable.  The source line:
1024
 
1025
     char g_foo = 'c';
1026
 
1027
generates the stab:
1028
 
1029
     .stabs "g_foo:G2",32,0,0,0
1030
 
1031
   The variable is represented by two symbol table entries in the object
1032
file (see below).  The first one originated as a stab.  The second one
1033
is an external symbol.  The upper case `D' signifies that the `n_type'
1034
field of the symbol table contains 7, `N_DATA' with local linkage.  The
1035
stab's value is zero since the value is not used for `N_GSYM' stabs.
1036
The value of the linker symbol is the relocatable address corresponding
1037
to the variable.
1038
 
1039
     00000000 - 00 0000  GSYM g_foo:G2
1040
     00000080 D _g_foo
1041
 
1042
These entries as transformed by the linker.  The linker symbol table
1043
entry now holds an absolute address:
1044
 
1045
     00000000 - 00 0000  GSYM g_foo:G2
1046
     ...
1047
     0000e008 D _g_foo
1048
 
1049

1050
File: stabs.info,  Node: Stab Section Transformations,  Prev: Transformations On Global Variables,  Up: Transformations On Symbol Tables
1051
 
1052
Transformations of Stabs in separate sections
1053
---------------------------------------------
1054
 
1055
   For object file formats using stabs in separate sections (*note Stab
1056
Sections::.), use `objdump --stabs' instead of `nm' to show the stabs
1057
in an object or executable file.  `objdump' is a GNU utility; Sun does
1058
not provide any equivalent.
1059
 
1060
   The following example is for a stab whose value is an address is
1061
relative to the compilation unit (*note ELF Linker Relocation::.).  For
1062
example, if the source line
1063
 
1064
     static int ld = 5;
1065
 
1066
   appears within a function, then the assembly language output from the
1067
compiler contains:
1068
 
1069
     .Ddata.data:
1070
     ...
1071
             .stabs "ld:V(0,3)",0x26,0,4,.L18-Ddata.data    # 0x26 is N_STSYM
1072
     ...
1073
     .L18:
1074
             .align 4
1075
             .word 0x5
1076
 
1077
   Because the value is formed by subtracting one symbol from another,
1078
the value is absolute, not relocatable, and so the object file contains
1079
 
1080
     Symnum n_type n_othr n_desc n_value  n_strx String
1081
     31     STSYM  0      4      00000004 680    ld:V(0,3)
1082
 
1083
   without any relocations, and the executable file also contains
1084
 
1085
     Symnum n_type n_othr n_desc n_value  n_strx String
1086
     31     STSYM  0      4      00000004 680    ld:V(0,3)
1087
 
1088

1089
File: stabs.info,  Node: Cplusplus,  Next: Stab Types,  Prev: Symbol Tables,  Up: Top
1090
 
1091
GNU C++ Stabs
1092
*************
1093
 
1094
* Menu:
1095
 
1096
* Class Names::                 C++ class names are both tags and typedefs.
1097
* Nested Symbols::              C++ symbol names can be within other types.
1098
* Basic Cplusplus Types::
1099
* Simple Classes::
1100
* Class Instance::
1101
* Methods::                     Method definition
1102
* Method Type Descriptor::      The `#' type descriptor
1103
* Member Type Descriptor::      The `@' type descriptor
1104
* Protections::
1105
* Method Modifiers::
1106
* Virtual Methods::
1107
* Inheritence::
1108
* Virtual Base Classes::
1109
* Static Members::
1110
 
1111

1112
File: stabs.info,  Node: Class Names,  Next: Nested Symbols,  Up: Cplusplus
1113
 
1114
C++ Class Names
1115
===============
1116
 
1117
   In C++, a class name which is declared with `class', `struct', or
1118
`union', is not only a tag, as in C, but also a type name.  Thus there
1119
should be stabs with both `t' and `T' symbol descriptors (*note
1120
Typedefs::.).
1121
 
1122
   To save space, there is a special abbreviation for this case.  If the
1123
`T' symbol descriptor is followed by `t', then the stab defines both a
1124
type name and a tag.
1125
 
1126
   For example, the C++ code
1127
 
1128
     struct foo {int x;};
1129
 
1130
   can be represented as either
1131
 
1132
     .stabs "foo:T19=s4x:1,0,32;;",128,0,0,0       # 128 is N_LSYM
1133
     .stabs "foo:t19",128,0,0,0
1134
 
1135
   or
1136
 
1137
     .stabs "foo:Tt19=s4x:1,0,32;;",128,0,0,0
1138
 
1139

1140
File: stabs.info,  Node: Nested Symbols,  Next: Basic Cplusplus Types,  Prev: Class Names,  Up: Cplusplus
1141
 
1142
Defining a Symbol Within Another Type
1143
=====================================
1144
 
1145
   In C++, a symbol (such as a type name) can be defined within another
1146
type.
1147
 
1148
   In stabs, this is sometimes represented by making the name of a
1149
symbol which contains `::'.  Such a pair of colons does not end the name
1150
of the symbol, the way a single colon would (*note String Field::.).
1151
I'm not sure how consistently used or well thought out this mechanism
1152
is.  So that a pair of colons in this position always has this meaning,
1153
`:' cannot be used as a symbol descriptor.
1154
 
1155
   For example, if the string for a stab is `foo::bar::baz:t5=*6', then
1156
`foo::bar::baz' is the name of the symbol, `t' is the symbol
1157
descriptor, and `5=*6' is the type information.
1158
 
1159

1160
File: stabs.info,  Node: Basic Cplusplus Types,  Next: Simple Classes,  Prev: Nested Symbols,  Up: Cplusplus
1161
 
1162
Basic Types For C++
1163
===================
1164
 
1165
   << the examples that follow are based on a01.C >>
1166
 
1167
   C++ adds two more builtin types to the set defined for C.  These are
1168
the unknown type and the vtable record type.  The unknown type, type
1169
16, is defined in terms of itself like the void type.
1170
 
1171
   The vtable record type, type 17, is defined as a structure type and
1172
then as a structure tag.  The structure has four fields: delta, index,
1173
pfn, and delta2.  pfn is the function pointer.
1174
 
1175
   << In boilerplate $vtbl_ptr_type, what are the fields delta, index,
1176
and delta2 used for? >>
1177
 
1178
   This basic type is present in all C++ programs even if there are no
1179
virtual methods defined.
1180
 
1181
     .stabs "struct_name:sym_desc(type)type_def(17)=type_desc(struct)struct_bytes(8)
1182
             elem_name(delta):type_ref(short int),bit_offset(0),field_bits(16);
1183
             elem_name(index):type_ref(short int),bit_offset(16),field_bits(16);
1184
             elem_name(pfn):type_def(18)=type_desc(ptr to)type_ref(void),
1185
                                         bit_offset(32),field_bits(32);
1186
             elem_name(delta2):type_def(short int);bit_offset(32),field_bits(16);;"
1187
             N_LSYM, NIL, NIL
1188
 
1189
     .stabs "$vtbl_ptr_type:t17=s8
1190
             delta:6,0,16;index:6,16,16;pfn:18=*15,32,32;delta2:6,32,16;;"
1191
             ,128,0,0,0
1192
 
1193
     .stabs "name:sym_dec(struct tag)type_ref($vtbl_ptr_type)",N_LSYM,NIL,NIL,NIL
1194
 
1195
     .stabs "$vtbl_ptr_type:T17",128,0,0,0
1196
 
1197

1198
File: stabs.info,  Node: Simple Classes,  Next: Class Instance,  Prev: Basic Cplusplus Types,  Up: Cplusplus
1199
 
1200
Simple Class Definition
1201
=======================
1202
 
1203
   The stabs describing C++ language features are an extension of the
1204
stabs describing C.  Stabs representing C++ class types elaborate
1205
extensively on the stab format used to describe structure types in C.
1206
Stabs representing class type variables look just like stabs
1207
representing C language variables.
1208
 
1209
   Consider the following very simple class definition.
1210
 
1211
     class baseA {
1212
     public:
1213
             int Adat;
1214
             int Ameth(int in, char other);
1215
     };
1216
 
1217
   The class `baseA' is represented by two stabs.  The first stab
1218
describes the class as a structure type.  The second stab describes a
1219
structure tag of the class type.  Both stabs are of stab type `N_LSYM'.
1220
Since the stab is not located between an `N_FUN' and an `N_LBRAC' stab
1221
this indicates that the class is defined at file scope.  If it were,
1222
then the `N_LSYM' would signify a local variable.
1223
 
1224
   A stab describing a C++ class type is similar in format to a stab
1225
describing a C struct, with each class member shown as a field in the
1226
structure.  The part of the struct format describing fields is expanded
1227
to include extra information relevent to C++ class members.  In
1228
addition, if the class has multiple base classes or virtual functions
1229
the struct format outside of the field parts is also augmented.
1230
 
1231
   In this simple example the field part of the C++ class stab
1232
representing member data looks just like the field part of a C struct
1233
stab.  The section on protections describes how its format is sometimes
1234
extended for member data.
1235
 
1236
   The field part of a C++ class stab representing a member function
1237
differs substantially from the field part of a C struct stab.  It still
1238
begins with `name:' but then goes on to define a new type number for
1239
the member function, describe its return type, its argument types, its
1240
protection level, any qualifiers applied to the method definition, and
1241
whether the method is virtual or not.  If the method is virtual then
1242
the method description goes on to give the vtable index of the method,
1243
and the type number of the first base class defining the method.
1244
 
1245
   When the field name is a method name it is followed by two colons
1246
rather than one.  This is followed by a new type definition for the
1247
method.  This is a number followed by an equal sign and the type of the
1248
method.  Normally this will be a type declared using the `#' type
1249
descriptor; see *Note Method Type Descriptor::; static member functions
1250
are declared using the `f' type descriptor instead; see *Note Function
1251
Types::.
1252
 
1253
   The format of an overloaded operator method name differs from that of
1254
other methods.  It is `op$::OPERATOR-NAME.' where OPERATOR-NAME is the
1255
operator name such as `+' or `+='.  The name ends with a period, and
1256
any characters except the period can occur in the OPERATOR-NAME string.
1257
 
1258
   The next part of the method description represents the arguments to
1259
the method, preceeded by a colon and ending with a semi-colon.  The
1260
types of the arguments are expressed in the same way argument types are
1261
expressed in C++ name mangling.  In this example an `int' and a `char'
1262
map to `ic'.
1263
 
1264
   This is followed by a number, a letter, and an asterisk or period,
1265
followed by another semicolon.  The number indicates the protections
1266
that apply to the member function.  Here the 2 means public.  The
1267
letter encodes any qualifier applied to the method definition.  In this
1268
case, `A' means that it is a normal function definition.  The dot shows
1269
that the method is not virtual.  The sections that follow elaborate
1270
further on these fields and describe the additional information present
1271
for virtual methods.
1272
 
1273
     .stabs "class_name:sym_desc(type)type_def(20)=type_desc(struct)struct_bytes(4)
1274
             field_name(Adat):type(int),bit_offset(0),field_bits(32);
1275
 
1276
             method_name(Ameth)::type_def(21)=type_desc(method)return_type(int);
1277
             :arg_types(int char);
1278
             protection(public)qualifier(normal)virtual(no);;"
1279
             N_LSYM,NIL,NIL,NIL
1280
 
1281
     .stabs "baseA:t20=s4Adat:1,0,32;Ameth::21=##1;:ic;2A.;;",128,0,0,0
1282
 
1283
     .stabs "class_name:sym_desc(struct tag)",N_LSYM,NIL,NIL,NIL
1284
 
1285
     .stabs "baseA:T20",128,0,0,0
1286
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.