mingw/info/stabs/Procedures.html

   1 <html lang="en">
   2 <head>
   3 <title>STABS</title>
   4 <meta http-equiv="Content-Type" content="text/html">
   5 <meta name="description" content="STABS">
   6 <meta name="generator" content="makeinfo 4.3">
   7 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
   8 </head>
   9 <body>
  10 <div class="node">
  11 <p>
  12 Node:<a name="Procedures">Procedures</a>,
  13 Next:<a rel="next" accesskey="n" href="Nested-Procedures.html#Nested%20Procedures">Nested Procedures</a>,
  14 Previous:<a rel="previous" accesskey="p" href="Line-Numbers.html#Line%20Numbers">Line Numbers</a>,
  15 Up:<a rel="up" accesskey="u" href="Program-Structure.html#Program%20Structure">Program Structure</a>
  16 <hr><br>
  17 </div>
  18
  19 <h3 class="section">Procedures</h3>
  20
  21    <p>All of the following stabs normally use the <code>N_FUN</code> symbol type.
  22 However, Sun's <code>acc</code> compiler on SunOS4 uses <code>N_GSYM</code> and
  23 <code>N_STSYM</code>, which means that the value of the stab for the function
  24 is useless and the debugger must get the address of the function from
  25 the non-stab symbols instead.  On systems where non-stab symbols have
  26 leading underscores, the stabs will lack underscores and the debugger
  27 needs to know about the leading underscore to match up the stab and the
  28 non-stab symbol.  BSD Fortran is said to use <code>N_FNAME</code> with the
  29 same restriction; the value of the symbol is not useful (I'm not sure it
  30 really does use this, because GDB doesn't handle this and no one has
  31 complained).
  32
  33    <p>A function is represented by an <code>F</code> symbol descriptor for a global
  34 (extern) function, and <code>f</code> for a static (local) function.  For
  35 a.out, the value of the symbol is the address of the start of the
  36 function; it is already relocated.  For stabs in ELF, the SunPRO
  37 compiler version 2.0.1 and GCC put out an address which gets relocated
  38 by the linker.  In a future release SunPRO is planning to put out zero,
  39 in which case the address can be found from the ELF (non-stab) symbol.
  40 Because looking things up in the ELF symbols would probably be slow, I'm
  41 not sure how to find which symbol of that name is the right one, and
  42 this doesn't provide any way to deal with nested functions, it would
  43 probably be better to make the value of the stab an address relative to
  44 the start of the file, or just absolute.  See <a href="ELF-Linker-Relocation.html#ELF%20Linker%20Relocation">ELF Linker Relocation</a> for more information on linker relocation of stabs in ELF
  45 files.  For XCOFF, the stab uses the <code>C_FUN</code> storage class and the
  46 value of the stab is meaningless; the address of the function can be
  47 found from the csect symbol (XTY_LD/XMC_PR).
  48
  49    <p>The type information of the stab represents the return type of the
  50 function; thus <code>foo:f5</code> means that foo is a function returning type
  51 5.  There is no need to try to get the line number of the start of the
  52 function from the stab for the function; it is in the next
  53 <code>N_SLINE</code> symbol.
  54
  55    <p>Some compilers (such as Sun's Solaris compiler) support an extension for
  56 specifying the types of the arguments.  I suspect this extension is not
  57 used for old (non-prototyped) function definitions in C.  If the
  58 extension is in use, the type information of the stab for the function
  59 is followed by type information for each argument, with each argument
  60 preceded by <code>;</code>.  An argument type of 0 means that additional
  61 arguments are being passed, whose types and number may vary (<code>...</code>
  62 in ANSI C).  GDB has tolerated this extension (parsed the syntax, if not
  63 necessarily used the information) since at least version 4.8; I don't
  64 know whether all versions of dbx tolerate it.  The argument types given
  65 here are not redundant with the symbols for the formal parameters
  66 (see <a href="Parameters.html#Parameters">Parameters</a>); they are the types of the arguments as they are
  67 passed, before any conversions might take place.  For example, if a C
  68 function which is declared without a prototype takes a <code>float</code>
  69 argument, the value is passed as a <code>double</code> but then converted to a
  70 <code>float</code>.  Debuggers need to use the types given in the arguments
  71 when printing values, but when calling the function they need to use the
  72 types given in the symbol defining the function.
  73
  74    <p>If the return type and types of arguments of a function which is defined
  75 in another source file are specified (i.e., a function prototype in ANSI
  76 C), traditionally compilers emit no stab; the only way for the debugger
  77 to find the information is if the source file where the function is
  78 defined was also compiled with debugging symbols.  As an extension the
  79 Solaris compiler uses symbol descriptor <code>P</code> followed by the return
  80 type of the function, followed by the arguments, each preceded by
  81 <code>;</code>, as in a stab with symbol descriptor <code>f</code> or <code>F</code>.
  82 This use of symbol descriptor <code>P</code> can be distinguished from its use
  83 for register parameters (see <a href="Register-Parameters.html#Register%20Parameters">Register Parameters</a>) by the fact that it has
  84 symbol type <code>N_FUN</code>.
  85
  86    <p>The AIX documentation also defines symbol descriptor <code>J</code> as an
  87 internal function.  I assume this means a function nested within another
  88 function.  It also says symbol descriptor <code>m</code> is a module in
  89 Modula-2 or extended Pascal.
  90
  91    <p>Procedures (functions which do not return values) are represented as
  92 functions returning the <code>void</code> type in C.  I don't see why this couldn't
  93 be used for all languages (inventing a <code>void</code> type for this purpose if
  94 necessary), but the AIX documentation defines <code>I</code>, <code>P</code>, and
  95 <code>Q</code> for internal, global, and static procedures, respectively.
  96 These symbol descriptors are unusual in that they are not followed by
  97 type information.
  98
  99    <p>The following example shows a stab for a function <code>main</code> which
 100 returns type number <code>1</code>.  The <code>_main</code> specified for the value
 101 is a reference to an assembler label which is used to fill in the start
 102 address of the function.
 103
 104 <pre class="example">     .stabs "main:F1",36,0,0,_main      # 36 is N_FUN
 105      </pre>
 106
 107    <p>The stab representing a procedure is located immediately following the
 108 code of the procedure.  This stab is in turn directly followed by a
 109 group of other stabs describing elements of the procedure.  These other
 110 stabs describe the procedure's parameters, its block local variables, and
 111 its block structure.
 112
 113    <p>If functions can appear in different sections, then the debugger may not
 114 be able to find the end of a function.  Recent versions of GCC will mark
 115 the end of a function with an <code>N_FUN</code> symbol with an empty string
 116 for the name.  The value is the address of the end of the current
 117 function.  Without such a symbol, there is no indication of the address
 118 of the end of a function, and you must assume that it ended at the
 119 starting address of the next function or at the end of the text section
 120 for the program.
 121
 122    </body></html>
 123