2.5 Procedures

All of the following stabs normally use the N_FUN symbol type. However, Sun’s acc compiler on SunOS4 uses N_GSYM and N_STSYM, which means that the value of the stab for the function is useless and the debugger must get the address of the function from the non-stab symbols instead. On systems where non-stab symbols have leading underscores, the stabs will lack underscores and the debugger needs to know about the leading underscore to match up the stab and the non-stab symbol. BSD Fortran is said to use N_FNAME with the same restriction; the value of the symbol is not useful (I’m not sure it really does use this, because GDB doesn’t handle this and no one has complained).

A function is represented by an ‘F’ symbol descriptor for a global (extern) function, and ‘f’ for a static (local) function. For a.out, the value of the symbol is the address of the start of the function; it is already relocated. For stabs in ELF, the SunPRO compiler version 2.0.1 and GCC put out an address which gets relocated by the linker. In a future release SunPRO is planning to put out zero, in which case the address can be found from the ELF (non-stab) symbol. Because looking things up in the ELF symbols would probably be slow, I’m not sure how to find which symbol of that name is the right one, and this doesn’t provide any way to deal with nested functions, it would probably be better to make the value of the stab an address relative to the start of the file, or just absolute. See Having the Linker Relocate Stabs in ELF for more information on linker relocation of stabs in ELF files. For XCOFF, the stab uses the C_FUN storage class and the value of the stab is meaningless; the address of the function can be found from the csect symbol (XTY_LD/XMC_PR).

The type information of the stab represents the return type of the function; thus ‘foo:f5’ means that foo is a function returning type 5. There is no need to try to get the line number of the start of the function from the stab for the function; it is in the next N_SLINE symbol.

Some compilers (such as Sun’s Solaris compiler) support an extension for specifying the types of the arguments. I suspect this extension is not used for old (non-prototyped) function definitions in C. If the extension is in use, the type information of the stab for the function is followed by type information for each argument, with each argument preceded by ‘;’. An argument type of 0 means that additional arguments are being passed, whose types and number may vary (‘...’ in ANSI C). GDB has tolerated this extension (parsed the syntax, if not necessarily used the information) since at least version 4.8; I don’t know whether all versions of dbx tolerate it. The argument types given here are not redundant with the symbols for the formal parameters (see Parameters); they are the types of the arguments as they are passed, before any conversions might take place. For example, if a C function which is declared without a prototype takes a float argument, the value is passed as a double but then converted to a float. Debuggers need to use the types given in the arguments when printing values, but when calling the function they need to use the types given in the symbol defining the function.

If the return type and types of arguments of a function which is defined in another source file are specified (i.e., a function prototype in ANSI C), traditionally compilers emit no stab; the only way for the debugger to find the information is if the source file where the function is defined was also compiled with debugging symbols. As an extension the Solaris compiler uses symbol descriptor ‘P’ followed by the return type of the function, followed by the arguments, each preceded by ‘;’, as in a stab with symbol descriptor ‘f’ or ‘F’. This use of symbol descriptor ‘P’ can be distinguished from its use for register parameters (see Passing Parameters in Registers) by the fact that it has symbol type N_FUN.

The AIX documentation also defines symbol descriptor ‘J’ as an internal function. I assume this means a function nested within another function. It also says symbol descriptor ‘m’ is a module in Modula-2 or extended Pascal.

Procedures (functions which do not return values) are represented as functions returning the void type in C. I don’t see why this couldn’t be used for all languages (inventing a void type for this purpose if necessary), but the AIX documentation defines ‘I’, ‘P’, and ‘Q’ for internal, global, and static procedures, respectively. These symbol descriptors are unusual in that they are not followed by type information.

The following example shows a stab for a function main which returns type number 1. The _main specified for the value is a reference to an assembler label which is used to fill in the start address of the function.

.stabs "main:F1",36,0,0,_main      # 36 is N_FUN

The stab representing a procedure is located immediately following the code of the procedure. This stab is in turn directly followed by a group of other stabs describing elements of the procedure. These other stabs describe the procedure’s parameters, its block local variables, and its block structure.

If functions can appear in different sections, then the debugger may not be able to find the end of a function. Recent versions of GCC will mark the end of a function with an N_FUN symbol with an empty string for the name. The value is the address of the end of the current function. Without such a symbol, there is no indication of the address of the end of a function, and you must assume that it ended at the starting address of the next function or at the end of the text section for the program.