mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 22:48:57 +08:00
* stabs.texinfo: Many minor cleanups.
* stabs.texinfo: Remove @deffn except from Expanded Reference node.
This commit is contained in:
@ -1,3 +1,9 @@
|
|||||||
|
Mon Aug 30 11:13:16 1993 Jim Kingdon (kingdon@lioth.cygnus.com)
|
||||||
|
|
||||||
|
* stabs.texinfo: Many minor cleanups.
|
||||||
|
|
||||||
|
* stabs.texinfo: Remove @deffn except from Expanded Reference node.
|
||||||
|
|
||||||
Sat Aug 28 12:08:09 1993 David J. MacKenzie (djm@edison.eng.umd.edu)
|
Sat Aug 28 12:08:09 1993 David J. MacKenzie (djm@edison.eng.umd.edu)
|
||||||
|
|
||||||
* stabs.texinfo: Remove full description of big example.
|
* stabs.texinfo: Remove full description of big example.
|
||||||
|
@ -373,7 +373,6 @@ blocks of code.
|
|||||||
@node Main program
|
@node Main program
|
||||||
@section Main program
|
@section Main program
|
||||||
|
|
||||||
@deffn @code{.stabs} N_MAIN
|
|
||||||
@findex N_MAIN
|
@findex N_MAIN
|
||||||
Most languages allow the main program to have any name. The
|
Most languages allow the main program to have any name. The
|
||||||
@code{N_MAIN} stab type tells the debugger the name that is used in this
|
@code{N_MAIN} stab type tells the debugger the name that is used in this
|
||||||
@ -382,12 +381,10 @@ a function which is the main program. Most C compilers do not use this
|
|||||||
stab (they expect the debugger to assume that the name is @code{main}),
|
stab (they expect the debugger to assume that the name is @code{main}),
|
||||||
but some C compilers emit an @code{N_MAIN} stab for the @code{main}
|
but some C compilers emit an @code{N_MAIN} stab for the @code{main}
|
||||||
function.
|
function.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Source files
|
@node Source files
|
||||||
@section Paths and names of the source files
|
@section Paths and names of the source files
|
||||||
|
|
||||||
@deffn @code{.stabs} N_SO
|
|
||||||
@findex N_SO
|
@findex N_SO
|
||||||
Before any other stabs occur, there must be a stab specifying the source
|
Before any other stabs occur, there must be a stab specifying the source
|
||||||
file. This information is contained in a symbol of stab type
|
file. This information is contained in a symbol of stab type
|
||||||
@ -415,7 +412,6 @@ For example:
|
|||||||
.text
|
.text
|
||||||
Ltext0:
|
Ltext0:
|
||||||
@end example
|
@end example
|
||||||
@end deffn
|
|
||||||
|
|
||||||
Instead of @code{N_SO} symbols, XCOFF uses a @code{.file} assembler
|
Instead of @code{N_SO} symbols, XCOFF uses a @code{.file} assembler
|
||||||
directive which assembles to a standard COFF @code{.file} symbol;
|
directive which assembles to a standard COFF @code{.file} symbol;
|
||||||
@ -429,7 +425,6 @@ traditional @code{N_SOL} approach, Sun's @code{N_BINCL} approach, and the
|
|||||||
XCOFF @code{C_BINCL} approach (which despite the similar name has little in
|
XCOFF @code{C_BINCL} approach (which despite the similar name has little in
|
||||||
common with @code{N_BINCL}).
|
common with @code{N_BINCL}).
|
||||||
|
|
||||||
@deffn @code{.stabs} N_SOL
|
|
||||||
@findex N_SOL
|
@findex N_SOL
|
||||||
An @code{N_SOL} symbol specifies which include file subsequent symbols
|
An @code{N_SOL} symbol specifies which include file subsequent symbols
|
||||||
refer to. The @var{string} field is the name of the file and the
|
refer to. The @var{string} field is the name of the file and the
|
||||||
@ -437,33 +432,27 @@ refer to. The @var{string} field is the name of the file and the
|
|||||||
previous include file and the start of this one. To specify the main
|
previous include file and the start of this one. To specify the main
|
||||||
source file again, use an @code{N_SOL} symbol with the name of the main
|
source file again, use an @code{N_SOL} symbol with the name of the main
|
||||||
source file.
|
source file.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@deffn @code{.stabs} N_BINCL
|
|
||||||
@deffnx @code{.stabs} N_EINCL
|
|
||||||
@deffnx {} N_EXCL
|
|
||||||
@findex N_BINCL
|
@findex N_BINCL
|
||||||
@findex N_EINCL
|
@findex N_EINCL
|
||||||
@findex N_EXCL
|
@findex N_EXCL
|
||||||
On Suns, an @code{N_BINCL} symbol specifies the start of an include file.
|
The @code{N_BINCL} approach works as follows. An @code{N_BINCL} symbol
|
||||||
In an object file, only the @var{string} is significant; the Sun linker
|
specifies the start of an include file. In an object file, only the
|
||||||
puts data into some of the other fields. The end of the include file is
|
@var{string} is significant; the Sun linker puts data into some of the
|
||||||
marked by an @code{N_EINCL} symbol (which has no @var{string} field). In
|
other fields. The end of the include file is marked by an
|
||||||
an object file, there is no significant data in the @code{N_EINCL}
|
@code{N_EINCL} symbol (which has no @var{string} field). In an object
|
||||||
symbol; the Sun linker puts data into some of the fields.
|
file, there is no significant data in the @code{N_EINCL} symbol; the Sun
|
||||||
@code{N_BINCL} and @code{N_EINCL} can be nested.
|
linker puts data into some of the fields. @code{N_BINCL} and
|
||||||
|
@code{N_EINCL} can be nested.
|
||||||
|
|
||||||
If the linker detects that two source files have identical stabs with an
|
If the linker detects that two source files have identical stabs between
|
||||||
@code{N_BINCL} and @code{N_EINCL} pair (as will generally be the case
|
an @code{N_BINCL} and @code{N_EINCL} pair (as will generally be the case
|
||||||
for a header file), then it only puts out the stabs once. Each
|
for a header file), then it only puts out the stabs once. Each
|
||||||
additional occurance is replaced by an @code{N_EXCL} symbol. I believe
|
additional occurance is replaced by an @code{N_EXCL} symbol. I believe
|
||||||
the Sun (SunOS4, not sure about Solaris) linker is the only one which
|
the Sun (SunOS4, not sure about Solaris) linker is the only one which
|
||||||
supports this feature.
|
supports this feature.
|
||||||
@c What do the fields of N_EXCL contain? -djm
|
@c What do the fields of N_EXCL contain? -djm
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@deffn @code{.bi} C_BINCL
|
|
||||||
@deffnx @code{.ei} C_EINCL
|
|
||||||
@findex C_BINCL
|
@findex C_BINCL
|
||||||
@findex C_EINCL
|
@findex C_EINCL
|
||||||
For the start of an include file in XCOFF, use the @file{.bi} assembler
|
For the start of an include file in XCOFF, use the @file{.bi} assembler
|
||||||
@ -476,22 +465,17 @@ and linker, is the offset into the executable of the beginning
|
|||||||
(inclusive, as you'd expect) or end (inclusive, as you would not expect)
|
(inclusive, as you'd expect) or end (inclusive, as you would not expect)
|
||||||
of the portion of the COFF line table that corresponds to this include
|
of the portion of the COFF line table that corresponds to this include
|
||||||
file. @code{C_BINCL} and @code{C_EINCL} do not nest.
|
file. @code{C_BINCL} and @code{C_EINCL} do not nest.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Line numbers
|
@node Line numbers
|
||||||
@section Line numbers
|
@section Line numbers
|
||||||
|
|
||||||
@deffn @code{.stabn} N_SLINE
|
|
||||||
@findex N_SLINE
|
@findex N_SLINE
|
||||||
An @code{N_SLINE} symbol represents the start of a source line. The
|
An @code{N_SLINE} symbol represents the start of a source line. The
|
||||||
@var{desc} field contains the line number and the @var{value} field
|
@var{desc} field contains the line number and the @var{value} field
|
||||||
contains the code address for the start of that source line. On most
|
contains the code address for the start of that source line. On most
|
||||||
machines the address is absolute; for Sun's stabs-in-ELF, it is relative
|
machines the address is absolute; for Sun's stabs-in-ELF, it is relative
|
||||||
to the function in which the @code{N_SLINE} symbol occurs.
|
to the function in which the @code{N_SLINE} symbol occurs.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@deffn @code{.stabn} N_DSLINE
|
|
||||||
@deffnx @code{.stabn} N_BSLINE
|
|
||||||
@findex N_DSLINE
|
@findex N_DSLINE
|
||||||
@findex N_BSLINE
|
@findex N_BSLINE
|
||||||
GNU documents @code{N_DSLINE} and @code{N_BSLINE} symbols for line
|
GNU documents @code{N_DSLINE} and @code{N_BSLINE} symbols for line
|
||||||
@ -502,7 +486,6 @@ declaration, but I believe that GCC2 actually puts the line number in
|
|||||||
the @var{desc} field of the stab for the variable itself. GDB has been
|
the @var{desc} field of the stab for the variable itself. GDB has been
|
||||||
ignoring these symbols (unless they contain a @var{string} field) since
|
ignoring these symbols (unless they contain a @var{string} field) since
|
||||||
at least GDB 3.5.
|
at least GDB 3.5.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
For single source lines that generate discontiguous code, such as flow
|
For single source lines that generate discontiguous code, such as flow
|
||||||
of control statements, there may be more than one line number entry for
|
of control statements, there may be more than one line number entry for
|
||||||
@ -510,42 +493,54 @@ the same source line. In this case there is a line number entry at the
|
|||||||
start of each code range, each with the same line number.
|
start of each code range, each with the same line number.
|
||||||
|
|
||||||
XCOFF uses COFF line numbers, which are outside the scope of this
|
XCOFF uses COFF line numbers, which are outside the scope of this
|
||||||
document.
|
document, ammeliorated by adequate marking of include files
|
||||||
|
(@pxref{Include files}).
|
||||||
|
|
||||||
@node Procedures
|
@node Procedures
|
||||||
@section Procedures
|
@section Procedures
|
||||||
|
|
||||||
@deffn @code{.stabs} N_FUN
|
|
||||||
@findex N_FUN
|
@findex N_FUN
|
||||||
All of the following stabs use the @code{N_FUN} symbol type.
|
@findex N_FNAME
|
||||||
|
@findex N_STSYM, for functions (Sun acc)
|
||||||
|
@findex N_GSYM, for functions (Sun acc)
|
||||||
|
All of the following stabs normally use the @code{N_FUN} symbol type.
|
||||||
|
However, Sun's @code{acc} compiler on SunOS4 uses @code{N_GSYM} and
|
||||||
|
@code{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. BSD Fortran is said to use @code{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 @samp{F} symbol descriptor for a global
|
A function is represented by an @samp{F} symbol descriptor for a global
|
||||||
(extern) function, and @samp{f} for a static (local) function. (The next
|
(extern) function, and @samp{f} for a static (local) function. The
|
||||||
@code{N_SLINE} symbol gives the line number of the start
|
@var{value} field is the address of the start of the function (absolute
|
||||||
of the function.) The @var{value} field is the address of the start of the
|
for @code{a.out}; relative to the start of the file for Sun's
|
||||||
function (absolute for @code{a.out}; relative to the start of the file
|
stabs-in-ELF). The type information of the stab represents the return
|
||||||
for Sun's stabs-in-ELF). The type information of the stab represents
|
type of the function; thus @samp{foo:f5} means that foo is a function
|
||||||
the return type of the function; thus @samp{foo:f5} means that foo is a
|
returning type 5. There is no need to try to get the line number of the
|
||||||
function returning type 5.
|
start of the function from the stab for the function; it is in the next
|
||||||
|
@code{N_SLINE} symbol.
|
||||||
|
|
||||||
@c What determines whether the option here v is taken? -djm
|
@c FIXME: verify whether the "I suspect" below is true or not.
|
||||||
The type information of the stab is optionally followed by type
|
Some compilers (such as Sun's Solaris compiler) support an extension for
|
||||||
information for each argument, with each argument preceded by @samp{;}.
|
specifying the types of the arguments. I suspect this extension is not
|
||||||
An argument type of 0 means that additional arguments are being passed,
|
used for old (non-prototyped) function definitions in C. If the
|
||||||
whose types and number may vary (@samp{...} in ANSI C). This extension
|
extension is in use, the type information of the stab for the function
|
||||||
is used by Sun's Solaris compiler. GDB has tolerated it (parsed the
|
is followed by type information for each argument, with each argument
|
||||||
syntax, if not necessarily used the information) since at least version
|
preceded by @samp{;}. An argument type of 0 means that additional
|
||||||
4.8; I don't know whether all versions of dbx tolerate it. The
|
arguments are being passed, whose types and number may vary (@samp{...}
|
||||||
argument types given here are not redundant with the symbols for the
|
in ANSI C). GDB has tolerated this extension (parsed the syntax, if not
|
||||||
arguments themselves (@pxref{Parameters}); they are the types of the
|
necessarily used the information) since at least version 4.8; I don't
|
||||||
arguments as they are passed, before any conversions might take place.
|
know whether all versions of dbx tolerate it. The argument types given
|
||||||
For example, if a C function which is declared without a prototype takes
|
here are not redundant with the symbols for the formal parameters
|
||||||
a @code{float} argument, the value is passed as a @code{double} but then
|
(@pxref{Parameters}); they are the types of the arguments as they are
|
||||||
converted to a @code{float}. Debuggers need to use the types given in
|
passed, before any conversions might take place. For example, if a C
|
||||||
the arguments when printing values, but if calling the function they
|
function which is declared without a prototype takes a @code{float}
|
||||||
need to use the types given in the symbol defining the function.
|
argument, the value is passed as a @code{double} but then converted to a
|
||||||
@c Are the "arguments themselves" referred to above the actual
|
@code{float}. Debuggers need to use the types given in the arguments
|
||||||
@c or formal parameters? I'm confused. -djm
|
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
|
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
|
in another source file are specified (i.e., a function prototype in ANSI
|
||||||
@ -572,31 +567,13 @@ necessary), but the AIX documentation defines @samp{I}, @samp{P}, and
|
|||||||
These symbol descriptors are unusual in that they are not followed by
|
These symbol descriptors are unusual in that they are not followed by
|
||||||
type information.
|
type information.
|
||||||
|
|
||||||
Here is an exploded summary (with whitespace added for clarity):
|
The following example shows a stab for a function @code{main} which
|
||||||
|
returns type number @code{1}. The @code{_main} specified for the value
|
||||||
|
is a reference to an assembler label which is used to fill in the start
|
||||||
|
address of the function.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
.stabs "@var{name}:
|
.stabs "main:F1",36,0,0,_main # @r{36 is N_FUN}
|
||||||
@var{desc} @r{(global proc @samp{F})}
|
|
||||||
@var{return_type_ref} @r{(int)}
|
|
||||||
",N_FUN, NIL, NIL,
|
|
||||||
@var{address}
|
|
||||||
@end example
|
|
||||||
|
|
||||||
Going back to our ``hello world'' example program,
|
|
||||||
|
|
||||||
@example
|
|
||||||
48 ret
|
|
||||||
49 restore
|
|
||||||
@end example
|
|
||||||
|
|
||||||
@noindent
|
|
||||||
The @code{.stabs} entry after this code fragment shows the @var{name} of
|
|
||||||
the procedure (@code{main}); the type descriptor @var{desc} (@code{F},
|
|
||||||
for a global procedure); a reference to the predefined type @code{int}
|
|
||||||
for the return type; and the starting @var{address} of the procedure.
|
|
||||||
|
|
||||||
@example
|
|
||||||
50 .stabs "main:F1",36,0,0,_main
|
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
The stab representing a procedure is located immediately following the
|
The stab representing a procedure is located immediately following the
|
||||||
@ -604,18 +581,17 @@ code of the procedure. This stab is in turn directly followed by a
|
|||||||
group of other stabs describing elements of the procedure. These other
|
group of other stabs describing elements of the procedure. These other
|
||||||
stabs describe the procedure's parameters, its block local variables, and
|
stabs describe the procedure's parameters, its block local variables, and
|
||||||
its block structure.
|
its block structure.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Nested procedures
|
@node Nested procedures
|
||||||
@section Nested procedures
|
@section Nested procedures
|
||||||
|
|
||||||
For any of the @code{N_FUN} symbol descriptors, after the symbol
|
For any of the symbol descriptors representing procedures, after the
|
||||||
descriptor and the type information is optionally a scope specifier.
|
symbol descriptor and the type information is optionally a scope
|
||||||
This consists of a comma, the name of the procedure, another comma, and
|
specifier. This consists of a comma, the name of the procedure, another
|
||||||
the name of the enclosing procedure. The first name is local to the
|
comma, and the name of the enclosing procedure. The first name is local
|
||||||
scope specified, and seems to be redundant with the name of the symbol
|
to the scope specified, and seems to be redundant with the name of the
|
||||||
(before the @samp{:}). This feature is used by GCC, and presumably
|
symbol (before the @samp{:}). This feature is used by GCC, and
|
||||||
Pascal, Modula-2, etc., compilers, for nested functions.
|
presumably Pascal, Modula-2, etc., compilers, for nested functions.
|
||||||
|
|
||||||
If procedures are nested more than one level deep, only the immediately
|
If procedures are nested more than one level deep, only the immediately
|
||||||
containing scope is specified. For example, this code:
|
containing scope is specified. For example, this code:
|
||||||
@ -648,8 +624,6 @@ produces the stabs:
|
|||||||
@node Block structure
|
@node Block structure
|
||||||
@section Block structure
|
@section Block structure
|
||||||
|
|
||||||
@deffn @code{.stabn} N_LBRAC
|
|
||||||
@deffnx @code{.stabn} N_RBRAC
|
|
||||||
@findex N_LBRAC
|
@findex N_LBRAC
|
||||||
@findex N_RBRAC
|
@findex N_RBRAC
|
||||||
The program's block structure is represented by the @code{N_LBRAC} (left
|
The program's block structure is represented by the @code{N_LBRAC} (left
|
||||||
@ -672,7 +646,6 @@ Sun documents the @var{desc} field of @code{N_LBRAC} and
|
|||||||
@code{N_RBRAC} symbols as containing the nesting level of the block.
|
@code{N_RBRAC} symbols as containing the nesting level of the block.
|
||||||
However, dbx seems to not care, and GCC always sets @var{desc} to
|
However, dbx seems to not care, and GCC always sets @var{desc} to
|
||||||
zero.
|
zero.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Constants
|
@node Constants
|
||||||
@chapter Constants
|
@chapter Constants
|
||||||
@ -765,16 +738,15 @@ long as that function executes (C calls such variables
|
|||||||
@dfn{automatic}), it can be allocated in a register (@pxref{Register
|
@dfn{automatic}), it can be allocated in a register (@pxref{Register
|
||||||
variables}) or on the stack.
|
variables}) or on the stack.
|
||||||
|
|
||||||
@deffn @code{.stabs} N_LSYM
|
|
||||||
@findex N_LSYM
|
@findex N_LSYM
|
||||||
Each variable allocated on the stack has a stab of type @code{N_LSYM},
|
Each variable allocated on the stack has a stab with the symbol
|
||||||
with the symbol descriptor omitted. Since type information should begin
|
descriptor omitted. Since type information should begin with a digit,
|
||||||
with a digit, @samp{-}, or @samp{(}, only those characters precluded
|
@samp{-}, or @samp{(}, only those characters precluded from being used
|
||||||
from being used for symbol descriptors. However, the Acorn RISC machine
|
for symbol descriptors. However, the Acorn RISC machine (ARM) is said
|
||||||
(ARM) is said to get this wrong: it puts out a mere type definition
|
to get this wrong: it puts out a mere type definition here, without the
|
||||||
here, without the preceding @samp{@var{type-number}=}. This is a bad
|
preceding @samp{@var{type-number}=}. This is a bad idea; there is no
|
||||||
idea; there is no guarantee that type descriptors are distinct from
|
guarantee that type descriptors are distinct from symbol descriptors.
|
||||||
symbol descriptors.
|
Stabs for stack variables use the @code{N_LSYM} stab type.
|
||||||
|
|
||||||
The @var{value} of the stab is the offset of the variable within the
|
The @var{value} of the stab is the offset of the variable within the
|
||||||
local variables. On most machines this is an offset from the frame
|
local variables. On most machines this is an offset from the frame
|
||||||
@ -803,12 +775,10 @@ produces the following stabs:
|
|||||||
@xref{Procedures} for more information on the @code{N_FUN} stab, and
|
@xref{Procedures} for more information on the @code{N_FUN} stab, and
|
||||||
@ref{Block structure} for more information on the @code{N_LBRAC} and
|
@ref{Block structure} for more information on the @code{N_LBRAC} and
|
||||||
@code{N_RBRAC} stabs.
|
@code{N_RBRAC} stabs.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Global variables
|
@node Global variables
|
||||||
@section Global variables
|
@section Global variables
|
||||||
|
|
||||||
@deffn @code{.stabs} N_GSYM
|
|
||||||
@findex N_GSYM
|
@findex N_GSYM
|
||||||
A variable whose scope is not specific to just one source file is
|
A variable whose scope is not specific to just one source file is
|
||||||
represented by the @samp{G} symbol descriptor. These stabs use the
|
represented by the @samp{G} symbol descriptor. These stabs use the
|
||||||
@ -837,12 +807,10 @@ contained in the @code{N_GSYM} stab. The debugger gets this information
|
|||||||
from the external symbol for the global variable. In the example above,
|
from the external symbol for the global variable. In the example above,
|
||||||
the @code{.global _g_foo} and @code{_g_foo:} lines tell the assembler to
|
the @code{.global _g_foo} and @code{_g_foo:} lines tell the assembler to
|
||||||
produce an external symbol.
|
produce an external symbol.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Register variables
|
@node Register variables
|
||||||
@section Register variables
|
@section Register variables
|
||||||
|
|
||||||
@deffn @code{.stabn} N_RSYM
|
|
||||||
@findex N_RSYM
|
@findex N_RSYM
|
||||||
@c According to an old version of this manual, AIX uses C_RPSYM instead
|
@c According to an old version of this manual, AIX uses C_RPSYM instead
|
||||||
@c of C_RSYM. I am skeptical; this should be verified.
|
@c of C_RSYM. I am skeptical; this should be verified.
|
||||||
@ -866,7 +834,6 @@ register int g_bar asm ("%g5");
|
|||||||
@noindent
|
@noindent
|
||||||
then the stab may be emitted at the end of the object file, with
|
then the stab may be emitted at the end of the object file, with
|
||||||
the other bss symbols.
|
the other bss symbols.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Common blocks
|
@node Common blocks
|
||||||
@section Common blocks
|
@section Common blocks
|
||||||
@ -875,17 +842,13 @@ A common block is a statically allocated section of memory which can be
|
|||||||
referred to by several source files. It may contain several variables.
|
referred to by several source files. It may contain several variables.
|
||||||
I believe Fortran is the only language with this feature.
|
I believe Fortran is the only language with this feature.
|
||||||
|
|
||||||
@deffn @code{.stabs} N_BCOMM
|
|
||||||
@deffnx @code{.stabs} N_ECOMM
|
|
||||||
@findex N_BCOMM
|
@findex N_BCOMM
|
||||||
@findex N_ECOMM
|
@findex N_ECOMM
|
||||||
A @code{N_BCOMM} stab begins a common block and an @code{N_ECOMM} stab
|
A @code{N_BCOMM} stab begins a common block and an @code{N_ECOMM} stab
|
||||||
ends it. The only field that is significant in these two stabs is the
|
ends it. The only field that is significant in these two stabs is the
|
||||||
@var{string}, which names a normal (non-debugging) symbol that gives the
|
@var{string}, which names a normal (non-debugging) symbol that gives the
|
||||||
address of the common block.
|
address of the common block.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@deffn @code{.stabn} N_ECOML
|
|
||||||
@findex N_ECOML
|
@findex N_ECOML
|
||||||
Each stab between the @code{N_BCOMM} and the @code{N_ECOMM} specifies a
|
Each stab between the @code{N_BCOMM} and the @code{N_ECOMM} specifies a
|
||||||
member of that common block; its @var{value} is the offset within the
|
member of that common block; its @var{value} is the offset within the
|
||||||
@ -895,7 +858,6 @@ documented for this purpose, but Sun's Fortran compiler uses
|
|||||||
local to a function and it used the @samp{V} symbol descriptor; I assume
|
local to a function and it used the @samp{V} symbol descriptor; I assume
|
||||||
one would use @samp{S} if not local to a function (that is, if a common
|
one would use @samp{S} if not local to a function (that is, if a common
|
||||||
block @emph{can} be anything other than local to a function).
|
block @emph{can} be anything other than local to a function).
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node Statics
|
@node Statics
|
||||||
@section Static variables
|
@section Static variables
|
||||||
@ -910,8 +872,6 @@ Initialized static variables are represented by the @samp{S} and
|
|||||||
@c (although GCC
|
@c (although GCC
|
||||||
@c 2.4.5 has a bug in that it uses @code{N_FUN}, so neither dbx nor GDB can
|
@c 2.4.5 has a bug in that it uses @code{N_FUN}, so neither dbx nor GDB can
|
||||||
@c find the variables)
|
@c find the variables)
|
||||||
@deffn @code{.stabs} N_STSYM
|
|
||||||
@deffnx @code{.stabs} N_LCSYM
|
|
||||||
@findex N_STSYM
|
@findex N_STSYM
|
||||||
@findex N_LCSYM
|
@findex N_LCSYM
|
||||||
In a.out files, @code{N_STSYM} means the data segment, @code{N_FUN}
|
In a.out files, @code{N_STSYM} means the data segment, @code{N_FUN}
|
||||||
@ -935,7 +895,6 @@ yield the following stabs:
|
|||||||
@dots{}
|
@dots{}
|
||||||
.stabs "var_noinit:S1",40,0,0,_var_noinit # @r{40 is N_LCSYM}
|
.stabs "var_noinit:S1",40,0,0,_var_noinit # @r{40 is N_LCSYM}
|
||||||
@end example
|
@end example
|
||||||
@end deffn
|
|
||||||
|
|
||||||
In XCOFF files, each symbol has a section number, so the stab type
|
In XCOFF files, each symbol has a section number, so the stab type
|
||||||
need not indicate the segment.
|
need not indicate the segment.
|
||||||
@ -952,13 +911,12 @@ stab type need not indicate the segment.
|
|||||||
@node Parameters
|
@node Parameters
|
||||||
@section Parameters
|
@section Parameters
|
||||||
|
|
||||||
Actual parameters to a function are represented by a stab (or sometimes
|
Formal parameters to a function are represented by a stab (or sometimes
|
||||||
two; see below) for each parameter. The stabs are in the order in which
|
two; see below) for each parameter. The stabs are in the order in which
|
||||||
the debugger should print the parameters (i.e., the order in which the
|
the debugger should print the parameters (i.e., the order in which the
|
||||||
parameters are declared in the source file). The exact form of the stab
|
parameters are declared in the source file). The exact form of the stab
|
||||||
depends on how the parameter is being passed.
|
depends on how the parameter is being passed.
|
||||||
|
|
||||||
@deffn @code{.stabs} N_PSYM
|
|
||||||
@findex N_PSYM
|
@findex N_PSYM
|
||||||
Parameters passed on the stack use the symbol descriptor @samp{p} and
|
Parameters passed on the stack use the symbol descriptor @samp{p} and
|
||||||
the @code{N_PSYM} symbol type. The @var{value} of the symbol is an offset
|
the @code{N_PSYM} symbol type. The @var{value} of the symbol is an offset
|
||||||
@ -985,7 +943,19 @@ produces the stabs:
|
|||||||
The type definition of @code{argv} is interesting because it contains
|
The type definition of @code{argv} is interesting because it contains
|
||||||
several type definitions. Type 21 is pointer to type 2 (char) and
|
several type definitions. Type 21 is pointer to type 2 (char) and
|
||||||
@code{argv} (type 20) is pointer to type 21.
|
@code{argv} (type 20) is pointer to type 21.
|
||||||
@end deffn
|
|
||||||
|
@c FIXME: figure out what these mean and describe them coherently.
|
||||||
|
The following are also said to go with @code{N_PSYM}:
|
||||||
|
|
||||||
|
@example
|
||||||
|
"name" -> "param_name:#type"
|
||||||
|
-> pP (<<??>>)
|
||||||
|
-> pF Fortran function parameter
|
||||||
|
-> X (function result variable)
|
||||||
|
-> b (based variable)
|
||||||
|
|
||||||
|
value -> offset from the argument pointer (positive).
|
||||||
|
@end example
|
||||||
|
|
||||||
@menu
|
@menu
|
||||||
* Register parameters::
|
* Register parameters::
|
||||||
@ -1008,8 +978,8 @@ two symbols for each argument:
|
|||||||
Debuggers use the second one to find the value, and the first one to
|
Debuggers use the second one to find the value, and the first one to
|
||||||
know that it is an argument.
|
know that it is an argument.
|
||||||
|
|
||||||
@deffn @code{.stabs} C_RPSYM
|
|
||||||
@findex C_RPSYM
|
@findex C_RPSYM
|
||||||
|
@findex N_RSYM, for parameters
|
||||||
Because that approach is kind of ugly, some compilers use symbol
|
Because that approach is kind of ugly, some compilers use symbol
|
||||||
descriptor @samp{P} or @samp{R} to indicate an argument which is in a
|
descriptor @samp{P} or @samp{R} to indicate an argument which is in a
|
||||||
register. Symbol type @code{C_RPSYM} is used with @samp{R} and
|
register. Symbol type @code{C_RPSYM} is used with @samp{R} and
|
||||||
@ -1017,7 +987,6 @@ register. Symbol type @code{C_RPSYM} is used with @samp{R} and
|
|||||||
the register number. @samp{P} and @samp{R} mean the same thing; the
|
the register number. @samp{P} and @samp{R} mean the same thing; the
|
||||||
difference is that @samp{P} is a GNU invention and @samp{R} is an IBM
|
difference is that @samp{P} is a GNU invention and @samp{R} is an IBM
|
||||||
(XCOFF) invention. As of version 4.9, GDB should handle either one.
|
(XCOFF) invention. As of version 4.9, GDB should handle either one.
|
||||||
@end deffn
|
|
||||||
|
|
||||||
There is at least one case where GCC uses a @samp{p} and @samp{r} pair
|
There is at least one case where GCC uses a @samp{p} and @samp{r} pair
|
||||||
rather than @samp{P}; this is where the argument is passed in the
|
rather than @samp{P}; this is where the argument is passed in the
|
||||||
@ -1029,6 +998,8 @@ unnecessary---why not just use @samp{R} with a register number which
|
|||||||
indicates that it's a floating point register? I haven't verified
|
indicates that it's a floating point register? I haven't verified
|
||||||
whether the system actually does what the documentation indicates.
|
whether the system actually does what the documentation indicates.
|
||||||
|
|
||||||
|
@c FIXME: On the hppa this is for any type > 8 bytes, I think, and not
|
||||||
|
@c for small structures (investigate).
|
||||||
On the sparc and hppa, for a @samp{P} symbol whose type is a structure
|
On the sparc and hppa, for a @samp{P} symbol whose type is a structure
|
||||||
or union, the register contains the address of the structure. On the
|
or union, the register contains the address of the structure. On the
|
||||||
sparc, this is also true of a @samp{p} and @samp{r} pair (using Sun
|
sparc, this is also true of a @samp{p} and @samp{r} pair (using Sun
|
||||||
@ -1052,6 +1023,7 @@ happens when the argument was passed in a register and then the compiler
|
|||||||
stores it as a local variable. If possible, the compiler should claim
|
stores it as a local variable. If possible, the compiler should claim
|
||||||
that it's in a register, but this isn't always done.
|
that it's in a register, but this isn't always done.
|
||||||
|
|
||||||
|
@findex N_LSYM, for parameter
|
||||||
Some compilers use the pair of symbols approach described above
|
Some compilers use the pair of symbols approach described above
|
||||||
(@samp{@var{arg}:p} followed by @samp{@var{arg}:}); this includes GCC1
|
(@samp{@var{arg}:p} followed by @samp{@var{arg}:}); this includes GCC1
|
||||||
(not GCC2) on the sparc when passing a small structure and GCC2
|
(not GCC2) on the sparc when passing a small structure and GCC2
|
||||||
@ -1171,19 +1143,17 @@ the type is an unsigned integral type whose bounds are too
|
|||||||
big to describe in an @code{int}. Traditionally this is only used for
|
big to describe in an @code{int}. Traditionally this is only used for
|
||||||
@code{unsigned int} and @code{unsigned long}:
|
@code{unsigned int} and @code{unsigned long}:
|
||||||
|
|
||||||
@c FIXME: Update this for the 2.4.5 output, not 2.3.3
|
|
||||||
@example
|
@example
|
||||||
.stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
|
.stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
|
||||||
.stabs "long long int:t7=r1;0;-1;",128,0,0,0
|
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
For larger types, GCC
|
For larger types, GCC 2.4.5 puts out bounds in octal, with a leading 0.
|
||||||
2.4.5 puts out bounds in octal, with a leading 0. In this case a
|
In this case a negative bound consists of a number which is a 1 bit
|
||||||
negative bound consists of a number which is a 1 bit followed by a bunch
|
followed by a bunch of 0 bits, and a positive bound is one in which a
|
||||||
of 0 bits, and a positive bound is one in which a bunch of bits are 1.
|
bunch of bits are 1. All known versions of dbx and GDB version 4 accept
|
||||||
All known versions of dbx and GDB version 4 accept this, but GDB 3.5
|
this, but GDB 3.5 refuses to read the whole file containing such
|
||||||
refuses to read the whole file containing such symbols. So GCC 2.3.3
|
symbols. So GCC 2.3.3 did not output the proper size for these types.
|
||||||
did not output the proper size for these types.
|
@c FIXME: How about an example?
|
||||||
|
|
||||||
If the lower bound of a subrange is 0 and the upper bound is negative,
|
If the lower bound of a subrange is 0 and the upper bound is negative,
|
||||||
the type is an unsigned integral type whose size in bytes is the
|
the type is an unsigned integral type whose size in bytes is the
|
||||||
@ -1282,7 +1252,7 @@ them as Fortran @code{complex}, @code{double complex}, and
|
|||||||
precision? Double precison?).
|
precision? Double precison?).
|
||||||
|
|
||||||
@item 6 (NF_LDOUBLE)
|
@item 6 (NF_LDOUBLE)
|
||||||
@code{long double}. This should probably only be used for Sun format
|
Long double. This should probably only be used for Sun format
|
||||||
@code{long double}, and new codes should be used for other floating
|
@code{long double}, and new codes should be used for other floating
|
||||||
point formats (@code{NF_DOUBLE} can be used if a @code{long double} is
|
point formats (@code{NF_DOUBLE} can be used if a @code{long double} is
|
||||||
really just an IEEE double, of course).
|
really just an IEEE double, of course).
|
||||||
@ -1457,9 +1427,6 @@ Unicode?).
|
|||||||
@node Miscellaneous types
|
@node Miscellaneous types
|
||||||
@section Miscellaneous types
|
@section Miscellaneous types
|
||||||
|
|
||||||
These type descriptors are for types that are built into languages and
|
|
||||||
are derived from the fundamental types.
|
|
||||||
|
|
||||||
@table @code
|
@table @code
|
||||||
@item b @var{type-information} ; @var{bytes}
|
@item b @var{type-information} ; @var{bytes}
|
||||||
Pascal space type. This is documented by IBM; what does it mean?
|
Pascal space type. This is documented by IBM; what does it mean?
|
||||||
@ -1470,9 +1437,9 @@ descriptors}) because the character following the type descriptor is
|
|||||||
always a digit, @samp{(}, or @samp{-}.
|
always a digit, @samp{(}, or @samp{-}.
|
||||||
|
|
||||||
@item B @var{type-information}
|
@item B @var{type-information}
|
||||||
A @code{volatile}-qualified version of @var{type-information}. This is
|
A volatile-qualified version of @var{type-information}. This is
|
||||||
a Sun extension. References and stores to a variable with a
|
a Sun extension. References and stores to a variable with a
|
||||||
@code{volatile}-qualified type must not be optimized or cached; they
|
volatile-qualified type must not be optimized or cached; they
|
||||||
must occur as the user specifies them.
|
must occur as the user specifies them.
|
||||||
|
|
||||||
@item d @var{type-information}
|
@item d @var{type-information}
|
||||||
@ -1480,9 +1447,8 @@ File of type @var{type-information}. As far as I know this is only used
|
|||||||
by Pascal.
|
by Pascal.
|
||||||
|
|
||||||
@item k @var{type-information}
|
@item k @var{type-information}
|
||||||
A @code{const}-qualified version of @var{type-information}. This is a
|
A const-qualified version of @var{type-information}. This is a Sun
|
||||||
Sun extension. A variable with a @code{const}-qualified type cannot be
|
extension. A variable with a const-qualified type cannot be modified.
|
||||||
modified.
|
|
||||||
|
|
||||||
@item M @var{type-information} ; @var{length}
|
@item M @var{type-information} ; @var{length}
|
||||||
Multiple instance type. The type seems to composed of @var{length}
|
Multiple instance type. The type seems to composed of @var{length}
|
||||||
@ -1603,12 +1569,12 @@ gives @samp{ar1;1;10;ar1;1;10;4} as a legitimate way to express a two
|
|||||||
dimensional array. According to AIX documentation, the element type
|
dimensional array. According to AIX documentation, the element type
|
||||||
must be type information. GDB accepts either.
|
must be type information. GDB accepts either.
|
||||||
|
|
||||||
The type of the index is often a range type, expressed as the letter @samp{r}
|
The type of the index is often a range type, expressed as the type
|
||||||
and some parameters. It defines the size of the array. In the example
|
descriptor @samp{r} and some parameters. It defines the size of the
|
||||||
below, the range @samp{r1;0;2;} defines an index type which is a
|
array. In the example below, the range @samp{r1;0;2;} defines an index
|
||||||
subrange of type 1 (integer), with a lower bound of 0 and an upper bound
|
type which is a subrange of type 1 (integer), with a lower bound of 0
|
||||||
of 2. This defines the valid range of subscripts of a three-element C
|
and an upper bound of 2. This defines the valid range of subscripts of
|
||||||
array.
|
a three-element C array.
|
||||||
|
|
||||||
For example, the definition:
|
For example, the definition:
|
||||||
|
|
||||||
@ -1722,7 +1688,7 @@ structure, enumeration, or union tag. The type descriptor @samp{e},
|
|||||||
following the @samp{22=} of the type definition narrows it down to an
|
following the @samp{22=} of the type definition narrows it down to an
|
||||||
enumeration type. Following the @samp{e} is a list of the elements of
|
enumeration type. Following the @samp{e} is a list of the elements of
|
||||||
the enumeration. The format is @samp{@var{name}:@var{value},}. The
|
the enumeration. The format is @samp{@var{name}:@var{value},}. The
|
||||||
list of elements ends with a @samp{;}.
|
list of elements ends with @samp{;}.
|
||||||
|
|
||||||
There is no standard way to specify the size of an enumeration type; it
|
There is no standard way to specify the size of an enumeration type; it
|
||||||
is determined by the architecture (normally all enumerations types are
|
is determined by the architecture (normally all enumerations types are
|
||||||
@ -1758,26 +1724,18 @@ typedef struct s_tag s_typedef;
|
|||||||
The structure tag has an @code{N_LSYM} stab type because, like the
|
The structure tag has an @code{N_LSYM} stab type because, like the
|
||||||
enumeration, the symbol has file scope. Like the enumeration, the
|
enumeration, the symbol has file scope. Like the enumeration, the
|
||||||
symbol descriptor is @samp{T}, for enumeration, structure, or tag type.
|
symbol descriptor is @samp{T}, for enumeration, structure, or tag type.
|
||||||
The symbol descriptor @samp{s} following the @samp{16=} of the type
|
The type descriptor @samp{s} following the @samp{16=} of the type
|
||||||
definition narrows the symbol type to structure.
|
definition narrows the symbol type to structure.
|
||||||
|
|
||||||
Following the structure symbol descriptor is the number of bytes the
|
Following the @samp{s} type descriptor is the number of bytes the
|
||||||
structure occupies, followed by a description of each structure element.
|
structure occupies, followed by a description of each structure element.
|
||||||
The structure element descriptions are of the form @var{name:type, bit
|
The structure element descriptions are of the form @var{name:type, bit
|
||||||
offset from the start of the struct, number of bits in the element}.
|
offset from the start of the struct, number of bits in the element}.
|
||||||
|
|
||||||
@display
|
@c FIXME: phony line break. Can probably be fixed by using an example
|
||||||
.stabs "name:sym_desc(struct tag) Type_def(16)=type_desc(struct type)
|
@c with fewer fields.
|
||||||
struct_bytes
|
|
||||||
elem_name:type_ref(int),bit_offset,field_bits;
|
|
||||||
elem_name:type_ref(float),bit_offset,field_bits;
|
|
||||||
elem_name:type_def(17)=type_desc(array)
|
|
||||||
index_type(range of int from 0 to 7);
|
|
||||||
element_type(char),bit_offset,field_bits;;",
|
|
||||||
N_LSYM,NIL,NIL,NIL
|
|
||||||
@end display
|
|
||||||
|
|
||||||
@example
|
@example
|
||||||
|
# @r{128 is N_LSYM}
|
||||||
.stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;
|
.stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;
|
||||||
s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0
|
s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0
|
||||||
@end example
|
@end example
|
||||||
@ -1800,11 +1758,11 @@ is specified by the type information (@pxref{String field}) for the stab.
|
|||||||
For example,
|
For example,
|
||||||
|
|
||||||
@example
|
@example
|
||||||
.stabs "s_typedef:t16",128,0,0,0
|
.stabs "s_typedef:t16",128,0,0,0 # @r{128 is N_LSYM}
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
specifies that @code{s_typedef} refers to type number 16. Such stabs
|
specifies that @code{s_typedef} refers to type number 16. Such stabs
|
||||||
have symbol type @code{N_LSYM} (or @code{C_DECL} on AIX).
|
have symbol type @code{N_LSYM} (or @code{C_DECL} for XCOFF).
|
||||||
|
|
||||||
If you are specifying the tag name for a structure, union, or
|
If you are specifying the tag name for a structure, union, or
|
||||||
enumeration, use the @samp{T} symbol descriptor instead. I believe C is
|
enumeration, use the @samp{T} symbol descriptor instead. I believe C is
|
||||||
@ -1845,16 +1803,10 @@ type @code{s_tag}. This is not true. The contents and position of the stab
|
|||||||
for @code{u_type} do not convey any infomation about its procedure local
|
for @code{u_type} do not convey any infomation about its procedure local
|
||||||
scope.
|
scope.
|
||||||
|
|
||||||
@display
|
@c FIXME: phony line break. Can probably be fixed by using an example
|
||||||
.stabs "name:sym_desc(union tag)type_def(22)=type_desc(union)
|
@c with fewer fields.
|
||||||
byte_size(4)
|
|
||||||
elem_name:type_ref(int),bit_offset(0),bit_size(32);
|
|
||||||
elem_name:type_ref(float),bit_offset(0),bit_size(32);
|
|
||||||
elem_name:type_ref(ptr to char),bit_offset(0),bit_size(32);;"
|
|
||||||
N_LSYM, NIL, NIL, NIL
|
|
||||||
@end display
|
|
||||||
|
|
||||||
@smallexample
|
@smallexample
|
||||||
|
# @r{128 is N_LSYM}
|
||||||
.stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;",
|
.stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;",
|
||||||
128,0,0,0
|
128,0,0,0
|
||||||
@end smallexample
|
@end smallexample
|
||||||
@ -1869,14 +1821,13 @@ union, number of bytes for the element;}.
|
|||||||
|
|
||||||
The stab for the union variable is:
|
The stab for the union variable is:
|
||||||
|
|
||||||
@display
|
|
||||||
.stabs "name:type_ref(u_tag)", N_LSYM, NIL, NIL, frame_ptr_offset
|
|
||||||
@end display
|
|
||||||
|
|
||||||
@example
|
@example
|
||||||
.stabs "an_u:23",128,0,0,-20
|
.stabs "an_u:23",128,0,0,-20 # @r{128 is N_LSYM}
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
|
@samp{-20} specifies where the variable is stored (@pxref{Stack
|
||||||
|
variables}).
|
||||||
|
|
||||||
@node Function types
|
@node Function types
|
||||||
@section Function types
|
@section Function types
|
||||||
|
|
||||||
@ -1894,14 +1845,15 @@ extensions to specify these, using the @samp{f}, @samp{F}, @samp{p}, and
|
|||||||
@samp{R} type descriptors.
|
@samp{R} type descriptors.
|
||||||
|
|
||||||
First comes the type descriptor. If it is @samp{f} or @samp{F}, this
|
First comes the type descriptor. If it is @samp{f} or @samp{F}, this
|
||||||
type involves a function, and the type information for the return type
|
type involves a function rather than a procedure, and the type
|
||||||
of the function follows, followed by a comma. Then comes the number of
|
information for the return type of the function follows, followed by a
|
||||||
parameters to the function and a semicolon. Then, for each parameter,
|
comma. Then comes the number of parameters to the function and a
|
||||||
there is the name of the parameter followed by a colon (this is only
|
semicolon. Then, for each parameter, there is the name of the parameter
|
||||||
present for type descriptors @samp{R} and @samp{F} which represent
|
followed by a colon (this is only present for type descriptors @samp{R}
|
||||||
Pascal function or procedure parameters), type information for the
|
and @samp{F} which represent Pascal function or procedure parameters),
|
||||||
parameter, a comma, 0 if passed by reference or 1 if passed by value,
|
type information for the parameter, a comma, 0 if passed by reference or
|
||||||
and a semicolon. The type definition ends with a semicolon.
|
1 if passed by value, and a semicolon. The type definition ends with a
|
||||||
|
semicolon.
|
||||||
|
|
||||||
For example, this variable definition:
|
For example, this variable definition:
|
||||||
|
|
||||||
@ -1977,9 +1929,11 @@ debugging information, unsorted. For stab entries the columns are:
|
|||||||
assembler and linker symbols, the columns are: @var{value}, @var{type},
|
assembler and linker symbols, the columns are: @var{value}, @var{type},
|
||||||
@var{string}.
|
@var{string}.
|
||||||
|
|
||||||
Where the @var{value} field of a stab contains a frame pointer offset,
|
The low 5 bits of the stab type tell the linker how to relocate the
|
||||||
or a register number, that @var{value} is unchanged by the rest of the
|
value of the stab. Thus for stab types like @code{N_RSYM} and
|
||||||
build.
|
@code{N_LSYM}, where the value is an offset or a register number, the
|
||||||
|
low 5 bits are @code{N_ABS}, which tells the linker not to relocate the
|
||||||
|
value.
|
||||||
|
|
||||||
Where the @var{value} field of a stab contains an assembly language label,
|
Where the @var{value} field of a stab contains an assembly language label,
|
||||||
it is transformed by each build step. The assembler turns it into a
|
it is transformed by each build step. The assembler turns it into a
|
||||||
@ -2800,7 +2754,7 @@ languages other than C.
|
|||||||
Global symbol; see @ref{Global variables}.
|
Global symbol; see @ref{Global variables}.
|
||||||
|
|
||||||
@item 0x22 N_FNAME
|
@item 0x22 N_FNAME
|
||||||
Function name (for BSD Fortran); see @ref{N_FNAME}.
|
Function name (for BSD Fortran); see @ref{Procedures}.
|
||||||
|
|
||||||
@item 0x24 N_FUN
|
@item 0x24 N_FUN
|
||||||
Function name (@pxref{Procedures}) or text segment variable
|
Function name (@pxref{Procedures}) or text segment variable
|
||||||
@ -2969,8 +2923,8 @@ Parameter passed by reference in register; see @ref{Reference parameters}.
|
|||||||
Constant; see @ref{Constants}.
|
Constant; see @ref{Constants}.
|
||||||
|
|
||||||
@item C
|
@item C
|
||||||
Conformant array bound (Pascal, maybe other languages); @ref{Reference
|
Conformant array bound (Pascal, maybe other languages); @ref{Conformant
|
||||||
parameters}. Name of a caught exception (GNU C++). These can be
|
arrays}. Name of a caught exception (GNU C++). These can be
|
||||||
distinguished because the latter uses @code{N_CATCH} and the former uses
|
distinguished because the latter uses @code{N_CATCH} and the former uses
|
||||||
another symbol type.
|
another symbol type.
|
||||||
|
|
||||||
@ -3209,7 +3163,6 @@ significant stab field. @samp{#} stands in for the type descriptor.
|
|||||||
Finally, any further information.
|
Finally, any further information.
|
||||||
|
|
||||||
@menu
|
@menu
|
||||||
* N_FNAME:: Function name (BSD Fortran)
|
|
||||||
* N_PC:: Pascal global symbol
|
* N_PC:: Pascal global symbol
|
||||||
* N_NSYMS:: Number of symbols
|
* N_NSYMS:: Number of symbols
|
||||||
* N_NOMAP:: No DST map
|
* N_NOMAP:: No DST map
|
||||||
@ -3226,21 +3179,6 @@ Finally, any further information.
|
|||||||
* N_LENG:: Length of preceding entry
|
* N_LENG:: Length of preceding entry
|
||||||
@end menu
|
@end menu
|
||||||
|
|
||||||
@node N_FNAME
|
|
||||||
@section N_FNAME
|
|
||||||
|
|
||||||
@deffn @code{.stabs} N_FNAME
|
|
||||||
@findex N_FNAME
|
|
||||||
Function name (for BSD Fortran).
|
|
||||||
|
|
||||||
@example
|
|
||||||
"name" -> "function_name"
|
|
||||||
@end example
|
|
||||||
|
|
||||||
Only the @var{string} field is significant. The location of the symbol is
|
|
||||||
obtained from the corresponding extern symbol.
|
|
||||||
@end deffn
|
|
||||||
|
|
||||||
@node N_PC
|
@node N_PC
|
||||||
@section N_PC
|
@section N_PC
|
||||||
|
|
||||||
@ -3528,11 +3466,11 @@ Mapping of a.out stab types to XCOFF storage classes:
|
|||||||
stab type storage class
|
stab type storage class
|
||||||
-------------------------------
|
-------------------------------
|
||||||
N_GSYM C_GSYM
|
N_GSYM C_GSYM
|
||||||
N_FNAME unknown
|
N_FNAME unused
|
||||||
N_FUN C_FUN
|
N_FUN C_FUN
|
||||||
N_STSYM C_STSYM
|
N_STSYM C_STSYM
|
||||||
N_LCSYM C_STSYM
|
N_LCSYM C_STSYM
|
||||||
N_MAIN unkown
|
N_MAIN unknown
|
||||||
N_PC unknown
|
N_PC unknown
|
||||||
N_RSYM C_RSYM
|
N_RSYM C_RSYM
|
||||||
unknown C_RPSYM
|
unknown C_RPSYM
|
||||||
|
Reference in New Issue
Block a user