1.3 The String Field

For most stabs the string field holds the meat of the debugging information. The flexible nature of this field is what makes stabs extensible. For some stab types the string field contains only a name. For other stab types the contents can be a great deal more complex.

The overall format of the string field for most stab types is:

     "name:symbol-descriptor type-information"

name is the name of the symbol represented by the stab; it can contain a pair of colons (see Nested Symbols). name can be omitted, which means the stab represents an unnamed object. For example, ‘:t10=*2’ defines type 10 as a pointer to type 2, but does not give the type a name. Omitting the name field is supported by AIX dbx and GDB after about version 4.8, but not other debuggers. GCC sometimes uses a single space as the name instead of omitting the name altogether; apparently that is supported by most debuggers.

The symbol-descriptor following the ‘:’ is an alphabetic character that tells more specifically what kind of symbol the stab represents. If the symbol-descriptor is omitted, but type information follows, then the stab represents a local variable. For a list of symbol descriptors, see Symbol Descriptors. The ‘c’ symbol descriptor is an exception in that it is not followed by type information. See Constants.

type-information is either a type-number, or ‘type-number=’. A type-number alone is a type reference, referring directly to a type that has already been defined.

The ‘type-number=’ form is a type definition, where the number represents a new type which is about to be defined. The type definition may refer to other types by number, and those type numbers may be followed by ‘=’ and nested definitions. Also, the Lucid compiler will repeat ‘type-number=’ more than once if it wants to define several type numbers at once.

In a type definition, if the character that follows the equals sign is non-numeric then it is a type-descriptor, and tells what kind of type is about to be defined. Any other values following the type-descriptor vary, depending on the type-descriptor. See Type Descriptors, for a list of type-descriptor values. If a number follows the ‘=’ then the number is a type-reference. For a full description of types, Types.

A type-number is often a single number. The GNU and Sun tools additionally permit a type-number to be a pair (file-number,filetype-number) (the parentheses appear in the string, and serve to distinguish the two cases). The file-number is 0 for the base source file, 1 for the first included file, 2 for the next, and so on. The filetype-number is a number starting with 1 which is incremented for each new type defined in the file. (Separating the file number and the type number permits the N_BINCL optimization to succeed more often; see Include Files).

There is an AIX extension for type attributes. Following the ‘=’ are any number of type attributes. Each one starts with ‘@’ and ends with ‘;’. Debuggers, including AIX's dbx and GDB 4.10, skip any type attributes they do not recognize. GDB 4.9 and other versions of dbx may not do this. Because of a conflict with C++ (see Cplusplus), new attributes should not be defined which begin with a digit, ‘(’, or ‘-’; GDB may be unable to distinguish those from the C++ type descriptor ‘@’. The attributes are:

aboundary

boundary is an integer specifying the alignment. I assume it applies to all variables of this type.

pinteger

Pointer class (for checking). Not sure what this means, or how integer is interpreted.

P

Indicate this is a packed type, meaning that structure fields or array elements are placed more closely in memory, to save memory at the expense of speed.

ssize

Size in bits of a variable of this type. This is fully supported by GDB 4.11 and later.

S

Indicate that this type is a string instead of an array of characters, or a bitstring instead of a set. It doesn't change the layout of the data being represented, but does enable the debugger to know which type it is.

V

Indicate that this type is a vector instead of an array. The only major difference between vectors and arrays is that vectors are passed by value instead of by reference (vector coprocessor extension).

All of this can make the string field quite long. All versions of GDB, and some versions of dbx, can handle arbitrarily long strings. But many versions of dbx (or assemblers or linkers, I'm not sure which) cretinously limit the strings to about 80 characters, so compilers which must work with such systems need to split the .stabs directive into several .stabs directives. Each stab duplicates every field except the string field. The string field of every stab except the last is marked as continued with a backslash at the end (in the assembly code this may be written as a double backslash, depending on the assembler). Removing the backslashes and concatenating the string fields of each stab produces the original, long string. Just to be incompatible (or so they don't have to worry about what the assembler does with backslashes), AIX can use ‘?’ instead of backslash.