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

Subversion Repositories or1k

[/] [or1k/] [trunk/] [gdb-5.3/] [gdb/] [doc/] [stabs.info-3] - Blame information for rev 1773

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

Line No. Rev Author Line
1 1181 sfurman
This is stabs.info, produced by makeinfo version 4.1 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,1993,1994,1995,1997,1998,2000,2001    Free Software
11
Foundation, Inc.  Contributed by Cygnus Support.  Written by Julia
12
Menapace, Jim Kingdon, and David MacKenzie.
13
 
14
   Permission is granted to copy, distribute and/or modify this document
15
under the terms of the GNU Free Documentation License, Version 1.1 or
16
any later version published by the Free Software Foundation; with no
17
Invariant Sections, with the Front-Cover Texts being "A GNU Manual,"
18
and with the Back-Cover Texts as in (a) below.
19
 
20
   (a) The FSF's Back-Cover Text is: "You have freedom to copy and
21
modify this GNU Manual, like GNU software.  Copies published by the Free
22
Software Foundation raise funds for GNU development."
23
 
24

25
File: stabs.info,  Node: Class Instance,  Next: Methods,  Prev: Simple Classes,  Up: Cplusplus
26
 
27
Class Instance
28
==============
29
 
30
   As shown above, describing even a simple C++ class definition is
31
accomplished by massively extending the stab format used in C to
32
describe structure types.  However, once the class is defined, C stabs
33
with no modifications can be used to describe class instances.  The
34
following source:
35
 
36
     main () {
37
             baseA AbaseA;
38
     }
39
 
40
yields the following stab describing the class instance.  It looks no
41
different from a standard C stab describing a local variable.
42
 
43
     .stabs "name:type_ref(baseA)", N_LSYM, NIL, NIL, frame_ptr_offset
44
 
45
     .stabs "AbaseA:20",128,0,0,-20
46
 
47

48
File: stabs.info,  Node: Methods,  Next: Method Type Descriptor,  Prev: Class Instance,  Up: Cplusplus
49
 
50
Method Definition
51
=================
52
 
53
   The class definition shown above declares Ameth.  The C++ source
54
below defines Ameth:
55
 
56
     int
57
     baseA::Ameth(int in, char other)
58
     {
59
             return in;
60
     };
61
 
62
   This method definition yields three stabs following the code of the
63
method.  One stab describes the method itself and following two describe
64
its parameters.  Although there is only one formal argument all methods
65
have an implicit argument which is the `this' pointer.  The `this'
66
pointer is a pointer to the object on which the method was called.  Note
67
that the method name is mangled to encode the class name and argument
68
types.  Name mangling is described in the ARM (`The Annotated C++
69
Reference Manual', by Ellis and Stroustrup, ISBN 0-201-51459-1);
70
`gpcompare.texi' in Cygnus GCC distributions describes the differences
71
between GNU mangling and ARM mangling.
72
 
73
     .stabs "name:symbol_descriptor(global function)return_type(int)",
74
             N_FUN, NIL, NIL, code_addr_of_method_start
75
 
76
     .stabs "Ameth__5baseAic:F1",36,0,0,_Ameth__5baseAic
77
 
78
   Here is the stab for the `this' pointer implicit argument.  The name
79
of the `this' pointer is always `this'.  Type 19, the `this' pointer is
80
defined as a pointer to type 20, `baseA', but a stab defining `baseA'
81
has not yet been emitted.  Since the compiler knows it will be emitted
82
shortly, here it just outputs a cross reference to the undefined
83
symbol, by prefixing the symbol name with `xs'.
84
 
85
     .stabs "name:sym_desc(register param)type_def(19)=
86
             type_desc(ptr to)type_ref(baseA)=
87
             type_desc(cross-reference to)baseA:",N_RSYM,NIL,NIL,register_number
88
 
89
     .stabs "this:P19=*20=xsbaseA:",64,0,0,8
90
 
91
   The stab for the explicit integer argument looks just like a
92
parameter to a C function.  The last field of the stab is the offset
93
from the argument pointer, which in most systems is the same as the
94
frame pointer.
95
 
96
     .stabs "name:sym_desc(value parameter)type_ref(int)",
97
             N_PSYM,NIL,NIL,offset_from_arg_ptr
98
 
99
     .stabs "in:p1",160,0,0,72
100
 
101
   << The examples that follow are based on A1.C >>
102
 
103

104
File: stabs.info,  Node: Method Type Descriptor,  Next: Member Type Descriptor,  Prev: Methods,  Up: Cplusplus
105
 
106
The `#' Type Descriptor
107
=======================
108
 
109
   This is used to describe a class method.  This is a function which
110
takes an extra argument as its first argument, for the `this' pointer.
111
 
112
   If the `#' is immediately followed by another `#', the second one
113
will be followed by the return type and a semicolon.  The class and
114
argument types are not specified, and must be determined by demangling
115
the name of the method if it is available.
116
 
117
   Otherwise, the single `#' is followed by the class type, a comma,
118
the return type, a comma, and zero or more parameter types separated by
119
commas.  The list of arguments is terminated by a semicolon.  In the
120
debugging output generated by gcc, a final argument type of `void'
121
indicates a method which does not take a variable number of arguments.
122
If the final argument type of `void' does not appear, the method was
123
declared with an ellipsis.
124
 
125
   Note that although such a type will normally be used to describe
126
fields in structures, unions, or classes, for at least some versions of
127
the compiler it can also be used in other contexts.
128
 
129

130
File: stabs.info,  Node: Member Type Descriptor,  Next: Protections,  Prev: Method Type Descriptor,  Up: Cplusplus
131
 
132
The `@' Type Descriptor
133
=======================
134
 
135
   The `@' type descriptor is for a member (class and variable) type.
136
It is followed by type information for the offset basetype, a comma, and
137
type information for the type of the field being pointed to.  (FIXME:
138
this is acknowledged to be gibberish.  Can anyone say what really goes
139
here?).
140
 
141
   Note that there is a conflict between this and type attributes
142
(*note String Field::); both use type descriptor `@'.  Fortunately, the
143
`@' type descriptor used in this C++ sense always will be followed by a
144
digit, `(', or `-', and type attributes never start with those things.
145
 
146

147
File: stabs.info,  Node: Protections,  Next: Method Modifiers,  Prev: Member Type Descriptor,  Up: Cplusplus
148
 
149
Protections
150
===========
151
 
152
   In the simple class definition shown above all member data and
153
functions were publicly accessible.  The example that follows contrasts
154
public, protected and privately accessible fields and shows how these
155
protections are encoded in C++ stabs.
156
 
157
   If the character following the `FIELD-NAME:' part of the string is
158
`/', then the next character is the visibility.  `0' means private, `1'
159
means protected, and `2' means public.  Debuggers should ignore
160
visibility characters they do not recognize, and assume a reasonable
161
default (such as public) (GDB 4.11 does not, but this should be fixed
162
in the next GDB release).  If no visibility is specified the field is
163
public.  The visibility `9' means that the field has been optimized out
164
and is public (there is no way to specify an optimized out field with a
165
private or protected visibility).  Visibility `9' is not supported by
166
GDB 4.11; this should be fixed in the next GDB release.
167
 
168
   The following C++ source:
169
 
170
     class vis {
171
     private:
172
             int   priv;
173
     protected:
174
             char  prot;
175
     public:
176
             float pub;
177
     };
178
 
179
generates the following stab:
180
 
181
     # 128 is N_LSYM
182
     .stabs "vis:T19=s12priv:/01,0,32;prot:/12,32,8;pub:12,64,32;;",128,0,0,0
183
 
184
   `vis:T19=s12' indicates that type number 19 is a 12 byte structure
185
named `vis' The `priv' field has public visibility (`/0'), type int
186
(`1'), and offset and size `,0,32;'.  The `prot' field has protected
187
visibility (`/1'), type char (`2') and offset and size `,32,8;'.  The
188
`pub' field has type float (`12'), and offset and size `,64,32;'.
189
 
190
   Protections for member functions are signified by one digit embedded
191
in the field part of the stab describing the method.  The digit is 0 if
192
private, 1 if protected and 2 if public.  Consider the C++ class
193
definition below:
194
 
195
     class all_methods {
196
     private:
197
             int   priv_meth(int in){return in;};
198
     protected:
199
             char  protMeth(char in){return in;};
200
     public:
201
             float pubMeth(float in){return in;};
202
     };
203
 
204
   It generates the following stab.  The digit in question is to the
205
left of an `A' in each case.  Notice also that in this case two symbol
206
descriptors apply to the class name struct tag and struct type.
207
 
208
     .stabs "class_name:sym_desc(struct tag&type)type_def(21)=
209
             sym_desc(struct)struct_bytes(1)
210
             meth_name::type_def(22)=sym_desc(method)returning(int);
211
             :args(int);protection(private)modifier(normal)virtual(no);
212
             meth_name::type_def(23)=sym_desc(method)returning(char);
213
             :args(char);protection(protected)modifier(normal)virtual(no);
214
             meth_name::type_def(24)=sym_desc(method)returning(float);
215
             :args(float);protection(public)modifier(normal)virtual(no);;",
216
             N_LSYM,NIL,NIL,NIL
217
 
218
     .stabs "all_methods:Tt21=s1priv_meth::22=##1;:i;0A.;protMeth::23=##2;:c;1A.;
219
             pubMeth::24=##12;:f;2A.;;",128,0,0,0
220
 
221

222
File: stabs.info,  Node: Method Modifiers,  Next: Virtual Methods,  Prev: Protections,  Up: Cplusplus
223
 
224
Method Modifiers (`const', `volatile', `const volatile')
225
========================================================
226
 
227
   << based on a6.C >>
228
 
229
   In the class example described above all the methods have the normal
230
modifier.  This method modifier information is located just after the
231
protection information for the method.  This field has four possible
232
character values.  Normal methods use `A', const methods use `B',
233
volatile methods use `C', and const volatile methods use `D'.  Consider
234
the class definition below:
235
 
236
     class A {
237
     public:
238
             int ConstMeth (int arg) const { return arg; };
239
             char VolatileMeth (char arg) volatile { return arg; };
240
             float ConstVolMeth (float arg) const volatile {return arg; };
241
     };
242
 
243
   This class is described by the following stab:
244
 
245
     .stabs "class(A):sym_desc(struct)type_def(20)=type_desc(struct)struct_bytes(1)
246
             meth_name(ConstMeth)::type_def(21)sym_desc(method)
247
             returning(int);:arg(int);protection(public)modifier(const)virtual(no);
248
             meth_name(VolatileMeth)::type_def(22)=sym_desc(method)
249
             returning(char);:arg(char);protection(public)modifier(volatile)virt(no)
250
             meth_name(ConstVolMeth)::type_def(23)=sym_desc(method)
251
             returning(float);:arg(float);protection(public)modifier(const volatile)
252
             virtual(no);;", ...
253
 
254
     .stabs "A:T20=s1ConstMeth::21=##1;:i;2B.;VolatileMeth::22=##2;:c;2C.;
255
                  ConstVolMeth::23=##12;:f;2D.;;",128,0,0,0
256
 
257

258
File: stabs.info,  Node: Virtual Methods,  Next: Inheritance,  Prev: Method Modifiers,  Up: Cplusplus
259
 
260
Virtual Methods
261
===============
262
 
263
   << The following examples are based on a4.C >>
264
 
265
   The presence of virtual methods in a class definition adds additional
266
data to the class description.  The extra data is appended to the
267
description of the virtual method and to the end of the class
268
description.  Consider the class definition below:
269
 
270
     class A {
271
     public:
272
             int Adat;
273
             virtual int A_virt (int arg) { return arg; };
274
     };
275
 
276
   This results in the stab below describing class A.  It defines a new
277
type (20) which is an 8 byte structure.  The first field of the class
278
struct is `Adat', an integer, starting at structure offset 0 and
279
occupying 32 bits.
280
 
281
   The second field in the class struct is not explicitly defined by the
282
C++ class definition but is implied by the fact that the class contains
283
a virtual method.  This field is the vtable pointer.  The name of the
284
vtable pointer field starts with `$vf' and continues with a type
285
reference to the class it is part of.  In this example the type
286
reference for class A is 20 so the name of its vtable pointer field is
287
`$vf20', followed by the usual colon.
288
 
289
   Next there is a type definition for the vtable pointer type (21).
290
This is in turn defined as a pointer to another new type (22).
291
 
292
   Type 22 is the vtable itself, which is defined as an array, indexed
293
by a range of integers between 0 and 1, and whose elements are of type
294
17.  Type 17 was the vtable record type defined by the boilerplate C++
295
type definitions, as shown earlier.
296
 
297
   The bit offset of the vtable pointer field is 32.  The number of bits
298
in the field are not specified when the field is a vtable pointer.
299
 
300
   Next is the method definition for the virtual member function
301
`A_virt'.  Its description starts out using the same format as the
302
non-virtual member functions described above, except instead of a dot
303
after the `A' there is an asterisk, indicating that the function is
304
virtual.  Since is is virtual some addition information is appended to
305
the end of the method description.
306
 
307
   The first number represents the vtable index of the method.  This is
308
a 32 bit unsigned number with the high bit set, followed by a
309
semi-colon.
310
 
311
   The second number is a type reference to the first base class in the
312
inheritance hierarchy defining the virtual member function.  In this
313
case the class stab describes a base class so the virtual function is
314
not overriding any other definition of the method.  Therefore the
315
reference is to the type number of the class that the stab is
316
describing (20).
317
 
318
   This is followed by three semi-colons.  One marks the end of the
319
current sub-section, one marks the end of the method field, and the
320
third marks the end of the struct definition.
321
 
322
   For classes containing virtual functions the very last section of the
323
string part of the stab holds a type reference to the first base class.
324
This is preceded by `~%' and followed by a final semi-colon.
325
 
326
     .stabs "class_name(A):type_def(20)=sym_desc(struct)struct_bytes(8)
327
             field_name(Adat):type_ref(int),bit_offset(0),field_bits(32);
328
             field_name(A virt func ptr):type_def(21)=type_desc(ptr to)type_def(22)=
329
             sym_desc(array)index_type_ref(range of int from 0 to 1);
330
             elem_type_ref(vtbl elem type),
331
             bit_offset(32);
332
             meth_name(A_virt)::typedef(23)=sym_desc(method)returning(int);
333
             :arg_type(int),protection(public)normal(yes)virtual(yes)
334
             vtable_index(1);class_first_defining(A);;;~%first_base(A);",
335
             N_LSYM,NIL,NIL,NIL
336
 
337
     .stabs "A:t20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32;
338
             A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0
339
 
340

341
File: stabs.info,  Node: Inheritance,  Next: Virtual Base Classes,  Prev: Virtual Methods,  Up: Cplusplus
342
 
343
Inheritance
344
===========
345
 
346
   Stabs describing C++ derived classes include additional sections that
347
describe the inheritance hierarchy of the class.  A derived class stab
348
also encodes the number of base classes.  For each base class it tells
349
if the base class is virtual or not, and if the inheritance is private
350
or public.  It also gives the offset into the object of the portion of
351
the object corresponding to each base class.
352
 
353
   This additional information is embedded in the class stab following
354
the number of bytes in the struct.  First the number of base classes
355
appears bracketed by an exclamation point and a comma.
356
 
357
   Then for each base type there repeats a series: a virtual character,
358
a visibility character, a number, a comma, another number, and a
359
semi-colon.
360
 
361
   The virtual character is `1' if the base class is virtual and `0' if
362
not.  The visibility character is `2' if the derivation is public, `1'
363
if it is protected, and `0' if it is private.  Debuggers should ignore
364
virtual or visibility characters they do not recognize, and assume a
365
reasonable default (such as public and non-virtual) (GDB 4.11 does not,
366
but this should be fixed in the next GDB release).
367
 
368
   The number following the virtual and visibility characters is the
369
offset from the start of the object to the part of the object
370
pertaining to the base class.
371
 
372
   After the comma, the second number is a type_descriptor for the base
373
type.  Finally a semi-colon ends the series, which repeats for each
374
base class.
375
 
376
   The source below defines three base classes `A', `B', and `C' and
377
the derived class `D'.
378
 
379
     class A {
380
     public:
381
             int Adat;
382
             virtual int A_virt (int arg) { return arg; };
383
     };
384
 
385
     class B {
386
     public:
387
             int B_dat;
388
             virtual int B_virt (int arg) {return arg; };
389
     };
390
 
391
     class C {
392
     public:
393
             int Cdat;
394
             virtual int C_virt (int arg) {return arg; };
395
     };
396
 
397
     class D : A, virtual B, public C {
398
     public:
399
             int Ddat;
400
             virtual int A_virt (int arg ) { return arg+1; };
401
             virtual int B_virt (int arg)  { return arg+2; };
402
             virtual int C_virt (int arg)  { return arg+3; };
403
             virtual int D_virt (int arg)  { return arg; };
404
     };
405
 
406
   Class stabs similar to the ones described earlier are generated for
407
each base class.
408
 
409
     .stabs "A:T20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32;
410
             A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0
411
 
412
     .stabs "B:Tt25=s8Bdat:1,0,32;$vf25:21,32;B_virt::26=##1;
413
             :i;2A*-2147483647;25;;;~%25;",128,0,0,0
414
 
415
     .stabs "C:Tt28=s8Cdat:1,0,32;$vf28:21,32;C_virt::29=##1;
416
             :i;2A*-2147483647;28;;;~%28;",128,0,0,0
417
 
418
   In the stab describing derived class `D' below, the information about
419
the derivation of this class is encoded as follows.
420
 
421
     .stabs "derived_class_name:symbol_descriptors(struct tag&type)=
422
             type_descriptor(struct)struct_bytes(32)!num_bases(3),
423
             base_virtual(no)inheritance_public(no)base_offset(0),
424
             base_class_type_ref(A);
425
             base_virtual(yes)inheritance_public(no)base_offset(NIL),
426
             base_class_type_ref(B);
427
             base_virtual(no)inheritance_public(yes)base_offset(64),
428
             base_class_type_ref(C); ...
429
 
430
     .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:
431
             1,160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt:
432
             :32:i;2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;
433
             28;;D_virt::32:i;2A*-2147483646;31;;;~%20;",128,0,0,0
434
 
435

436
File: stabs.info,  Node: Virtual Base Classes,  Next: Static Members,  Prev: Inheritance,  Up: Cplusplus
437
 
438
Virtual Base Classes
439
====================
440
 
441
   A derived class object consists of a concatenation in memory of the
442
data areas defined by each base class, starting with the leftmost and
443
ending with the rightmost in the list of base classes.  The exception
444
to this rule is for virtual inheritance.  In the example above, class
445
`D' inherits virtually from base class `B'.  This means that an
446
instance of a `D' object will not contain its own `B' part but merely a
447
pointer to a `B' part, known as a virtual base pointer.
448
 
449
   In a derived class stab, the base offset part of the derivation
450
information, described above, shows how the base class parts are
451
ordered.  The base offset for a virtual base class is always given as 0.
452
Notice that the base offset for `B' is given as 0 even though `B' is
453
not the first base class.  The first base class `A' starts at offset 0.
454
 
455
   The field information part of the stab for class `D' describes the
456
field which is the pointer to the virtual base class `B'. The vbase
457
pointer name is `$vb' followed by a type reference to the virtual base
458
class.  Since the type id for `B' in this example is 25, the vbase
459
pointer name is `$vb25'.
460
 
461
     .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:1,
462
            160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt::32:i;
463
            2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;28;;D_virt:
464
            :32:i;2A*-2147483646;31;;;~%20;",128,0,0,0
465
 
466
   Following the name and a semicolon is a type reference describing the
467
type of the virtual base class pointer, in this case 24.  Type 24 was
468
defined earlier as the type of the `B' class `this' pointer.  The
469
`this' pointer for a class is a pointer to the class type.
470
 
471
     .stabs "this:P24=*25=xsB:",64,0,0,8
472
 
473
   Finally the field offset part of the vbase pointer field description
474
shows that the vbase pointer is the first field in the `D' object,
475
before any data fields defined by the class.  The layout of a `D' class
476
object is a follows, `Adat' at 0, the vtable pointer for `A' at 32,
477
`Cdat' at 64, the vtable pointer for C at 96, the virtual base pointer
478
for `B' at 128, and `Ddat' at 160.
479
 
480

481
File: stabs.info,  Node: Static Members,  Prev: Virtual Base Classes,  Up: Cplusplus
482
 
483
Static Members
484
==============
485
 
486
   The data area for a class is a concatenation of the space used by the
487
data members of the class.  If the class has virtual methods, a vtable
488
pointer follows the class data.  The field offset part of each field
489
description in the class stab shows this ordering.
490
 
491
   << How is this reflected in stabs?  See Cygnus bug #677 for some
492
info.  >>
493
 
494

495
File: stabs.info,  Node: Stab Types,  Next: Symbol Descriptors,  Prev: Cplusplus,  Up: Top
496
 
497
Table of Stab Types
498
*******************
499
 
500
   The following are all the possible values for the stab type field,
501
for a.out files, in numeric order.  This does not apply to XCOFF, but
502
it does apply to stabs in sections (*note Stab Sections::).  Stabs in
503
ECOFF use these values but add 0x8f300 to distinguish them from non-stab
504
symbols.
505
 
506
   The symbolic names are defined in the file `include/aout/stabs.def'.
507
 
508
* Menu:
509
 
510
* Non-Stab Symbol Types::       Types from 0 to 0x1f
511
* Stab Symbol Types::           Types from 0x20 to 0xff
512
 
513

514
File: stabs.info,  Node: Non-Stab Symbol Types,  Next: Stab Symbol Types,  Up: Stab Types
515
 
516
Non-Stab Symbol Types
517
=====================
518
 
519
   The following types are used by the linker and assembler, not by stab
520
directives.  Since this document does not attempt to describe aspects of
521
object file format other than the debugging format, no details are
522
given.
523
 
524
`0x0     N_UNDF'
525
     Undefined symbol
526
 
527
`0x2     N_ABS'
528
     File scope absolute symbol
529
 
530
`0x3     N_ABS | N_EXT'
531
     External absolute symbol
532
 
533
`0x4     N_TEXT'
534
     File scope text symbol
535
 
536
`0x5     N_TEXT | N_EXT'
537
     External text symbol
538
 
539
`0x6     N_DATA'
540
     File scope data symbol
541
 
542
`0x7     N_DATA | N_EXT'
543
     External data symbol
544
 
545
`0x8     N_BSS'
546
     File scope BSS symbol
547
 
548
`0x9     N_BSS | N_EXT'
549
     External BSS symbol
550
 
551
`0x0c    N_FN_SEQ'
552
     Same as `N_FN', for Sequent compilers
553
 
554
`0x0a    N_INDR'
555
     Symbol is indirected to another symbol
556
 
557
`0x12    N_COMM'
558
     Common--visible after shared library dynamic link
559
 
560
`0x14 N_SETA'
561
`0x15 N_SETA | N_EXT'
562
     Absolute set element
563
 
564
`0x16 N_SETT'
565
`0x17 N_SETT | N_EXT'
566
     Text segment set element
567
 
568
`0x18 N_SETD'
569
`0x19 N_SETD | N_EXT'
570
     Data segment set element
571
 
572
`0x1a N_SETB'
573
`0x1b N_SETB | N_EXT'
574
     BSS segment set element
575
 
576
`0x1c N_SETV'
577
`0x1d N_SETV | N_EXT'
578
     Pointer to set vector
579
 
580
`0x1e N_WARNING'
581
     Print a warning message during linking
582
 
583
`0x1f    N_FN'
584
     File name of a `.o' file
585
 
586

587
File: stabs.info,  Node: Stab Symbol Types,  Prev: Non-Stab Symbol Types,  Up: Stab Types
588
 
589
Stab Symbol Types
590
=================
591
 
592
   The following symbol types indicate that this is a stab.  This is the
593
full list of stab numbers, including stab types that are used in
594
languages other than C.
595
 
596
`0x20     N_GSYM'
597
     Global symbol; see *Note Global Variables::.
598
 
599
`0x22     N_FNAME'
600
     Function name (for BSD Fortran); see *Note Procedures::.
601
 
602
`0x24     N_FUN'
603
     Function name (*note Procedures::) or text segment variable (*note
604
     Statics::).
605
 
606
`0x26 N_STSYM'
607
     Data segment file-scope variable; see *Note Statics::.
608
 
609
`0x28 N_LCSYM'
610
     BSS segment file-scope variable; see *Note Statics::.
611
 
612
`0x2a N_MAIN'
613
     Name of main routine; see *Note Main Program::.
614
 
615
`0x2c N_ROSYM'
616
     Variable in `.rodata' section; see *Note Statics::.
617
 
618
`0x30     N_PC'
619
     Global symbol (for Pascal); see *Note N_PC::.
620
 
621
`0x32     N_NSYMS'
622
     Number of symbols (according to Ultrix V4.0); see *Note N_NSYMS::.
623
 
624
`0x34     N_NOMAP'
625
     No DST map; see *Note N_NOMAP::.
626
 
627
`0x38 N_OBJ'
628
     Object file (Solaris2).
629
 
630
`0x3c N_OPT'
631
     Debugger options (Solaris2).
632
 
633
`0x40     N_RSYM'
634
     Register variable; see *Note Register Variables::.
635
 
636
`0x42     N_M2C'
637
     Modula-2 compilation unit; see *Note N_M2C::.
638
 
639
`0x44     N_SLINE'
640
     Line number in text segment; see *Note Line Numbers::.
641
 
642
`0x46     N_DSLINE'
643
     Line number in data segment; see *Note Line Numbers::.
644
 
645
`0x48     N_BSLINE'
646
     Line number in bss segment; see *Note Line Numbers::.
647
 
648
`0x48     N_BROWS'
649
     Sun source code browser, path to `.cb' file; see *Note N_BROWS::.
650
 
651
`0x4a     N_DEFD'
652
     GNU Modula2 definition module dependency; see *Note N_DEFD::.
653
 
654
`0x4c N_FLINE'
655
     Function start/body/end line numbers (Solaris2).
656
 
657
`0x50     N_EHDECL'
658
     GNU C++ exception variable; see *Note N_EHDECL::.
659
 
660
`0x50     N_MOD2'
661
     Modula2 info "for imc" (according to Ultrix V4.0); see *Note
662
     N_MOD2::.
663
 
664
`0x54     N_CATCH'
665
     GNU C++ `catch' clause; see *Note N_CATCH::.
666
 
667
`0x60     N_SSYM'
668
     Structure of union element; see *Note N_SSYM::.
669
 
670
`0x62 N_ENDM'
671
     Last stab for module (Solaris2).
672
 
673
`0x64     N_SO'
674
     Path and name of source file; see *Note Source Files::.
675
 
676
`0x80 N_LSYM'
677
     Stack variable (*note Stack Variables::) or type (*note
678
     Typedefs::).
679
 
680
`0x82     N_BINCL'
681
     Beginning of an include file (Sun only); see *Note Include Files::.
682
 
683
`0x84     N_SOL'
684
     Name of include file; see *Note Include Files::.
685
 
686
`0xa0     N_PSYM'
687
     Parameter variable; see *Note Parameters::.
688
 
689
`0xa2     N_EINCL'
690
     End of an include file; see *Note Include Files::.
691
 
692
`0xa4     N_ENTRY'
693
     Alternate entry point; see *Note Alternate Entry Points::.
694
 
695
`0xc0     N_LBRAC'
696
     Beginning of a lexical block; see *Note Block Structure::.
697
 
698
`0xc2     N_EXCL'
699
     Place holder for a deleted include file; see *Note Include Files::.
700
 
701
`0xc4     N_SCOPE'
702
     Modula2 scope information (Sun linker); see *Note N_SCOPE::.
703
 
704
`0xe0     N_RBRAC'
705
     End of a lexical block; see *Note Block Structure::.
706
 
707
`0xe2     N_BCOMM'
708
     Begin named common block; see *Note Common Blocks::.
709
 
710
`0xe4     N_ECOMM'
711
     End named common block; see *Note Common Blocks::.
712
 
713
`0xe8     N_ECOML'
714
     Member of a common block; see *Note Common Blocks::.
715
 
716
`0xea N_WITH'
717
     Pascal `with' statement: type,,0,0,offset (Solaris2).
718
 
719
`0xf0     N_NBTEXT'
720
     Gould non-base registers; see *Note Gould::.
721
 
722
`0xf2     N_NBDATA'
723
     Gould non-base registers; see *Note Gould::.
724
 
725
`0xf4     N_NBBSS'
726
     Gould non-base registers; see *Note Gould::.
727
 
728
`0xf6     N_NBSTS'
729
     Gould non-base registers; see *Note Gould::.
730
 
731
`0xf8     N_NBLCS'
732
     Gould non-base registers; see *Note Gould::.
733
 
734

735
File: stabs.info,  Node: Symbol Descriptors,  Next: Type Descriptors,  Prev: Stab Types,  Up: Top
736
 
737
Table of Symbol Descriptors
738
***************************
739
 
740
   The symbol descriptor is the character which follows the colon in
741
many stabs, and which tells what kind of stab it is.  *Note String
742
Field::, for more information about their use.
743
 
744
`DIGIT'
745
`('
746
`-'
747
     Variable on the stack; see *Note Stack Variables::.
748
 
749
`:'
750
     C++ nested symbol; see *Note Nested Symbols::.
751
 
752
`a'
753
     Parameter passed by reference in register; see *Note Reference
754
     Parameters::.
755
 
756
`b'
757
     Based variable; see *Note Based Variables::.
758
 
759
`c'
760
     Constant; see *Note Constants::.
761
 
762
`C'
763
     Conformant array bound (Pascal, maybe other languages); *Note
764
     Conformant Arrays::.  Name of a caught exception (GNU C++).  These
765
     can be distinguished because the latter uses `N_CATCH' and the
766
     former uses another symbol type.
767
 
768
`d'
769
     Floating point register variable; see *Note Register Variables::.
770
 
771
`D'
772
     Parameter in floating point register; see *Note Register
773
     Parameters::.
774
 
775
`f'
776
     File scope function; see *Note Procedures::.
777
 
778
`F'
779
     Global function; see *Note Procedures::.
780
 
781
`G'
782
     Global variable; see *Note Global Variables::.
783
 
784
`i'
785
     *Note Register Parameters::.
786
 
787
`I'
788
     Internal (nested) procedure; see *Note Nested Procedures::.
789
 
790
`J'
791
     Internal (nested) function; see *Note Nested Procedures::.
792
 
793
`L'
794
     Label name (documented by AIX, no further information known).
795
 
796
`m'
797
     Module; see *Note Procedures::.
798
 
799
`p'
800
     Argument list parameter; see *Note Parameters::.
801
 
802
`pP'
803
     *Note Parameters::.
804
 
805
`pF'
806
     Fortran Function parameter; see *Note Parameters::.
807
 
808
`P'
809
     Unfortunately, three separate meanings have been independently
810
     invented for this symbol descriptor.  At least the GNU and Sun
811
     uses can be distinguished by the symbol type.  Global Procedure
812
     (AIX) (symbol type used unknown); see *Note Procedures::.
813
     Register parameter (GNU) (symbol type `N_PSYM'); see *Note
814
     Parameters::.  Prototype of function referenced by this file (Sun
815
     `acc') (symbol type `N_FUN').
816
 
817
`Q'
818
     Static Procedure; see *Note Procedures::.
819
 
820
`R'
821
     Register parameter; see *Note Register Parameters::.
822
 
823
`r'
824
     Register variable; see *Note Register Variables::.
825
 
826
`S'
827
     File scope variable; see *Note Statics::.
828
 
829
`s'
830
     Local variable (OS9000).
831
 
832
`t'
833
     Type name; see *Note Typedefs::.
834
 
835
`T'
836
     Enumeration, structure, or union tag; see *Note Typedefs::.
837
 
838
`v'
839
     Parameter passed by reference; see *Note Reference Parameters::.
840
 
841
`V'
842
     Procedure scope static variable; see *Note Statics::.
843
 
844
`x'
845
     Conformant array; see *Note Conformant Arrays::.
846
 
847
`X'
848
     Function return variable; see *Note Parameters::.
849
 
850

851
File: stabs.info,  Node: Type Descriptors,  Next: Expanded Reference,  Prev: Symbol Descriptors,  Up: Top
852
 
853
Table of Type Descriptors
854
*************************
855
 
856
   The type descriptor is the character which follows the type number
857
and an equals sign.  It specifies what kind of type is being defined.
858
*Note String Field::, for more information about their use.
859
 
860
`DIGIT'
861
`('
862
     Type reference; see *Note String Field::.
863
 
864
`-'
865
     Reference to builtin type; see *Note Negative Type Numbers::.
866
 
867
`#'
868
     Method (C++); see *Note Method Type Descriptor::.
869
 
870
`*'
871
     Pointer; see *Note Miscellaneous Types::.
872
 
873
`&'
874
     Reference (C++).
875
 
876
`@'
877
     Type Attributes (AIX); see *Note String Field::.  Member (class
878
     and variable) type (GNU C++); see *Note Member Type Descriptor::.
879
 
880
`a'
881
     Array; see *Note Arrays::.
882
 
883
`A'
884
     Open array; see *Note Arrays::.
885
 
886
`b'
887
     Pascal space type (AIX); see *Note Miscellaneous Types::.  Builtin
888
     integer type (Sun); see *Note Builtin Type Descriptors::.  Const
889
     and volatile qualified type (OS9000).
890
 
891
`B'
892
     Volatile-qualified type; see *Note Miscellaneous Types::.
893
 
894
`c'
895
     Complex builtin type (AIX); see *Note Builtin Type Descriptors::.
896
     Const-qualified type (OS9000).
897
 
898
`C'
899
     COBOL Picture type.  See AIX documentation for details.
900
 
901
`d'
902
     File type; see *Note Miscellaneous Types::.
903
 
904
`D'
905
     N-dimensional dynamic array; see *Note Arrays::.
906
 
907
`e'
908
     Enumeration type; see *Note Enumerations::.
909
 
910
`E'
911
     N-dimensional subarray; see *Note Arrays::.
912
 
913
`f'
914
     Function type; see *Note Function Types::.
915
 
916
`F'
917
     Pascal function parameter; see *Note Function Types::
918
 
919
`g'
920
     Builtin floating point type; see *Note Builtin Type Descriptors::.
921
 
922
`G'
923
     COBOL Group.  See AIX documentation for details.
924
 
925
`i'
926
     Imported type (AIX); see *Note Cross-References::.
927
     Volatile-qualified type (OS9000).
928
 
929
`k'
930
     Const-qualified type; see *Note Miscellaneous Types::.
931
 
932
`K'
933
     COBOL File Descriptor.  See AIX documentation for details.
934
 
935
`M'
936
     Multiple instance type; see *Note Miscellaneous Types::.
937
 
938
`n'
939
     String type; see *Note Strings::.
940
 
941
`N'
942
     Stringptr; see *Note Strings::.
943
 
944
`o'
945
     Opaque type; see *Note Typedefs::.
946
 
947
`p'
948
     Procedure; see *Note Function Types::.
949
 
950
`P'
951
     Packed array; see *Note Arrays::.
952
 
953
`r'
954
     Range type; see *Note Subranges::.
955
 
956
`R'
957
     Builtin floating type; see *Note Builtin Type Descriptors:: (Sun).
958
     Pascal subroutine parameter; see *Note Function Types:: (AIX).
959
     Detecting this conflict is possible with careful parsing (hint: a
960
     Pascal subroutine parameter type will always contain a comma, and
961
     a builtin type descriptor never will).
962
 
963
`s'
964
     Structure type; see *Note Structures::.
965
 
966
`S'
967
     Set type; see *Note Miscellaneous Types::.
968
 
969
`u'
970
     Union; see *Note Unions::.
971
 
972
`v'
973
     Variant record.  This is a Pascal and Modula-2 feature which is
974
     like a union within a struct in C.  See AIX documentation for
975
     details.
976
 
977
`w'
978
     Wide character; see *Note Builtin Type Descriptors::.
979
 
980
`x'
981
     Cross-reference; see *Note Cross-References::.
982
 
983
`Y'
984
     Used by IBM's xlC C++ compiler (for structures, I think).
985
 
986
`z'
987
     gstring; see *Note Strings::.
988
 
989

990
File: stabs.info,  Node: Expanded Reference,  Next: Questions,  Prev: Type Descriptors,  Up: Top
991
 
992
Expanded Reference by Stab Type
993
*******************************
994
 
995
   For a full list of stab types, and cross-references to where they are
996
described, see *Note Stab Types::.  This appendix just covers certain
997
stabs which are not yet described in the main body of this document;
998
eventually the information will all be in one place.
999
 
1000
   Format of an entry:
1001
 
1002
   The first line is the symbol type (see `include/aout/stab.def').
1003
 
1004
   The second line describes the language constructs the symbol type
1005
represents.
1006
 
1007
   The third line is the stab format with the significant stab fields
1008
named and the rest NIL.
1009
 
1010
   Subsequent lines expand upon the meaning and possible values for each
1011
significant stab field.
1012
 
1013
   Finally, any further information.
1014
 
1015
* Menu:
1016
 
1017
* N_PC::                        Pascal global symbol
1018
* N_NSYMS::                     Number of symbols
1019
* N_NOMAP::                     No DST map
1020
* N_M2C::                       Modula-2 compilation unit
1021
* N_BROWS::                     Path to .cb file for Sun source code browser
1022
* N_DEFD::                      GNU Modula2 definition module dependency
1023
* N_EHDECL::                    GNU C++ exception variable
1024
* N_MOD2::                      Modula2 information "for imc"
1025
* N_CATCH::                     GNU C++ "catch" clause
1026
* N_SSYM::                      Structure or union element
1027
* N_SCOPE::                     Modula2 scope information (Sun only)
1028
* Gould::                       non-base register symbols used on Gould systems
1029
* N_LENG::                      Length of preceding entry
1030
 
1031

1032
File: stabs.info,  Node: N_PC,  Next: N_NSYMS,  Up: Expanded Reference
1033
 
1034
N_PC
1035
====
1036
 
1037
 - `.stabs': N_PC
1038
     Global symbol (for Pascal).
1039
 
1040
          "name" -> "symbol_name"  <>
1041
          value  -> supposedly the line number (stab.def is skeptical)
1042
 
1043
          `stabdump.c' says:
1044
 
1045
          global pascal symbol: name,,0,subtype,line
1046
          << subtype? >>
1047
 
1048

1049
File: stabs.info,  Node: N_NSYMS,  Next: N_NOMAP,  Prev: N_PC,  Up: Expanded Reference
1050
 
1051
N_NSYMS
1052
=======
1053
 
1054
 - `.stabn': N_NSYMS
1055
     Number of symbols (according to Ultrix V4.0).
1056
 
1057
                  0, files,,funcs,lines (stab.def)
1058
 
1059

1060
File: stabs.info,  Node: N_NOMAP,  Next: N_M2C,  Prev: N_NSYMS,  Up: Expanded Reference
1061
 
1062
N_NOMAP
1063
=======
1064
 
1065
 - `.stabs': N_NOMAP
1066
     No DST map for symbol (according to Ultrix V4.0).  I think this
1067
     means a variable has been optimized out.
1068
 
1069
                  name, ,0,type,ignored (stab.def)
1070
 
1071

1072
File: stabs.info,  Node: N_M2C,  Next: N_BROWS,  Prev: N_NOMAP,  Up: Expanded Reference
1073
 
1074
N_M2C
1075
=====
1076
 
1077
 - `.stabs': N_M2C
1078
     Modula-2 compilation unit.
1079
 
1080
          "string" -> "unit_name,unit_time_stamp[,code_time_stamp]"
1081
          desc   -> unit_number
1082
          value  -> 0 (main unit)
1083
                    1 (any other unit)
1084
 
1085
     See `Dbx and Dbxtool Interfaces', 2nd edition, by Sun, 1988, for
1086
     more information.
1087
 
1088
 
1089

1090
File: stabs.info,  Node: N_BROWS,  Next: N_DEFD,  Prev: N_M2C,  Up: Expanded Reference
1091
 
1092
N_BROWS
1093
=======
1094
 
1095
 - `.stabs': N_BROWS
1096
     Sun source code browser, path to `.cb' file
1097
 
1098
     <> "path to associated `.cb' file"
1099
 
1100
     Note: N_BROWS has the same value as N_BSLINE.
1101
 
1102

1103
File: stabs.info,  Node: N_DEFD,  Next: N_EHDECL,  Prev: N_BROWS,  Up: Expanded Reference
1104
 
1105
N_DEFD
1106
======
1107
 
1108
 - `.stabn': N_DEFD
1109
     GNU Modula2 definition module dependency.
1110
 
1111
     GNU Modula-2 definition module dependency.  The value is the
1112
     modification time of the definition file.  The other field is
1113
     non-zero if it is imported with the GNU M2 keyword `%INITIALIZE'.
1114
     Perhaps `N_M2C' can be used if there are enough empty fields?
1115
 
1116

1117
File: stabs.info,  Node: N_EHDECL,  Next: N_MOD2,  Prev: N_DEFD,  Up: Expanded Reference
1118
 
1119
N_EHDECL
1120
========
1121
 
1122
 - `.stabs': N_EHDECL
1123
     GNU C++ exception variable <>.
1124
 
1125
     "STRING is variable name"
1126
 
1127
     Note: conflicts with `N_MOD2'.
1128
 
1129

1130
File: stabs.info,  Node: N_MOD2,  Next: N_CATCH,  Prev: N_EHDECL,  Up: Expanded Reference
1131
 
1132
N_MOD2
1133
======
1134
 
1135
 - `.stab?': N_MOD2
1136
     Modula2 info "for imc" (according to Ultrix V4.0)
1137
 
1138
     Note: conflicts with `N_EHDECL'  <>
1139
 
1140

1141
File: stabs.info,  Node: N_CATCH,  Next: N_SSYM,  Prev: N_MOD2,  Up: Expanded Reference
1142
 
1143
N_CATCH
1144
=======
1145
 
1146
 - `.stabn': N_CATCH
1147
     GNU C++ `catch' clause
1148
 
1149
     GNU C++ `catch' clause.  The value is its address.  The desc field
1150
     is nonzero if this entry is immediately followed by a `CAUGHT' stab
1151
     saying what exception was caught.  Multiple `CAUGHT' stabs means
1152
     that multiple exceptions can be caught here.  If desc is 0, it
1153
     means all exceptions are caught here.
1154
 
1155

1156
File: stabs.info,  Node: N_SSYM,  Next: N_SCOPE,  Prev: N_CATCH,  Up: Expanded Reference
1157
 
1158
N_SSYM
1159
======
1160
 
1161
 - `.stabn': N_SSYM
1162
     Structure or union element.
1163
 
1164
     The value is the offset in the structure.
1165
 
1166
     <>
1167
 
1168

1169
File: stabs.info,  Node: N_SCOPE,  Next: Gould,  Prev: N_SSYM,  Up: Expanded Reference
1170
 
1171
N_SCOPE
1172
=======
1173
 
1174
 - `.stab?': N_SCOPE
1175
     Modula2 scope information (Sun linker) <>
1176
 
1177

1178
File: stabs.info,  Node: Gould,  Next: N_LENG,  Prev: N_SCOPE,  Up: Expanded Reference
1179
 
1180
Non-base registers on Gould systems
1181
===================================
1182
 
1183
 - `.stab?': N_NBTEXT
1184
 - `.stab?': N_NBDATA
1185
 - `.stab?': N_NBBSS
1186
 - `.stab?': N_NBSTS
1187
 - `.stab?': N_NBLCS
1188
     These are used on Gould systems for non-base registers syms.
1189
 
1190
     However, the following values are not the values used by Gould;
1191
     they are the values which GNU has been documenting for these
1192
     values for a long time, without actually checking what Gould uses.
1193
     I include these values only because perhaps some someone actually
1194
     did something with the GNU information (I hope not, why GNU
1195
     knowingly assigned wrong values to these in the header file is a
1196
     complete mystery to me).
1197
 
1198
          240    0xf0     N_NBTEXT  ??
1199
          242    0xf2     N_NBDATA  ??
1200
          244    0xf4     N_NBBSS   ??
1201
          246    0xf6     N_NBSTS   ??
1202
          248    0xf8     N_NBLCS   ??
1203
 
1204

1205
File: stabs.info,  Node: N_LENG,  Prev: Gould,  Up: Expanded Reference
1206
 
1207
N_LENG
1208
======
1209
 
1210
 - `.stabn': N_LENG
1211
     Second symbol entry containing a length-value for the preceding
1212
     entry.  The value is the length.
1213
 
1214

1215
File: stabs.info,  Node: Questions,  Next: Stab Sections,  Prev: Expanded Reference,  Up: Top
1216
 
1217
Questions and Anomalies
1218
***********************
1219
 
1220
   * For GNU C stabs defining local and global variables (`N_LSYM' and
1221
     `N_GSYM'), the desc field is supposed to contain the source line
1222
     number on which the variable is defined.  In reality the desc
1223
     field is always 0.  (This behavior is defined in `dbxout.c' and
1224
     putting a line number in desc is controlled by `#ifdef
1225
     WINNING_GDB', which defaults to false). GDB supposedly uses this
1226
     information if you say `list VAR'.  In reality, VAR can be a
1227
     variable defined in the program and GDB says `function VAR not
1228
     defined'.
1229
 
1230
   * In GNU C stabs, there seems to be no way to differentiate tag
1231
     types: structures, unions, and enums (symbol descriptor `T') and
1232
     typedefs (symbol descriptor `t') defined at file scope from types
1233
     defined locally to a procedure or other more local scope.  They
1234
     all use the `N_LSYM' stab type.  Types defined at procedure scope
1235
     are emitted after the `N_RBRAC' of the preceding function and
1236
     before the code of the procedure in which they are defined.  This
1237
     is exactly the same as types defined in the source file between
1238
     the two procedure bodies.  GDB over-compensates by placing all
1239
     types in block #1, the block for symbols of file scope.  This is
1240
     true for default, `-ansi' and `-traditional' compiler options.
1241
     (Bugs gcc/1063, gdb/1066.)
1242
 
1243
   * What ends the procedure scope?  Is it the proc block's `N_RBRAC'
1244
     or the next `N_FUN'?  (I believe its the first.)
1245
 
1246

1247
File: stabs.info,  Node: Stab Sections,  Next: Symbol Types Index,  Prev: Questions,  Up: Top
1248
 
1249
Using Stabs in Their Own Sections
1250
*********************************
1251
 
1252
   Many object file formats allow tools to create object files with
1253
custom sections containing any arbitrary data.  For any such object file
1254
format, stabs can be embedded in special sections.  This is how stabs
1255
are used with ELF and SOM, and aside from ECOFF and XCOFF, is how stabs
1256
are used with COFF.
1257
 
1258
* Menu:
1259
 
1260
* Stab Section Basics::    How to embed stabs in sections
1261
* ELF Linker Relocation::  Sun ELF hacks
1262
 
1263

1264
File: stabs.info,  Node: Stab Section Basics,  Next: ELF Linker Relocation,  Up: Stab Sections
1265
 
1266
How to Embed Stabs in Sections
1267
==============================
1268
 
1269
   The assembler creates two custom sections, a section named `.stab'
1270
which contains an array of fixed length structures, one struct per stab,
1271
and a section named `.stabstr' containing all the variable length
1272
strings that are referenced by stabs in the `.stab' section.  The byte
1273
order of the stabs binary data depends on the object file format.  For
1274
ELF, it matches the byte order of the ELF file itself, as determined
1275
from the `EI_DATA' field in the `e_ident' member of the ELF header.
1276
For SOM, it is always big-endian (is this true??? FIXME).  For COFF, it
1277
matches the byte order of the COFF headers.  The meaning of the fields
1278
is the same as for a.out (*note Symbol Table Format::), except that the
1279
`n_strx' field is relative to the strings for the current compilation
1280
unit (which can be found using the synthetic N_UNDF stab described
1281
below), rather than the entire string table.
1282
 
1283
   The first stab in the `.stab' section for each compilation unit is
1284
synthetic, generated entirely by the assembler, with no corresponding
1285
`.stab' directive as input to the assembler.  This stab contains the
1286
following fields:
1287
 
1288
`n_strx'
1289
     Offset in the `.stabstr' section to the source filename.
1290
 
1291
`n_type'
1292
     `N_UNDF'.
1293
 
1294
`n_other'
1295
     Unused field, always zero.  This may eventually be used to hold
1296
     overflows from the count in the `n_desc' field.
1297
 
1298
`n_desc'
1299
     Count of upcoming symbols, i.e., the number of remaining stabs for
1300
     this source file.
1301
 
1302
`n_value'
1303
     Size of the string table fragment associated with this source
1304
     file, in bytes.
1305
 
1306
   The `.stabstr' section always starts with a null byte (so that string
1307
offsets of zero reference a null string), followed by random length
1308
strings, each of which is null byte terminated.
1309
 
1310
   The ELF section header for the `.stab' section has its `sh_link'
1311
member set to the section number of the `.stabstr' section, and the
1312
`.stabstr' section has its ELF section header `sh_type' member set to
1313
`SHT_STRTAB' to mark it as a string table.  SOM and COFF have no way of
1314
linking the sections together or marking them as string tables.
1315
 
1316
   For COFF, the `.stab' and `.stabstr' sections may be simply
1317
concatenated by the linker.  GDB then uses the `n_desc' fields to
1318
figure out the extent of the original sections.  Similarly, the
1319
`n_value' fields of the header symbols are added together in order to
1320
get the actual position of the strings in a desired `.stabstr' section.
1321
Although this design obviates any need for the linker to relocate or
1322
otherwise manipulate `.stab' and `.stabstr' sections, it also requires
1323
some care to ensure that the offsets are calculated correctly.  For
1324
instance, if the linker were to pad in between the `.stabstr' sections
1325
before concatenating, then the offsets to strings in the middle of the
1326
executable's `.stabstr' section would be wrong.
1327
 
1328
   The GNU linker is able to optimize stabs information by merging
1329
duplicate strings and removing duplicate header file information (*note
1330
Include Files::).  When some versions of the GNU linker optimize stabs
1331
in sections, they remove the leading `N_UNDF' symbol and arranges for
1332
all the `n_strx' fields to be relative to the start of the `.stabstr'
1333
section.
1334
 
1335

1336
File: stabs.info,  Node: ELF Linker Relocation,  Prev: Stab Section Basics,  Up: Stab Sections
1337
 
1338
Having the Linker Relocate Stabs in ELF
1339
=======================================
1340
 
1341
   This section describes some Sun hacks for Stabs in ELF; it does not
1342
apply to COFF or SOM.
1343
 
1344
   To keep linking fast, you don't want the linker to have to relocate
1345
very many stabs.  Making sure this is done for `N_SLINE', `N_RBRAC',
1346
and `N_LBRAC' stabs is the most important thing (see the descriptions
1347
of those stabs for more information).  But Sun's stabs in ELF has taken
1348
this further, to make all addresses in the `n_value' field (functions
1349
and static variables) relative to the source file.  For the `N_SO'
1350
symbol itself, Sun simply omits the address.  To find the address of
1351
each section corresponding to a given source file, the compiler puts
1352
out symbols giving the address of each section for a given source file.
1353
Since these are ELF (not stab) symbols, the linker relocates them
1354
correctly without having to touch the stabs section.  They are named
1355
`Bbss.bss' for the bss section, `Ddata.data' for the data section, and
1356
`Drodata.rodata' for the rodata section.  For the text section, there
1357
is no such symbol (but there should be, see below).  For an example of
1358
how these symbols work, *Note Stab Section Transformations::.  GCC does
1359
not provide these symbols; it instead relies on the stabs getting
1360
relocated.  Thus addresses which would normally be relative to
1361
`Bbss.bss', etc., are already relocated.  The Sun linker provided with
1362
Solaris 2.2 and earlier relocates stabs using normal ELF relocation
1363
information, as it would do for any section.  Sun has been threatening
1364
to kludge their linker to not do this (to speed up linking), even
1365
though the correct way to avoid having the linker do these relocations
1366
is to have the compiler no longer output relocatable values.  Last I
1367
heard they had been talked out of the linker kludge.  See Sun point
1368
patch 101052-01 and Sun bug 1142109.  With the Sun compiler this
1369
affects `S' symbol descriptor stabs (*note Statics::) and functions
1370
(*note Procedures::).  In the latter case, to adopt the clean solution
1371
(making the value of the stab relative to the start of the compilation
1372
unit), it would be necessary to invent a `Ttext.text' symbol, analogous
1373
to the `Bbss.bss', etc., symbols.  I recommend this rather than using a
1374
zero value and getting the address from the ELF symbols.
1375
 
1376
   Finding the correct `Bbss.bss', etc., symbol is difficult, because
1377
the linker simply concatenates the `.stab' sections from each `.o' file
1378
without including any information about which part of a `.stab' section
1379
comes from which `.o' file.  The way GDB does this is to look for an
1380
ELF `STT_FILE' symbol which has the same name as the last component of
1381
the file name from the `N_SO' symbol in the stabs (for example, if the
1382
file name is `../../gdb/main.c', it looks for an ELF `STT_FILE' symbol
1383
named `main.c').  This loses if different files have the same name
1384
(they could be in different directories, a library could have been
1385
copied from one system to another, etc.).  It would be much cleaner to
1386
have the `Bbss.bss' symbols in the stabs themselves.  Having the linker
1387
relocate them there is no more work than having the linker relocate ELF
1388
symbols, and it solves the problem of having to associate the ELF and
1389
stab symbols.  However, no one has yet designed or implemented such a
1390
scheme.
1391
 

powered by: WebSVN 2.1.0

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