Format of an entry: The first line is the symbol type expressed in decimal, hexadecimal, and as a #define (see devo/include/aout/stab.def).
The second line describes the language constructs the symbol type represents.
The third line is the stab format with the significant stab fields named and the rest NIL.
Subsequent lines expand upon the meaning and possible values for each significant stab field. # stands in for the type descriptor.
Finally, any further information.
Global variable. .stabs "name", N_GSYM, NIL, NIL, NIL
"name" -> "symbol_name:#type"
# -> G
Only the "name" field is significant. the location of the variable is obtained from the corresponding external symbol.
Function name (for BSD Fortran)
.stabs "name", N_FNAME, NIL, NIL, NIL
"name" -> "function_name"
Only the "name" field is significant. The location of the symbol is obtained from the corresponding extern symbol.
Function name or text segment variable for C.
.stabs "name", N_FUN, NIL, desc, value
For functions:
"name" -> "proc_name:#return_type"
# -> F (global function)
f (local function)
desc -> line num for proc start. (GCC doesn't set and DBX doesn't miss it.)
value -> Code address of proc start.
For text segment variables:
<<How to create one?>>
Initialized static symbol (data segment w/internal linkage).
.stabs "name", N_STSYM, NIL, NIL, value
"name" -> "symbol_name#type"
# -> S (scope global to compilation unit)
-> V (scope local to a procedure)
value -> Data Address
Unitialized static (.lcomm) symbol(BSS segment w/internal linkage).
.stabs "name", N_LCLSYM, NIL, NIL, value
"name" -> "symbol_name#type"
# -> S (scope global to compilation unit)
-> V (scope local to procedure)
value -> BSS Address
Name of main routine (not used in C)
.stabs "name", N_MAIN, NIL, NIL, NIL
"name" -> "name_of_main_routine"
Global symbol (for Pascal)
.stabs "name", N_PC, NIL, NIL, value
"name" -> "symbol_name" <<?>> value -> supposedly the line number (stab.def is skeptical)
stabdump.c says: global pascal symbol: name,,0,subtype,line << subtype? >>
Number of symbols (according to Ultrix V4.0)
0, files,,funcs,lines (stab.def)
no DST map for sym (according to Ultrix V4.0)
name, ,0,type,ignored (stab.def)
register variable
.stabs "name:type",N_RSYM,0,RegSize,RegNumber (Sun doc)
Modula-2 compilation unit
.stabs "name", N_M2C, 0, desc, value
"name" -> "unit_name,unit_time_stamp[,code_time_stamp]
desc -> unit_number
value -> 0 (main unit)
1 (any other unit)
Line number in text segment
.stabn N_SLINE, 0, desc, value
desc -> line_number value -> code_address (relocatable addr where the corresponding code starts)
For single source lines that generate discontiguous code, such as flow of control statements, there may be more than one N_SLINE stab for the same source line. In this case there is a stab at the start of each code range, each with the same line number.
Line number in data segment
.stabn N_DSLINE, 0, desc, value
desc -> line_number value -> data_address (relocatable addr where the corresponding code starts)
See comment for N_SLINE above.
Line number in bss segment
.stabn N_BSLINE, 0, desc, value
desc -> line_number value -> bss_address (relocatable addr where the corresponding code starts)
See comment for N_SLINE above.
Sun source code browser, path to .cb file
<<?>> "path to associated .cb file"
Note: type field value overlaps with N_BSLINE
GNU Modula2 definition module dependency
GNU Modula-2 definition module dependency. Value is the modification time of the definition file. Other is non-zero if it is imported with the GNU M2 keyword %INITIALIZE. Perhaps N_M2C can be used if there are enough empty fields?
GNU C++ exception variable <<?>>
"name is variable name"
Note: conflicts with N_MOD2.
Modula2 info "for imc" (according to Ultrix V4.0)
Note: conflicts with N_EHDECL <<?>>
GNU C++ "catch" clause
GNU C++ `catch' clause. Value is its address. Desc is nonzero if this entry is immediately followed by a CAUGHT stab saying what exception was caught. Multiple CAUGHT stabs means that multiple exceptions can be caught here. If Desc is 0, it means all exceptions are caught here.
Structure or union element
Value is offset in the structure.
<<?looking at structs and unions in C I didn't see these>>
Path and name of source file containing main routine
.stabs "name", N_SO, NIL, NIL, value
"name" -> /path/to/source/file
-> source_file_terminal_name
value -> the starting text address of the compilation.
These are found two in a row. The name field of the first N_SO contains the path to the source file. The name field of the second N_SO contains the terminal name of the source file itself.
Automatic var in the stack (also used for type descriptors.)
.stabs "name" N_LSYM, NIL, NIL, value
For stack based local variables:
"name" -> name of the variable
value -> offset from frame pointer (negative)
For type descriptors:
"name" -> "name_of_the_type:#type"
# -> t
type -> type_ref (or) type_def
type_ref -> type_number
type_def -> type_number=type_desc etc.
Type may be either a type reference or a type definition. A type reference is a number that refers to a previously defined type. A type definition is the number that will refer to this type, followed by an equals sign, a type descriptor and the additional data that defines the type. See the Table D for type descriptors and the section on types for what data follows each type descriptor.
Beginning of an include file (Sun only)
Beginning of an include file. Only Sun uses this. In an object file, only the name is significant. The Sun linker puts data into some of the other fields.
Name of a sub-source file (#include file). Value is starting address of the compilation. <<?>>
Parameter variable
stabs. "name", N_PSYM, NIL, NIL, value
"name" -> "param_name:#type"
# -> p (value parameter)
-> i (value parameter by reference, indirect access)
-> v (variable parameter by reference)
-> C ( read-only parameter, conformant array bound)
-> x (confomant array value parameter)
-> pP (<<??>>)
-> pF (<<??>>)
-> X (function result variable)
-> b (based variable)
value -> offset from the argument pointer (positive).
On most machines the argument pointer is the same as the frame pointer.
End of an include file. This and N_BINCL act as brackets around the file's output. In an ojbect file, there is no significant data in this entry. The Sun linker puts data into some of the fields. <<?>>
Alternate entry point. Value is its address. <<?>>
Beginning of a lexical block (left brace). The variable defined inside the block precede the N_LBRAC symbol. Or can they follow as well as long as a new N_FUNC was not encountered. <<?>>
.stabn N_LBRAC, NIL, NIL, value
value -> code address of block start.
Place holder for a deleted include file. Replaces a N_BINCL and everything up to the corresponding N_EINCL. The Sun linker generates these when it finds multiple indentical copies of the symbols from an included file. This appears only in output from the Sun linker. <<?>>
Modula2 scope information (Sun linker) <<?>>
End of a lexical block (right brace)
.stabn N_RBRAC, NIL, NIL, value
value -> code address of the end of the block.
Begin named common block.
Only the name is significant. <<?>>
End named common block.
Only the name is significant and it should match the N_BCOMM <<?>>
End common (local name)
value is address. <<?>>
<< used on Gould systems for non-base registers syms, values assigned at random, need real info from Gould. >> <<?>>
240 0xf0 N_NBTEXT ?? 242 0xf2 N_NBDATA ?? 244 0xf4 N_NBBSS ?? 246 0xf6 N_NBSTS ?? 248 0xf8 N_NBLCS ??
Second symbol entry containing a length-value for the preceding entry. The value is the length.