5.1.3 Negative Type Numbers

This is the method used in XCOFF for defining builtin types. Since the debugger knows about the builtin types anyway, the idea of negative type numbers is simply to give a special type number which indicates the builtin type. There is no stab defining these types.

There are several subtle issues with negative type numbers.

One is the size of the type. A builtin type (for example the C types int or long) might have different sizes depending on compiler options, the target architecture, the ABI, etc. This issue doesn’t come up for IBM tools since (so far) they just target the RS/6000; the sizes indicated below for each size are what the IBM RS/6000 tools use. To deal with differing sizes, either define separate negative type numbers for each size (which works but requires changing the debugger, and, unless you get both AIX dbx and GDB to accept the change, introduces an incompatibility), or use a type attribute (see The String Field) to define a new type with the appropriate size (which merely requires a debugger which understands type attributes, like AIX dbx or GDB). For example,

.stabs "boolean:t10=@s8;-16",128,0,0,0

defines an 8-bit boolean type, and

.stabs "boolean:t10=@s64;-16",128,0,0,0

defines a 64-bit boolean type.

A similar issue is the format of the type. This comes up most often for floating-point types, which could have various formats (particularly extended doubles, which vary quite a bit even among IEEE systems). Again, it is best to define a new negative type number for each different format; changing the format based on the target system has various problems. One such problem is that the Alpha has both VAX and IEEE floating types. One can easily imagine one library using the VAX types and another library in the same executable using the IEEE types. Another example is that the interpretation of whether a boolean is true or false can be based on the least significant bit, most significant bit, whether it is zero, etc., and different compilers (or different options to the same compiler) might provide different kinds of boolean.

The last major issue is the names of the types. The name of a given type depends only on the negative type number given; these do not vary depending on the language, the target system, or anything else. One can always define separate type numbers—in the following list you will see for example separate int and integer*4 types which are identical except for the name. But compatibility can be maintained by not inventing new negative type numbers and instead just defining a new type with a new name. For example:

.stabs "CARDINAL:t10=-8",128,0,0,0

Here is the list of negative type numbers. The phrase integral type is used to mean twos-complement (I strongly suspect that all machines which use stabs use twos-complement; most machines use twos-complement these days).

-1

int, 32 bit signed integral type.

-2

char, 8 bit type holding a character. Both GDB and dbx on AIX treat this as signed. GCC uses this type whether char is signed or not, which seems like a bad idea. The AIX compiler (xlc) seems to avoid this type; it uses -5 instead for char.

-3

short, 16 bit signed integral type.

-4

long, 32 bit signed integral type.

-5

unsigned char, 8 bit unsigned integral type.

-6

signed char, 8 bit signed integral type.

-7

unsigned short, 16 bit unsigned integral type.

-8

unsigned int, 32 bit unsigned integral type.

-9

unsigned, 32 bit unsigned integral type.

-10

unsigned long, 32 bit unsigned integral type.

-11

void, type indicating the lack of a value.

-12

float, IEEE single precision.

-13

double, IEEE double precision.

-14

long double, IEEE double precision. The compiler claims the size will increase in a future release, and for binary compatibility you have to avoid using long double. I hope when they increase it they use a new negative type number.

-15

integer. 32 bit signed integral type.

-16

boolean. 32 bit type. GDB and GCC assume that zero is false, one is true, and other values have unspecified meaning. I hope this agrees with how the IBM tools use the type.

-17

short real. IEEE single precision.

-18

real. IEEE double precision.

-19

stringptr. See Strings.

-20

character, 8 bit unsigned character type.

-21

logical*1, 8 bit type. This Fortran type has a split personality in that it is used for boolean variables, but can also be used for unsigned integers. 0 is false, 1 is true, and other values are non-boolean.

-22

logical*2, 16 bit type. This Fortran type has a split personality in that it is used for boolean variables, but can also be used for unsigned integers. 0 is false, 1 is true, and other values are non-boolean.

-23

logical*4, 32 bit type. This Fortran type has a split personality in that it is used for boolean variables, but can also be used for unsigned integers. 0 is false, 1 is true, and other values are non-boolean.

-24

logical, 32 bit type. This Fortran type has a split personality in that it is used for boolean variables, but can also be used for unsigned integers. 0 is false, 1 is true, and other values are non-boolean.

-25

complex. A complex type consisting of two IEEE single-precision floating point values.

-26

complex. A complex type consisting of two IEEE double-precision floating point values.

-27

integer*1, 8 bit signed integral type.

-28

integer*2, 16 bit signed integral type.

-29

integer*4, 32 bit signed integral type.

-30

wchar. Wide character, 16 bits wide, unsigned (what format? Unicode?).

-31

long long, 64 bit signed integral type.

-32

unsigned long long, 64 bit unsigned integral type.

-33

logical*8, 64 bit unsigned integral type.

-34

integer*8, 64 bit signed integral type.