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

Subversion Repositories or1k

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

powered by: WebSVN 2.1.0

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