154 lines
8.7 KiB
HTML
154 lines
8.7 KiB
HTML
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<title>String Field - STABS</title>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html">
|
||
|
|
<meta name="description" content="STABS">
|
||
|
|
<meta name="generator" content="makeinfo 4.13">
|
||
|
|
<link title="Top" rel="start" href="index.html#Top">
|
||
|
|
<link rel="up" href="Overview.html#Overview" title="Overview">
|
||
|
|
<link rel="prev" href="Stabs-Format.html#Stabs-Format" title="Stabs Format">
|
||
|
|
<link rel="next" href="C-Example.html#C-Example" title="C Example">
|
||
|
|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||
|
|
<!--
|
||
|
|
Copyright (C) 1992-2019 Free Software Foundation, Inc.
|
||
|
|
Contributed by Cygnus Support. Written by Julia Menapace, Jim Kingdon,
|
||
|
|
and David MacKenzie.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||
|
|
any later version published by the Free Software Foundation; with no
|
||
|
|
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||
|
|
Texts. A copy of the license is included in the section entitled ``GNU
|
||
|
|
Free Documentation License''.-->
|
||
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
||
|
|
<style type="text/css"><!--
|
||
|
|
pre.display { font-family:inherit }
|
||
|
|
pre.format { font-family:inherit }
|
||
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallexample { font-size:smaller }
|
||
|
|
pre.smalllisp { font-size:smaller }
|
||
|
|
span.sc { font-variant:small-caps }
|
||
|
|
span.roman { font-family:serif; font-weight:normal; }
|
||
|
|
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||
|
|
--></style>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<div class="node">
|
||
|
|
<a name="String-Field"></a>
|
||
|
|
<p>
|
||
|
|
Next: <a rel="next" accesskey="n" href="C-Example.html#C-Example">C Example</a>,
|
||
|
|
Previous: <a rel="previous" accesskey="p" href="Stabs-Format.html#Stabs-Format">Stabs Format</a>,
|
||
|
|
Up: <a rel="up" accesskey="u" href="Overview.html#Overview">Overview</a>
|
||
|
|
<hr>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h3 class="section">1.3 The String Field</h3>
|
||
|
|
|
||
|
|
<p>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.
|
||
|
|
|
||
|
|
<p>The overall format of the string field for most stab types is:
|
||
|
|
|
||
|
|
<pre class="example"> "<var>name</var>:<var>symbol-descriptor</var> <var>type-information</var>"
|
||
|
|
</pre>
|
||
|
|
<p><var>name</var> is the name of the symbol represented by the stab; it can
|
||
|
|
contain a pair of colons (see <a href="Nested-Symbols.html#Nested-Symbols">Nested Symbols</a>). <var>name</var> can be
|
||
|
|
omitted, which means the stab represents an unnamed object. For
|
||
|
|
example, ‘<samp><span class="samp">:t10=*2</span></samp>’ defines type 10 as a pointer to type 2, but does
|
||
|
|
not give the type a name. Omitting the <var>name</var> 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.
|
||
|
|
|
||
|
|
<p>The <var>symbol-descriptor</var> following the ‘<samp><span class="samp">:</span></samp>’ is an alphabetic
|
||
|
|
character that tells more specifically what kind of symbol the stab
|
||
|
|
represents. If the <var>symbol-descriptor</var> is omitted, but type
|
||
|
|
information follows, then the stab represents a local variable. For a
|
||
|
|
list of symbol descriptors, see <a href="Symbol-Descriptors.html#Symbol-Descriptors">Symbol Descriptors</a>. The ‘<samp><span class="samp">c</span></samp>’
|
||
|
|
symbol descriptor is an exception in that it is not followed by type
|
||
|
|
information. See <a href="Constants.html#Constants">Constants</a>.
|
||
|
|
|
||
|
|
<p><var>type-information</var> is either a <var>type-number</var>, or
|
||
|
|
‘<samp><var>type-number</var><span class="samp">=</span></samp>’. A <var>type-number</var> alone is a type
|
||
|
|
reference, referring directly to a type that has already been defined.
|
||
|
|
|
||
|
|
<p>The ‘<samp><var>type-number</var><span class="samp">=</span></samp>’ 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 ‘<samp><span class="samp">=</span></samp>’ and nested definitions. Also, the Lucid
|
||
|
|
compiler will repeat ‘<samp><var>type-number</var><span class="samp">=</span></samp>’ more than once if it
|
||
|
|
wants to define several type numbers at once.
|
||
|
|
|
||
|
|
<p>In a type definition, if the character that follows the equals sign is
|
||
|
|
non-numeric then it is a <var>type-descriptor</var>, and tells what kind of
|
||
|
|
type is about to be defined. Any other values following the
|
||
|
|
<var>type-descriptor</var> vary, depending on the <var>type-descriptor</var>.
|
||
|
|
See <a href="Type-Descriptors.html#Type-Descriptors">Type Descriptors</a>, for a list of <var>type-descriptor</var> values. If
|
||
|
|
a number follows the ‘<samp><span class="samp">=</span></samp>’ then the number is a <var>type-reference</var>.
|
||
|
|
For a full description of types, <a href="Types.html#Types">Types</a>.
|
||
|
|
|
||
|
|
<p>A <var>type-number</var> is often a single number. The GNU and Sun tools
|
||
|
|
additionally permit a <var>type-number</var> to be a pair
|
||
|
|
(<var>file-number</var>,<var>filetype-number</var>) (the parentheses appear in the
|
||
|
|
string, and serve to distinguish the two cases). The <var>file-number</var>
|
||
|
|
is 0 for the base source file, 1 for the first included file, 2 for the
|
||
|
|
next, and so on. The <var>filetype-number</var> 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
|
||
|
|
<code>N_BINCL</code> optimization to succeed more often; see <a href="Include-Files.html#Include-Files">Include Files</a>).
|
||
|
|
|
||
|
|
<p>There is an AIX extension for type attributes. Following the ‘<samp><span class="samp">=</span></samp>’
|
||
|
|
are any number of type attributes. Each one starts with ‘<samp><span class="samp">@</span></samp>’ and
|
||
|
|
ends with ‘<samp><span class="samp">;</span></samp>’. 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<tt>++</tt>
|
||
|
|
(see <a href="Cplusplus.html#Cplusplus">Cplusplus</a>), new attributes should not be defined which begin
|
||
|
|
with a digit, ‘<samp><span class="samp">(</span></samp>’, or ‘<samp><span class="samp">-</span></samp>’; GDB may be unable to distinguish
|
||
|
|
those from the C<tt>++</tt> type descriptor ‘<samp><span class="samp">@</span></samp>’. The attributes are:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><code>a</code><var>boundary</var><dd><var>boundary</var> is an integer specifying the alignment. I assume it
|
||
|
|
applies to all variables of this type.
|
||
|
|
|
||
|
|
<br><dt><code>p</code><var>integer</var><dd>Pointer class (for checking). Not sure what this means, or how
|
||
|
|
<var>integer</var> is interpreted.
|
||
|
|
|
||
|
|
<br><dt><code>P</code><dd>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.
|
||
|
|
|
||
|
|
<br><dt><code>s</code><var>size</var><dd>Size in bits of a variable of this type. This is fully supported by GDB
|
||
|
|
4.11 and later.
|
||
|
|
|
||
|
|
<br><dt><code>S</code><dd>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.
|
||
|
|
|
||
|
|
<br><dt><code>V</code><dd>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).
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p>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 <code>.stabs</code> directive
|
||
|
|
into several <code>.stabs</code> 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 ‘<samp><span class="samp">?</span></samp>’ instead of backslash.
|
||
|
|
|
||
|
|
</body></html>
|
||
|
|
|