Install infopages
This commit is contained in:
parent
dc16046f96
commit
eb9747a649
|
@ -0,0 +1 @@
|
|||
@set GDBVN 4.13
|
|
@ -1,340 +1,4 @@
|
|||
# This file was generated automatically by configure. Do not edit.
|
||||
VPATH = .
|
||||
links =
|
||||
host_alias = i386-unknown-freebsd
|
||||
host_cpu = i386
|
||||
host_vendor = unknown
|
||||
host_os = freebsd
|
||||
host_canonical = i386-unknown-freebsd
|
||||
target_alias = i386-unknown-freebsd
|
||||
target_cpu = i386
|
||||
target_vendor = unknown
|
||||
target_os = freebsd
|
||||
target_canonical = i386-unknown-freebsd
|
||||
##Copyright (C) 1991, 1992 Free Software Foundation, Inc.
|
||||
INFO = gdb gdbint stabs
|
||||
MAKEINFOFLAGS += -I ${.CURDIR}/../../../lib/libreadline/doc
|
||||
|
||||
# Makefile for GDB documentation.
|
||||
# This file is part of GDB.
|
||||
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2 of the License, or
|
||||
# (at your option) any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, write to the Free Software
|
||||
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
srcdir = .
|
||||
|
||||
prefix = /usr/gnu
|
||||
|
||||
infodir = $(prefix)/info
|
||||
|
||||
SHELL = /bin/sh
|
||||
|
||||
INSTALL = install -c
|
||||
INSTALL_PROGRAM = $(INSTALL)
|
||||
INSTALL_DATA = $(INSTALL)
|
||||
|
||||
# main GDB source directory
|
||||
gdbdir = $(srcdir)/..
|
||||
|
||||
# where to find texinfo; GDB dist should include a recent one
|
||||
TEXIDIR=${gdbdir}/../texinfo
|
||||
|
||||
# where to find makeinfo, preferably one designed for texinfo-2
|
||||
MAKEINFO=makeinfo
|
||||
|
||||
# where to find texi2roff, ditto
|
||||
TEXI2ROFF=texi2roff
|
||||
|
||||
# Where is the source dir for the READLINE library doc?
|
||||
# Traditionally readline is in .. or .
|
||||
READLINE_DIR = ${gdbdir}/../readline/doc
|
||||
|
||||
SET_TEXINPUTS = TEXINPUTS=${TEXIDIR}:.:$(srcdir):$(READLINE_DIR):$$TEXINPUTS
|
||||
|
||||
# There may be alternate predefined collections of switches to configure
|
||||
# the GDB manual. Normally this is not done in synch with the software
|
||||
# config system, since this choice tends to be independent; most people
|
||||
# want a doc config of `all' for a generic manual, regardless of sw config.
|
||||
DOC_CONFIG = all
|
||||
|
||||
# This list of sed edits will edit the GDB reference card
|
||||
# for what fonts and what papersize to use.
|
||||
# By default (NO edits applied), the refcard uses:
|
||||
# - Computer Modern (CM) fonts
|
||||
# - US letter paper (8.5x11in)
|
||||
# List some of the following files for alternative fonts and paper:
|
||||
# a4rc.sed use A4 paper (297 x 210 mm)
|
||||
# psrc.sed use PostScript fonts (Karl Berry short TeX names)
|
||||
# lpsrc.sed use PostScript fonts (full PostScript names in TeX)
|
||||
# e.g. for A4, Postscript: REFEDITS = a4rc.sed psrc.sed
|
||||
# for A4, CM fonts: REFEDITS = a4rc.sed
|
||||
# for US, PS fonts: REFEDITS = psrc.sed
|
||||
# for default:
|
||||
REFEDITS =
|
||||
|
||||
# Don Knuth's TeX formatter
|
||||
TEX = tex
|
||||
|
||||
# auxiliary program for sorting Texinfo indices
|
||||
TEXINDEX = texindex
|
||||
|
||||
# Main GDB manual's source files
|
||||
SFILES_INCLUDED = gdb-cfg.texi $(srcdir)/remote.texi
|
||||
|
||||
SFILES_LOCAL = $(srcdir)/gdb.texinfo GDBvn.texi $(SFILES_INCLUDED)
|
||||
|
||||
SFILES_DOC = $(SFILES_LOCAL) \
|
||||
$(READLINE_DIR)/rluser.texinfo $(READLINE_DIR)/inc-hist.texi
|
||||
|
||||
#### Host, target, and site specific Makefile fragments come in here.
|
||||
###
|
||||
|
||||
all install:
|
||||
|
||||
info: gdb.info gdbint.info stabs.info
|
||||
dvi: gdb.dvi refcard.dvi gdbint.dvi
|
||||
all-doc: gdb.info gdb.dvi refcard.dvi gdb-internals gdbint.dvi
|
||||
|
||||
install-info: info
|
||||
for i in *.info* ; do \
|
||||
$(INSTALL_DATA) $$i $(infodir)/$$i ; \
|
||||
done
|
||||
|
||||
STAGESTUFF = *.info* gdb-all.texi GDBvn.texi
|
||||
|
||||
# Copy the object files from a particular stage into a subdirectory.
|
||||
stage1: force
|
||||
-mkdir stage1
|
||||
-mv $(STAGESTUFF) stage1
|
||||
|
||||
stage2: force
|
||||
-mkdir stage2
|
||||
-mv $(STAGESTUFF) stage2
|
||||
|
||||
stage3: force
|
||||
-mkdir stage3
|
||||
-mv $(STAGESTUFF) stage3
|
||||
|
||||
against=stage2
|
||||
|
||||
comparison: force
|
||||
for i in $(STAGESTUFF) ; do cmp $$i $(against)/$$i ; done
|
||||
|
||||
de-stage1: force
|
||||
-(cd stage1 ; mv -f * ..)
|
||||
-rmdir stage1
|
||||
|
||||
de-stage2: force
|
||||
-(cd stage2 ; mv -f * ..)
|
||||
-rmdir stage2
|
||||
|
||||
de-stage3: force
|
||||
-(cd stage3 ; mv -f * ..)
|
||||
-rmdir stage3
|
||||
|
||||
clean-info:
|
||||
rm -f gdb.info* gdbint.info* stabs.info*
|
||||
|
||||
clean-dvi:
|
||||
rm -f gdb.dvi refcard.dvi gdbint.dvi stabs.dvi sedref.dvi
|
||||
|
||||
mostlyclean: clean-info clean-dvi
|
||||
rm -f gdb.?? gdb.??? gdb.mm gdb.ms gdb.me
|
||||
rm -f links2roff
|
||||
rm -f refcard.ps lrefcard.ps refcard.log sedref.* *~
|
||||
rm -f gdbint.?? gdbint.??? stabs.?? stabs.???
|
||||
|
||||
clean: mostlyclean
|
||||
rm -f GDBvn.texi rluser.texinfo inc-hist.texi
|
||||
|
||||
distclean: clean
|
||||
rm -f Makefile config.status
|
||||
|
||||
realclean: distclean clean-dvi clean-info
|
||||
|
||||
# GDB QUICK REFERENCE (dvi output)
|
||||
refcard.dvi : refcard.tex $(REFEDITS)
|
||||
if [ -z "$(REFEDITS)" ]; then \
|
||||
cp $(srcdir)/refcard.tex sedref.tex ; \
|
||||
else \
|
||||
echo > tmp.sed ; \
|
||||
for f in "$(REFEDITS)" ; do \
|
||||
cat $(srcdir)/$$f >>tmp.sed ; done ; \
|
||||
sed -f tmp.sed $(srcdir)/refcard.tex >sedref.tex ; \
|
||||
fi
|
||||
$(SET_TEXINPUTS) $(TEX) sedref.tex
|
||||
mv sedref.dvi refcard.dvi
|
||||
rm -f sedref.log sedref.tex tmp.sed
|
||||
|
||||
refcard.ps : refcard.dvi
|
||||
dvips -t landscape refcard.dvi -o
|
||||
|
||||
# File to record current GDB version number (copied from main dir Makefile.in)
|
||||
GDBvn.texi : ${gdbdir}/Makefile.in
|
||||
echo "@set GDBVN `sed <$(srcdir)/../Makefile.in -n 's/VERSION = //p'`" > ./GDBvn.new
|
||||
mv GDBvn.new GDBvn.texi
|
||||
|
||||
# Updated atomically
|
||||
.PRECIOUS: GDBvn.texi
|
||||
|
||||
# Choose configuration for GDB manual (normally `all'; normally not tied into
|
||||
# `configure' script because most users prefer generic version of manual,
|
||||
# not one for their binary config---which may not be specifically
|
||||
# defined anyways).
|
||||
gdb-cfg.texi: ${srcdir}/${DOC_CONFIG}-cfg.texi
|
||||
ln -s ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi || \
|
||||
ln ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi || \
|
||||
cp ${srcdir}/${DOC_CONFIG}-cfg.texi gdb-cfg.texi
|
||||
|
||||
# GDB MANUAL: texinfo source, using @set/@clear/@value/@ifset/@ifclear
|
||||
# If your texinfo or makeinfo don't support these, get a new texinfo release
|
||||
#
|
||||
# The nonsense with GDBvn.texi gets this to run with both Sun and GNU make.
|
||||
# Note that we can *generate* GDBvn.texi, but since we distribute one in the
|
||||
# source directory for the benefit of people who *don't* use this makefile,
|
||||
# VPATH will often tell make not to bother building it, because the one
|
||||
# in the srcdir is up to date. (if not, then make should build one here).
|
||||
|
||||
# GDB MANUAL: TeX dvi file
|
||||
gdb.dvi: ${SFILES_DOC}
|
||||
if [ ! -f ./GDBvn.texi ]; then \
|
||||
ln -s $(srcdir)/GDBvn.texi . || \
|
||||
ln $(srcdir)/GDBvn.texi . || \
|
||||
cp $(srcdir)/GDBvn.texi . ; else true; fi
|
||||
$(SET_TEXINPUTS) $(TEX) gdb.texinfo
|
||||
$(SET_TEXINPUTS) $(TEX) gdb.texinfo
|
||||
$(TEXINDEX) gdb.??
|
||||
$(SET_TEXINPUTS) $(TEX) gdb.texinfo
|
||||
rm -f gdb.?? gdb.log gdb.aux gdb.toc gdb.??s
|
||||
|
||||
# GDB MANUAL: info file
|
||||
# We're using texinfo2, and older makeinfo's may not be able to
|
||||
# cope with all the markup.
|
||||
gdb.info: ${SFILES_DOC}
|
||||
$(MAKEINFO) -I ${READLINE_DIR} -I $(srcdir) -o ./gdb.info gdb.texinfo
|
||||
|
||||
# GDB MANUAL: roff translations
|
||||
# Try to use a recent texi2roff. v2 was put on prep in jan91.
|
||||
# If you want an index, see texi2roff doc for postprocessing
|
||||
# and add -i to texi2roff invocations below.
|
||||
# Workarounds for texi2roff-2 (probably fixed in later texi2roff's, delete
|
||||
# corresponding -e lines when later texi2roff's are current)
|
||||
# + @ifinfo's deleted explicitly due to texi2roff-2 bug w nested constructs.
|
||||
# + @c's deleted explicitly because texi2roff sees texinfo commands in them
|
||||
# + @ (that's at-BLANK) not recognized by texi2roff, turned into blank
|
||||
# + @alphaenumerate is ridiculously new, turned into @enumerate
|
||||
|
||||
# texi2roff doesn't have a notion of include dirs, so we have to fake
|
||||
# it out for gdb manual's include files---but only if not configured
|
||||
# in main sourcedir.
|
||||
links2roff: $(SFILES_INCLUDED)
|
||||
if [ ! -f gdb.texinfo ]; then \
|
||||
ln -s $(SFILES_INCLUDED) . || \
|
||||
ln $(SFILES_INCLUDED) . || \
|
||||
cp $(SFILES_INCLUDED) . ; \
|
||||
fi
|
||||
touch links2roff
|
||||
|
||||
# "Readline" appendices. Get them also due to lack of includes,
|
||||
# regardless of whether or not configuring in main sourcedir.
|
||||
# @ftable removed due to bug in texi2roff-2; if your texi2roff
|
||||
# is newer, try just ln or cp
|
||||
rluser.texinfo: ${READLINE_DIR}/rluser.texinfo
|
||||
sed -e 's/^@ftable/@table/g' \
|
||||
-e 's/^@end ftable/@end table/g' \
|
||||
${READLINE_DIR}/rluser.texinfo > ./rluser.texinfo
|
||||
|
||||
inc-hist.texi: ${READLINE_DIR}/inc-hist.texi
|
||||
ln -s ${READLINE_DIR}/inc-hist.texi . || \
|
||||
ln ${READLINE_DIR}/inc-hist.texi . || \
|
||||
cp ${READLINE_DIR}/inc-hist.texi .
|
||||
|
||||
# gdb manual suitable for [gtn]roff -me
|
||||
gdb.me: $(SFILES_LOCAL) links2roff rluser.texinfo inc-hist.texi
|
||||
sed -e '/\\input texinfo/d' \
|
||||
-e '/@c TEXI2ROFF-KILL/,/@c END TEXI2ROFF-KILL/d' \
|
||||
-e '/^@ifinfo/,/^@end ifinfo/d' \
|
||||
-e '/^@c /d' \
|
||||
-e 's/{.*,,/{/' \
|
||||
-e 's/@ / /g' \
|
||||
-e 's/^@alphaenumerate/@enumerate/g' \
|
||||
-e 's/^@end alphaenumerate/@end enumerate/g' \
|
||||
$(srcdir)/gdb.texinfo | \
|
||||
$(TEXI2ROFF) -me | \
|
||||
sed -e 's/---/\\(em/g' \
|
||||
>gdb.me
|
||||
|
||||
# gdb manual suitable for [gtn]roff -ms
|
||||
gdb.ms: $(SFILES_LOCAL) links2roff rluser.texinfo inc-hist.texi
|
||||
sed -e '/\\input texinfo/d' \
|
||||
-e '/@c TEXI2ROFF-KILL/,/@c END TEXI2ROFF-KILL/d' \
|
||||
-e '/^@ifinfo/,/^@end ifinfo/d' \
|
||||
-e '/^@c /d' \
|
||||
-e 's/{.*,,/{/' \
|
||||
-e 's/@ / /g' \
|
||||
-e 's/^@alphaenumerate/@enumerate/g' \
|
||||
-e 's/^@end alphaenumerate/@end enumerate/g' \
|
||||
$(srcdir)/gdb.texinfo | \
|
||||
$(TEXI2ROFF) -ms | \
|
||||
sed -e 's/---/\\(em/g' \
|
||||
>gdb.ms
|
||||
|
||||
# gdb manual suitable for [tn]roff -mm
|
||||
# '@noindent's removed due to texi2roff-2 mm bug; if yours is newer,
|
||||
# try leaving them in
|
||||
gdb.mm: $(SFILES_LOCAL) links2roff rluser.texinfo inc-hist.texi
|
||||
sed -e '/\\input texinfo/d' \
|
||||
-e '/@c TEXI2ROFF-KILL/,/@c END TEXI2ROFF-KILL/d' \
|
||||
-e '/^@ifinfo/,/^@end ifinfo/d' \
|
||||
-e '/^@c /d' \
|
||||
-e 's/{.*,,/{/' \
|
||||
-e '/@noindent/d' \
|
||||
-e 's/@ / /g' \
|
||||
-e 's/^@alphaenumerate/@enumerate/g' \
|
||||
-e 's/^@end alphaenumerate/@end enumerate/g' \
|
||||
$(srcdir)/gdb.texinfo | \
|
||||
$(TEXI2ROFF) -mm | \
|
||||
sed -e 's/---/\\(em/g' \
|
||||
>gdb.mm
|
||||
|
||||
# GDB INTERNALS MANUAL: TeX dvi file
|
||||
gdbint.dvi : gdbint.texinfo
|
||||
$(SET_TEXINPUTS) $(TEX) gdbint.texinfo
|
||||
$(TEXINDEX) gdbint.??
|
||||
$(SET_TEXINPUTS) $(TEX) gdbint.texinfo
|
||||
rm -f gdbint.?? gdbint.aux gdbint.cps gdbint.fns gdbint.kys \
|
||||
gdbint.log gdbint.pgs gdbint.toc gdbint.tps gdbint.vrs
|
||||
|
||||
# GDB INTERNALS MANUAL: info file
|
||||
gdb-internals: gdbint.info
|
||||
|
||||
gdbint.info: gdbint.texinfo
|
||||
$(MAKEINFO) -o gdbint.info $(srcdir)/gdbint.texinfo
|
||||
|
||||
stabs.info: stabs.texinfo
|
||||
$(MAKEINFO) -o stabs.info $(srcdir)/stabs.texinfo
|
||||
|
||||
# STABS DOCUMENTATION: TeX dvi file
|
||||
stabs.dvi : stabs.texinfo
|
||||
$(SET_TEXINPUTS) $(TEX) stabs.texinfo
|
||||
$(TEXINDEX) stabs.??
|
||||
$(SET_TEXINPUTS) $(TEX) stabs.texinfo
|
||||
rm -f stabs.?? stabs.aux stabs.cps stabs.fns stabs.kys \
|
||||
stabs.log stabs.pgs stabs.toc stabs.tps stabs.vrs
|
||||
|
||||
stabs.ps: stabs.dvi
|
||||
dvips -o stabs.ps stabs
|
||||
|
||||
force:
|
||||
|
||||
Makefile: $(srcdir)/Makefile.in $(host_makefile_frag) $(target_makefile_frag)
|
||||
$(SHELL) ./config.status
|
||||
.include <bsd.info.mk>
|
||||
|
|
|
@ -0,0 +1,708 @@
|
|||
\input texinfo @c -*-texinfo-*-
|
||||
@c %**start of header
|
||||
@setfilename annotate.info
|
||||
@settitle GDB Annotations
|
||||
@setchapternewpage off
|
||||
@c %**end of header
|
||||
|
||||
@set EDITION 0.5
|
||||
@set DATE May 1994
|
||||
|
||||
@ifinfo
|
||||
This file documents GDB annotations.
|
||||
|
||||
This is Edition @value{EDITION}, @value{DATE}, of @cite{GDB
|
||||
Annotations}. Copyright 1994 Free Software Foundation
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
are preserved on all copies.
|
||||
|
||||
@ignore
|
||||
Permission is granted to process this file through TeX and print the
|
||||
results, provided the printed document carries copying permission
|
||||
notice identical to this one except for the removal of this paragraph
|
||||
(this paragraph not being relevant to the printed manual).
|
||||
|
||||
@end ignore
|
||||
Permission is granted to copy and distribute modified versions of this
|
||||
manual under the conditions for verbatim copying, provided also that the
|
||||
entire resulting derived work is distributed under the terms of a
|
||||
permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this manual
|
||||
into another language, under the above conditions for modified versions.
|
||||
@end ifinfo
|
||||
|
||||
@titlepage
|
||||
@title GDB Annotations
|
||||
@subtitle Edition @value{EDITION}
|
||||
@subtitle @value{DATE}
|
||||
@author Cygnus Support
|
||||
@page
|
||||
@vskip 0pt plus 1filll
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
are preserved on all copies.
|
||||
|
||||
Copyright @copyright{} 1994 Free Software Foundation
|
||||
@end titlepage
|
||||
|
||||
@ifinfo
|
||||
@node Top
|
||||
@top GDB Annotations
|
||||
|
||||
This file describes annotations in GDB, the GNU symbolic debugger.
|
||||
Annotations are designed to interface GDB to graphical user interfaces
|
||||
or other similar programs which want to interact with GDB at a
|
||||
relatively high level.
|
||||
|
||||
This is Edition @value{EDITION}, @value{DATE}.
|
||||
|
||||
@menu
|
||||
* General:: What annotations are; the general syntax.
|
||||
* Server:: Issuing a command without affecting user state.
|
||||
* Values:: Values are marked as such.
|
||||
* Frames:: Stack frames are annotated.
|
||||
* Displays:: GDB can be told to display something periodically.
|
||||
* Prompting:: Annotations marking GDB's need for input.
|
||||
* Errors:: Annotations for error messages.
|
||||
* Breakpoint Info:: Information on breakpoints.
|
||||
* Invalidation:: Some annotations describe things now invalid.
|
||||
* Running:: Whether the program is running, how it stopped, etc.
|
||||
* Source:: Annotations describing source code.
|
||||
* TODO:: Annotations which might be added in the future.
|
||||
* Index:: Index
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
@node General
|
||||
@chapter What is an Annotation?
|
||||
|
||||
To produce annotations, start GDB with the @code{--annotate=2} option.
|
||||
|
||||
Annotations start with a newline character, two @samp{control-z}
|
||||
characters, and the name of the annotation. If there is no additional
|
||||
information associated with this annotation, the name of the annotation
|
||||
is followed immediately by a newline. If there is additional
|
||||
information, the name of the annotation is followed by a space, the
|
||||
additional information, and a newline. The additional information
|
||||
cannot contain newline characters.
|
||||
|
||||
Any output not beginning with a newline and two @samp{control-z}
|
||||
characters denotes literal output from GDB. Currently there is no need
|
||||
for GDB to output a newline followed by two @samp{control-z} characters,
|
||||
but if there was such a need, the annotations could be extended with an
|
||||
@samp{escape} annotation which means those three characters as output.
|
||||
|
||||
A simple example of starting up GDB with annotations is:
|
||||
|
||||
@example
|
||||
$ gdb --annotate=2
|
||||
GDB is free software and you are welcome to distribute copies of it
|
||||
under certain conditions; type "show copying" to see the conditions.
|
||||
There is absolutely no warranty for GDB; type "show warranty" for details.
|
||||
GDB 4.12.3 (sparc-sun-sunos4.1.3),
|
||||
Copyright 1994 Free Software Foundation, Inc.
|
||||
|
||||
^Z^Zpre-prompt
|
||||
(gdb)
|
||||
^Z^Zprompt
|
||||
quit
|
||||
|
||||
^Z^Zpost-prompt
|
||||
$
|
||||
@end example
|
||||
|
||||
Here @samp{quit} is input to GDB; the rest is output from GDB. The three
|
||||
lines beginning @samp{^Z^Z} (where @samp{^Z} denotes a @samp{control-z}
|
||||
character) are annotations; the rest is output from GDB.
|
||||
|
||||
@node Server
|
||||
@chapter The Server Prefix
|
||||
|
||||
To issue a command to GDB without affecting certain aspects of the state
|
||||
which is seen by users, prefix it with @samp{server }. This means that
|
||||
this command will not affect the command history, nor will it affect
|
||||
GDB's notion of which command to repeat if @key{RET} is pressed on a
|
||||
line by itself.
|
||||
|
||||
The server prefix does not affect the recording of values into the value
|
||||
history; to print a value without recording it into the value history,
|
||||
use the @code{output} command instead of the @code{print} command.
|
||||
|
||||
@node Values
|
||||
@chapter Values
|
||||
|
||||
When a value is printed in various contexts, GDB uses annotations to
|
||||
delimit the value from the surrounding text.
|
||||
|
||||
@findex value-history-begin
|
||||
@findex value-history-value
|
||||
@findex value-history-end
|
||||
If a value is printed using @code{print} and added to the value history,
|
||||
the annotation looks like
|
||||
|
||||
@example
|
||||
^Z^Zvalue-history-begin @var{history-number} @var{value-flags}
|
||||
@var{history-string}
|
||||
^Z^Zvalue-history-value
|
||||
@var{the-value}
|
||||
^Z^Zvalue-history-end
|
||||
@end example
|
||||
|
||||
where @var{history-number} is the number it is getting in the value
|
||||
history, @var{history-string} is a string, such as @samp{$5 = }, which
|
||||
introduces the value to the user, @var{the-value} is the output
|
||||
corresponding to the value itself, and @var{value-flags} is @samp{*} for
|
||||
a value which can be dereferenced and @samp{-} for a value which cannot.
|
||||
|
||||
@findex value-begin
|
||||
@findex value-end
|
||||
If the value is not added to the value history (it is an invalid float
|
||||
or it is printed with the @code{output} command), the annotation is similar:
|
||||
|
||||
@example
|
||||
^Z^Zvalue-begin @var{value-flags}
|
||||
@var{the-value}
|
||||
^Z^Zvalue-end
|
||||
@end example
|
||||
|
||||
@findex arg-begin
|
||||
@findex arg-name-end
|
||||
@findex arg-value
|
||||
@findex arg-end
|
||||
When GDB prints an argument to a function (for example, in the output
|
||||
from the @code{backtrace} command), it annotates it as follows:
|
||||
|
||||
@example
|
||||
^Z^Zarg-begin
|
||||
@var{argument-name}
|
||||
^Z^Zarg-name-end
|
||||
@var{separator-string}
|
||||
^Z^Zarg-value @var{value-flags}
|
||||
@var{the-value}
|
||||
^Z^Zarg-end
|
||||
@end example
|
||||
|
||||
where @var{argument-name} is the name of the argument,
|
||||
@var{separator-string} is text which separates the name from the value
|
||||
for the user's benefit (such as @samp{=}), and @var{value-flags} and
|
||||
@var{the-value} have the same meanings as in a
|
||||
@code{value-history-begin} annotation.
|
||||
|
||||
@findex field-begin
|
||||
@findex field-name-end
|
||||
@findex field-value
|
||||
@findex field-end
|
||||
When printing a structure, GDB annotates it as follows:
|
||||
|
||||
@example
|
||||
^Z^Zfield-begin @var{value-flags}
|
||||
@var{field-name}
|
||||
^Z^Zfield-name-end
|
||||
@var{separator-string}
|
||||
^Z^Zfield-value
|
||||
@var{the-value}
|
||||
^Z^Zfield-end
|
||||
@end example
|
||||
|
||||
where @var{field-name} is the name of the field, @var{separator-string}
|
||||
is text which separates the name from the value for the user's benefit
|
||||
(such as @samp{=}), and @var{value-flags} and @var{the-value} have the
|
||||
same meanings as in a @code{value-history-begin} annotation.
|
||||
|
||||
When printing an array, GDB annotates it as follows:
|
||||
|
||||
@example
|
||||
^Z^Zarray-section-begin @var{array-index} @var{value-flags}
|
||||
@end example
|
||||
|
||||
where @var{array-index} is the index of the first element being
|
||||
annotated and @var{value-flags} has the same meaning as in a
|
||||
@code{value-history-begin} annotation. This is followed by any number
|
||||
of elements, where is element can be either a single element:
|
||||
|
||||
@findex elt
|
||||
@example
|
||||
@samp{,} @var{whitespace} ; @r{omitted for the first element}
|
||||
@var{the-value}
|
||||
^Z^Zelt
|
||||
@end example
|
||||
|
||||
or a repeated element
|
||||
|
||||
@findex elt-rep
|
||||
@findex elt-rep-end
|
||||
@example
|
||||
@samp{,} @var{whitespace} ; @r{omitted for the first element}
|
||||
@var{the-value}
|
||||
^Z^Zelt-rep @var{number-of-repititions}
|
||||
@var{repetition-string}
|
||||
^Z^Zelt-rep-end
|
||||
@end example
|
||||
|
||||
In both cases, @var{the-value} is the output for the value of the
|
||||
element and @var{whitespace} can contain spaces, tabs, and newlines. In
|
||||
the repeated case, @var{number-of-repititons} is the number of
|
||||
consecutive array elements which contain that value, and
|
||||
@var{repetition-string} is a string which is designed to convey to the
|
||||
user that repitition is being depicted.
|
||||
|
||||
@findex array-section-end
|
||||
Once all the array elements have been output, the array annotation is
|
||||
ended with
|
||||
|
||||
@example
|
||||
^Z^Zarray-section-end
|
||||
@end example
|
||||
|
||||
@node Frames
|
||||
@chapter Frames
|
||||
|
||||
Whenever GDB prints a frame, it annotates it. For example, this applies
|
||||
to frames printed when GDB stops, output from commands such as
|
||||
@code{backtrace} or @code{up}, etc.
|
||||
|
||||
@findex frame-begin
|
||||
The frame annotation begins with
|
||||
|
||||
@example
|
||||
^Z^Zframe-begin @var{level} @var{address}
|
||||
@var{level-string}
|
||||
@end example
|
||||
|
||||
where @var{level} is the number of the frame (0 is the innermost frame,
|
||||
and other frames have positive numbers), @var{address} is the address of
|
||||
the code executing in that frame, and @var{level-string} is a string
|
||||
designed to convey the level to the user. The frame ends with
|
||||
|
||||
@findex frame-end
|
||||
@example
|
||||
^Z^Zframe-end
|
||||
@end example
|
||||
|
||||
Between these annotations is the main body of the frame, which can
|
||||
consist of
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
@findex function-call
|
||||
@example
|
||||
^Z^Zfunction-call
|
||||
@var{function-call-string}
|
||||
@end example
|
||||
|
||||
where @var{function-call-string} is text designed to convey to the user
|
||||
that this frame is associated with a function call made by GDB to a
|
||||
function in the program being debugged.
|
||||
|
||||
@item
|
||||
@findex signal-handler-caller
|
||||
@example
|
||||
^Z^Zsignal-handler-caller
|
||||
@var{signal-handler-caller-string}
|
||||
@end example
|
||||
|
||||
where @var{signal-handler-caller-string} is text designed to convey to
|
||||
the user that this frame is associated with whatever mechanism is used
|
||||
by this operating system to call a signal handler (it is the frame which
|
||||
calls the signal handler, not the frame for the signal handler itself).
|
||||
|
||||
@item
|
||||
A normal frame.
|
||||
|
||||
@findex frame-address
|
||||
@findex frame-address-end
|
||||
This can optionally (depending on whether this is thought of as
|
||||
interesting information for the user to see) begin with
|
||||
|
||||
@example
|
||||
^Z^Zframe-address
|
||||
@var{address}
|
||||
^Z^Zframe-address-end
|
||||
@var{separator-string}
|
||||
@end example
|
||||
|
||||
where @var{address} is the address executing in the frame (the same
|
||||
address as in the @code{frame-begin} annotation), and
|
||||
@var{separator-string} is a string intended to separate this address
|
||||
from what follows for the user's benefit.
|
||||
|
||||
@findex frame-function-name
|
||||
@findex frame-args
|
||||
Then comes
|
||||
|
||||
@example
|
||||
^Z^Zframe-function-name
|
||||
@var{function-name}
|
||||
^Z^Zframe-args
|
||||
@var{arguments}
|
||||
@end example
|
||||
|
||||
where @var{function-name} is the name of the function executing in the
|
||||
frame, or @samp{??} if not known, and @var{arguments} are the arguments
|
||||
to the frame, with parentheses around them (each argument is annotated
|
||||
individually as well @pxref{Values}).
|
||||
|
||||
@findex frame-source-begin
|
||||
@findex frame-source-file
|
||||
@findex frame-source-file-end
|
||||
@findex frame-source-line
|
||||
@findex frame-source-end
|
||||
If source information is available, a reference to it is then printed:
|
||||
|
||||
@example
|
||||
^Z^Zframe-source-begin
|
||||
@var{source-intro-string}
|
||||
^Z^Zframe-source-file
|
||||
@var{filename}
|
||||
^Z^Zframe-source-file-end
|
||||
:
|
||||
^Z^Zframe-source-line
|
||||
@var{line-number}
|
||||
^Z^Zframe-source-end
|
||||
@end example
|
||||
|
||||
where @var{source-intro-string} separates for the user's benefit the
|
||||
reference from the text which precedes it, @var{filename} is the name of
|
||||
the source file, and @var{line-number} is the line number within that
|
||||
file (the first line is line 1).
|
||||
|
||||
@findex frame-where
|
||||
If GDB prints some information about where the frame is from (which
|
||||
library, which load segment, etc.; currently only done on the RS/6000),
|
||||
it is annotated with
|
||||
|
||||
@example
|
||||
^Z^Zframe-where
|
||||
@var{information}
|
||||
@end example
|
||||
|
||||
Then, if source is to actually be displayed for this frame (for example,
|
||||
this is not true for output from the @code{backtrace} command), then a
|
||||
@code{source} annotation (@pxref{Source}) is displayed. Unlike most
|
||||
annotations, this is output instead of the normal text which would be
|
||||
output, not in addition.
|
||||
@end itemize
|
||||
|
||||
@node Displays
|
||||
@chapter Displays
|
||||
|
||||
@findex display-begin
|
||||
@findex display-number-end
|
||||
@findex display-format
|
||||
@findex display-expression
|
||||
@findex display-expression-end
|
||||
@findex display-value
|
||||
@findex display-end
|
||||
When GDB is told to display something using the @code{display} command,
|
||||
the results of the display are annotated:
|
||||
|
||||
@example
|
||||
^Z^Zdisplay-begin
|
||||
@var{number}
|
||||
^Z^Zdisplay-number-end
|
||||
@var{number-separator}
|
||||
^Z^Zdisplay-format
|
||||
@var{format}
|
||||
^Z^Zdisplay-expression
|
||||
@var{expression}
|
||||
^Z^Zdisplay-expression-end
|
||||
@var{expression-separator}
|
||||
^Z^Zdisplay-value
|
||||
@var{value}
|
||||
^Z^Zdisplay-end
|
||||
@end example
|
||||
|
||||
where @var{number} is the number of the display, @var{number-separator}
|
||||
is intended to separate the number from what follows for the user,
|
||||
@var{format} includes information such as the size, format, or other
|
||||
information about how the value is being displayed, @var{expression} is
|
||||
the expression being displayed, @var{expression-separator} is intended
|
||||
to separate the expression from the text that follows for the user,
|
||||
and @var{value} is the actual value being displayed.
|
||||
|
||||
@node Prompting
|
||||
@chapter Annotation for GDB Input
|
||||
|
||||
When GDB prompts for input, it annotates this fact so it is possible
|
||||
to know when to send output, when the output from a given command is
|
||||
over, etc.
|
||||
|
||||
Different kinds of input each have a different @dfn{input type}. Each
|
||||
input type has three annotations: a @code{pre-} annotation, which
|
||||
denotes the beginning of any prompt which is being output, a plain
|
||||
annotation, which denotes the end of the prompt, and then a @code{post-}
|
||||
annotation which denotes the end of any echo which may (or may not) be
|
||||
associated with the input. For example, the @code{prompt} input type
|
||||
features the following annotations:
|
||||
|
||||
@example
|
||||
^Z^Zpre-prompt
|
||||
^Z^Zprompt
|
||||
^Z^Zpost-prompt
|
||||
@end example
|
||||
|
||||
The input types are
|
||||
|
||||
@table @code
|
||||
@findex pre-prompt
|
||||
@findex prompt
|
||||
@findex post-prompt
|
||||
@item prompt
|
||||
When GDB is prompting for a command (the main GDB prompt).
|
||||
|
||||
@findex pre-commands
|
||||
@findex commands
|
||||
@findex post-commands
|
||||
@item commands
|
||||
When GDB prompts for a set of commands, like in the @code{commands}
|
||||
command. The annotations are repeated for each command which is input.
|
||||
|
||||
@findex pre-overload-choice
|
||||
@findex overload-choice
|
||||
@findex post-overload-choice
|
||||
@item overload-choice
|
||||
When GDB wants the user to select between various overloaded functions.
|
||||
|
||||
@findex pre-query
|
||||
@findex query
|
||||
@findex post-query
|
||||
@item query
|
||||
When GDB wants the user to confirm a potentially dangerous operation.
|
||||
|
||||
@findex pre-prompt-for-continue
|
||||
@findex prompt-for-continue
|
||||
@findex post-prompt-for-continue
|
||||
@item prompt-for-continue
|
||||
When GDB is asking the user to press return to continue. Note: Don't
|
||||
expect this to work well; instead use @code{set height 0} to disable
|
||||
prompting. This is because the counting of lines is buggy in the
|
||||
presence of annotations.
|
||||
@end table
|
||||
|
||||
@node Errors
|
||||
@chapter Errors
|
||||
|
||||
@findex quit
|
||||
@example
|
||||
^Z^Zquit
|
||||
@end example
|
||||
|
||||
This annotation occurs right before GDB responds to an interrupt.
|
||||
|
||||
@findex error
|
||||
@example
|
||||
^Z^Zerror
|
||||
@end example
|
||||
|
||||
This annotation occurs right before GDB responds to an error.
|
||||
|
||||
Quit and error annotations indicate that any annotations which GDB was
|
||||
in the middle of may end abruptly. For example, if a
|
||||
@code{value-history-begin} annotation is followed by a @code{error}, one
|
||||
cannot expect to receive the matching @code{value-history-end}. One
|
||||
cannot expect not to receive it either, however; an error annotation
|
||||
does not necessarily mean that GDB is immediately returning all the way
|
||||
to the top level.
|
||||
|
||||
@findex error-begin
|
||||
A quit or error annotation may be preceded by
|
||||
|
||||
@example
|
||||
^Z^Zerror-begin
|
||||
@end example
|
||||
|
||||
Any output between that and the quit or error annotation is the error
|
||||
message.
|
||||
|
||||
Warning messages are not yet annotated.
|
||||
@c If we want to change that, need to fix warning(), type_error(),
|
||||
@c range_error(), and possibly other places.
|
||||
|
||||
@node Breakpoint Info
|
||||
@chapter Information on Breakpoints
|
||||
|
||||
The output from the @code{info breakpoints} command is annotated as follows:
|
||||
|
||||
@findex breakpoints-headers
|
||||
@findex breakpoints-table
|
||||
@example
|
||||
^Z^Zbreakpoints-headers
|
||||
@var{header-entry}
|
||||
^Z^Zbreakpoints-table
|
||||
@end example
|
||||
|
||||
where @var{header-entry} has the same syntax as an entry (see below) but
|
||||
instead of containing data, it contains strings which are intended to
|
||||
convey the meaning of each field to the user. This is followed by any
|
||||
number of entries. If a field does not apply for this entry, it is
|
||||
omitted. Fields may contain trailing whitespace. Each entry consists
|
||||
of:
|
||||
|
||||
@findex record
|
||||
@findex field
|
||||
@example
|
||||
^Z^Zrecord
|
||||
^Z^Zfield 0
|
||||
@var{number}
|
||||
^Z^Zfield 1
|
||||
@var{type}
|
||||
^Z^Zfield 2
|
||||
@var{disposition}
|
||||
^Z^Zfield 3
|
||||
@var{enable}
|
||||
^Z^Zfield 4
|
||||
@var{address}
|
||||
^Z^Zfield 5
|
||||
@var{what}
|
||||
^Z^Zfield 6
|
||||
@var{frame}
|
||||
^Z^Zfield 7
|
||||
@var{condition}
|
||||
^Z^Zfield 8
|
||||
@var{ignore-count}
|
||||
^Z^Zfield 9
|
||||
@var{commands}
|
||||
@end example
|
||||
|
||||
The output ends with
|
||||
|
||||
@findex breakpoints-table-end
|
||||
@example
|
||||
^Z^Zbreakpoints-table-end
|
||||
@end example
|
||||
|
||||
@node Invalidation
|
||||
@chapter Invalidation Notices
|
||||
|
||||
The following annotations say that certain pieces of state may have
|
||||
changed.
|
||||
|
||||
@table @code
|
||||
@findex frames-invalid
|
||||
@item ^Z^Zframes-invalid
|
||||
|
||||
The frames (for example, output from the @code{backtrace} command) may
|
||||
have changed.
|
||||
|
||||
@findex breakpoints-invalid
|
||||
@item ^Z^Zbreakpoints-invalid
|
||||
|
||||
The breakpoints may have changed. For example, the user just added or
|
||||
deleted a breakpoint.
|
||||
@end table
|
||||
|
||||
@node Running
|
||||
@chapter Running the Program
|
||||
|
||||
@findex starting
|
||||
@findex stopping
|
||||
When the program starts executing due to a GDB command such as
|
||||
@code{step} or @code{continue},
|
||||
|
||||
@example
|
||||
^Z^Zstarting
|
||||
@end example
|
||||
|
||||
is output. When the program stops,
|
||||
|
||||
@example
|
||||
^Z^Zstopped
|
||||
@end example
|
||||
|
||||
is output. Before the @code{stopped} annotation, a variety of
|
||||
annotations describe how the program stopped.
|
||||
|
||||
@table @code
|
||||
@findex exited
|
||||
@item ^Z^Zexited @var{exit-status}
|
||||
The program exited, and @var{exit-status} is the exit status (zero for
|
||||
successful exit, otherwise nonzero).
|
||||
|
||||
@findex signalled
|
||||
@findex signal-name
|
||||
@findex signal-name-end
|
||||
@findex signal-string
|
||||
@findex signal-string-end
|
||||
@item ^Z^Zsignalled
|
||||
The program exited with a signal. After the @code{^Z^Zsignalled}, the
|
||||
annotation continues:
|
||||
|
||||
@example
|
||||
@var{intro-text}
|
||||
^Z^Zsignal-name
|
||||
@var{name}
|
||||
^Z^Zsignal-name-end
|
||||
@var{middle-text}
|
||||
^Z^Zsignal-string
|
||||
@var{string}
|
||||
^Z^Zsignal-string-end
|
||||
@var{end-text}
|
||||
@end example
|
||||
|
||||
where @var{name} is the name of the signal, such as @code{SIGILL} or
|
||||
@code{SIGSEGV}, and @var{string} is the explanation of the signal, such
|
||||
as @code{Illegal Instruction} or @code{Segmentation fault}.
|
||||
@var{intro-text}, @var{middle-text}, and @var{end-text} are for the
|
||||
user's benefit and have no particular format.
|
||||
|
||||
@findex signal
|
||||
@item ^Z^Zsignal
|
||||
The syntax of this annotation is just like @code{signalled}, but GDB is
|
||||
just saying that the program received the signal, not that it was
|
||||
terminated with it.
|
||||
|
||||
@findex breakpoint
|
||||
@item ^Z^Zbreakpoint @var{number}
|
||||
The program hit breakpoint number @var{number}.
|
||||
|
||||
@findex watchpoint
|
||||
@item ^Z^Zwatchpoint @var{number}
|
||||
The program hit watchpoint number @var{number}.
|
||||
@end table
|
||||
|
||||
@node Source
|
||||
@chapter Displaying Source
|
||||
|
||||
@findex source
|
||||
The following annotation is used instead of displaying source code:
|
||||
|
||||
@example
|
||||
^Z^Zsource @var{filename}:@var{line}:@var{character}:@var{middle}:@var{addr}
|
||||
@end example
|
||||
|
||||
where @var{filename} is an absolute file name indicating which source
|
||||
file, @var{line} is the line number within that file (where 1 is the
|
||||
first line in the file), @var{character} is the character position
|
||||
within the file (where 0 is the first character in the file) (for most
|
||||
debug formats this will necessarily point to the beginning of a line),
|
||||
@var{middle} is @samp{middle} if @var{addr} is in the middle of the
|
||||
line, or @samp{beg} if @var{addr} is at the beginning of the line, and
|
||||
@var{addr} is the address in the target program associated with the
|
||||
source which is being displayed.
|
||||
|
||||
@node TODO
|
||||
@chapter Annotations We Might Want in the Future
|
||||
|
||||
@format
|
||||
- target-invalid
|
||||
the target might have changed (registers, heap contents, or
|
||||
execution status). For performance, we might eventually want
|
||||
to hit `registers-invalid' and `all-registers-invalid' with
|
||||
greater precision
|
||||
|
||||
- systematic annotation for set/show parameters (including
|
||||
invalidation notices).
|
||||
|
||||
- similarly, `info' returns a list of candidates for invalidation
|
||||
notices.
|
||||
@end format
|
||||
|
||||
@node Index
|
||||
@unnumbered Index
|
||||
|
||||
@printindex fn
|
||||
|
||||
@bye
|
File diff suppressed because it is too large
Load Diff
|
@ -1,6 +1,6 @@
|
|||
\input texinfo
|
||||
@setfilename gdbint.info
|
||||
@c $Id: gdbint.texinfo,v 1.1.1.1 1993/10/30 21:59:41 jkh Exp $
|
||||
@c $Id: gdbint.texinfo,v 1.76 1994/07/17 21:17:18 shebs Exp $
|
||||
|
||||
@ifinfo
|
||||
@format
|
||||
|
@ -13,7 +13,7 @@ END-INFO-DIR-ENTRY
|
|||
@ifinfo
|
||||
This file documents the internals of the GNU debugger GDB.
|
||||
|
||||
Copyright 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
|
||||
Copyright 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Support. Written by John Gilmore.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
|
@ -42,7 +42,7 @@ regarded as a program in the language TeX).
|
|||
@page
|
||||
@tex
|
||||
\def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
|
||||
\xdef\manvers{\$Revision: 1.1.1.1 $} % For use in headers, footers too
|
||||
\xdef\manvers{\$Revision: 1.76 $} % For use in headers, footers too
|
||||
{\parskip=0pt
|
||||
\hfill Cygnus Support\par
|
||||
\hfill \manvers\par
|
||||
|
@ -51,7 +51,7 @@ regarded as a program in the language TeX).
|
|||
@end tex
|
||||
|
||||
@vskip 0pt plus 1filll
|
||||
Copyright @copyright{} 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
|
||||
Copyright @copyright{} 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
|
@ -201,17 +201,17 @@ Good luck!
|
|||
|
||||
@node Debugging GDB
|
||||
@chapter Debugging GDB with itself
|
||||
If gdb is limping on your machine, this is the preferred way to get it
|
||||
If GDB is limping on your machine, this is the preferred way to get it
|
||||
fully functional. Be warned that in some ancient Unix systems, like
|
||||
Ultrix 4.2, a program can't be running in one process while it is being
|
||||
debugged in another. Rather than typing the command @code{@w{./gdb
|
||||
./gdb}}, which works on Suns and such, you can copy @file{gdb} to
|
||||
@file{gdb2} and then type @code{@w{./gdb ./gdb2}}.
|
||||
|
||||
When you run gdb in the gdb source directory, it will read a
|
||||
When you run GDB in the GDB source directory, it will read a
|
||||
@file{.gdbinit} file that sets up some simple things to make debugging
|
||||
gdb easier. The @code{info} command, when executed without a subcommand
|
||||
in a gdb being debugged by gdb, will pop you back up to the top level
|
||||
in a GDB being debugged by gdb, will pop you back up to the top level
|
||||
gdb. See @file{.gdbinit} for details.
|
||||
|
||||
If you use emacs, you will probably want to do a @code{make TAGS} after
|
||||
|
@ -219,7 +219,7 @@ you configure your distribution; this will put the machine dependent
|
|||
routines for your local machine where they will be accessed first by
|
||||
@kbd{M-.}
|
||||
|
||||
Also, make sure that you've either compiled gdb with your local cc, or
|
||||
Also, make sure that you've either compiled GDB with your local cc, or
|
||||
have run @code{fixincludes} if you are compiling with gcc.
|
||||
|
||||
@node New Architectures
|
||||
|
@ -347,7 +347,7 @@ Then edit @file{bfd/configure.host}. Add a line to recognize your
|
|||
@code{my_host} to @var{xxx} when you recognize it. This will cause your
|
||||
file @file{h-@var{xxx}.h} to be linked to @file{sysdep.h} at configuration
|
||||
time. When creating the line that recognizes your configuration,
|
||||
only match the fields that you really need to match; e.g. don't match
|
||||
only match the fields that you really need to match; e.g. don't
|
||||
match the architecture or manufacturer if the OS is sufficient
|
||||
to distinguish the configuration that your @file{h-@var{xxx}.h} file supports.
|
||||
Don't match the manufacturer name unless you really need to.
|
||||
|
@ -452,7 +452,7 @@ Now, you are now ready to try configuring GDB to compile using your system
|
|||
as its host. From the top level (above @file{bfd}, @file{gdb}, etc), do:
|
||||
|
||||
@example
|
||||
./configure @var{xxx} +target=vxworks960
|
||||
./configure @var{xxx} --target=vxworks960
|
||||
@end example
|
||||
|
||||
This will configure your system to cross-compile for VxWorks on
|
||||
|
@ -933,14 +933,14 @@ more work.
|
|||
|
||||
Fundamental Types (e.g., FT_VOID, FT_BOOLEAN).
|
||||
|
||||
These are the fundamental types that gdb uses internally. Fundamental
|
||||
These are the fundamental types that GDB uses internally. Fundamental
|
||||
types from the various debugging formats (stabs, ELF, etc) are mapped into
|
||||
one of these. They are basically a union of all fundamental types that
|
||||
gdb knows about for all the languages that gdb knows about.
|
||||
gdb knows about for all the languages that GDB knows about.
|
||||
|
||||
Type Codes (e.g., TYPE_CODE_PTR, TYPE_CODE_ARRAY).
|
||||
|
||||
Each time gdb builds an internal type, it marks it with one of these
|
||||
Each time GDB builds an internal type, it marks it with one of these
|
||||
types. The type may be a fundamental type, such as TYPE_CODE_INT, or
|
||||
a derived type, such as TYPE_CODE_PTR which is a pointer to another
|
||||
type. Typically, several FT_* types map to one TYPE_CODE_* type, and
|
||||
|
@ -950,7 +950,7 @@ the type is signed or unsigned, and how many bits it uses.
|
|||
Builtin Types (e.g., builtin_type_void, builtin_type_char).
|
||||
|
||||
These are instances of type structs that roughly correspond to fundamental
|
||||
types and are created as global types for gdb to use for various ugly
|
||||
types and are created as global types for GDB to use for various ugly
|
||||
historical reasons. We eventually want to eliminate these. Note for
|
||||
example that builtin_type_int initialized in gdbtypes.c is basically the
|
||||
same as a TYPE_CODE_INT type that is initialized in c-lang.c for an
|
||||
|
@ -997,7 +997,7 @@ string table, etc.
|
|||
@chapter Symbol Reading
|
||||
|
||||
GDB reads symbols from "symbol files". The usual symbol file is the
|
||||
file containing the program which gdb is debugging. GDB can be directed
|
||||
file containing the program which GDB is debugging. GDB can be directed
|
||||
to use a different file for symbols (with the ``symbol-file''
|
||||
command), and it can also read more symbols via the ``add-file'' and ``load''
|
||||
commands, or while reading symbols from shared libraries.
|
||||
|
@ -1490,23 +1490,30 @@ available somehow (e.g. anonymous FTP), and announce it on
|
|||
|
||||
When GDB is configured and compiled, various macros are defined or left
|
||||
undefined, to control compilation based on the attributes of the host
|
||||
system. These macros and their meanings are:
|
||||
system. These macros and their meanings (or if the meaning is not
|
||||
documented here, then one of the source files where they are used is
|
||||
indicated) are:
|
||||
|
||||
@emph{NOTE: For now, both host and target conditionals are here.
|
||||
Eliminate target conditionals from this list as they are identified.}
|
||||
|
||||
@table @code
|
||||
|
||||
@item BLOCK_ADDRESS_FUNCTION_RELATIVE
|
||||
dbxread.c
|
||||
|
||||
@item GDBINIT_FILENAME
|
||||
The default name of GDB's initialization file (normally @file{.gdbinit}).
|
||||
|
||||
@item KERNELDEBUG
|
||||
tm-hppa.h
|
||||
|
||||
@item MEM_FNS_DECLARED
|
||||
Your host config file defines this if it includes
|
||||
declarations of @code{memcpy} and @code{memset}. Define this
|
||||
to avoid conflicts between the native include
|
||||
files and the declarations in @file{defs.h}.
|
||||
|
||||
@item NO_SYS_FILE
|
||||
dbxread.c
|
||||
@item PYRAMID_CONTROL_FRAME_DEBUGGING
|
||||
|
@ -1533,8 +1540,6 @@ altos-xdep.c
|
|||
xm-altos.h
|
||||
@item ASCII_COFF
|
||||
remote-adapt.c
|
||||
@item BADMAG
|
||||
coffread.c
|
||||
@item BCS
|
||||
tm-delta88.h
|
||||
@item BEFORE_MAIN_LOOP_HOOK
|
||||
|
@ -1551,28 +1556,20 @@ solib.c
|
|||
dbxread.c
|
||||
@item BPT_VECTOR
|
||||
tm-m68k.h
|
||||
@item BREAKPOINT
|
||||
tm-m68k.h
|
||||
@item BREAKPOINT_DEBUG
|
||||
breakpoint.c
|
||||
|
||||
@item BROKEN_LARGE_ALLOCA
|
||||
Avoid large @code{alloca}'s. For example, on sun's, Large alloca's fail
|
||||
because the attempt to increase the stack limit in main() fails because
|
||||
shared libraries are allocated just below the initial stack limit. The
|
||||
SunOS kernel will not allow the stack to grow into the area occupied by
|
||||
the shared libraries.
|
||||
@item BSTRING
|
||||
regex.c
|
||||
|
||||
@item CALL_DUMMY
|
||||
valops.c
|
||||
@item CALL_DUMMY_LOCATION
|
||||
inferior.h
|
||||
@item CALL_DUMMY_STACK_ADJUST
|
||||
valops.c
|
||||
@item CANNOT_FETCH_REGISTER
|
||||
hppabsd-xdep.c
|
||||
@item CANNOT_STORE_REGISTER
|
||||
findvar.c
|
||||
@item CFRONT_PRODUCER
|
||||
dwarfread.c
|
||||
@item CHILD_PREPARE_TO_STORE
|
||||
|
@ -1589,8 +1586,6 @@ symm-tdep.c
|
|||
stack.c
|
||||
@item CPLUS_MARKER
|
||||
cplus-dem.c
|
||||
@item CREATE_INFERIOR_HOOK
|
||||
infrun.c
|
||||
@item C_ALLOCA
|
||||
regex.c
|
||||
@item C_GLBLREG
|
||||
|
@ -1599,16 +1594,16 @@ coffread.c
|
|||
partial-stab.h
|
||||
@item DBX_PARM_SYMBOL_CLASS
|
||||
stabsread.c
|
||||
@item DEBUG
|
||||
remote-adapt.c
|
||||
@item DEBUG_INFO
|
||||
partial-stab.h
|
||||
@item DEBUG_PTRACE
|
||||
hppabsd-xdep.c
|
||||
@item DECR_PC_AFTER_BREAK
|
||||
breakpoint.c
|
||||
|
||||
@item DEFAULT_PROMPT
|
||||
The default value of the prompt string (normally @code{"(gdb) "}).
|
||||
|
||||
@item DELTA88
|
||||
m88k-xdep.c
|
||||
@item DEV_TTY
|
||||
|
@ -1637,24 +1632,6 @@ target.c
|
|||
infcmd.c
|
||||
@item FOPEN_RB
|
||||
defs.h
|
||||
@item FRAMELESS_FUNCTION_INVOCATION
|
||||
blockframe.c
|
||||
@item FRAME_ARGS_ADDRESS_CORRECT
|
||||
stack.c
|
||||
@item FRAME_CHAIN_COMBINE
|
||||
blockframe.c
|
||||
@item FRAME_CHAIN_VALID
|
||||
frame.h
|
||||
@item FRAME_CHAIN_VALID_ALTERNATE
|
||||
frame.h
|
||||
@item FRAME_FIND_SAVED_REGS
|
||||
stack.c
|
||||
@item FRAME_GET_BASEREG_VALUE
|
||||
frame.h
|
||||
@item FRAME_NUM_ARGS
|
||||
tm-m68k.h
|
||||
@item FRAME_SPECIFICATION_DYADIC
|
||||
stack.c
|
||||
@item FUNCTION_EPILOGUE_SIZE
|
||||
coffread.c
|
||||
@item F_OK
|
||||
|
@ -1673,9 +1650,11 @@ findvar.c
|
|||
dwarfread.c
|
||||
@item HANDLE_RBRAC
|
||||
partial-stab.h
|
||||
|
||||
@item HAVE_MMAP
|
||||
In some cases, use the system call @code{mmap} for reading symbol
|
||||
tables. For some machines this allows for sharing and quick updates.
|
||||
|
||||
@item HAVE_REGISTER_WINDOWS
|
||||
findvar.c
|
||||
@item HAVE_SIGSETMASK
|
||||
|
@ -1687,7 +1666,7 @@ arm-tdep.c
|
|||
@item HOSTING_ONLY
|
||||
xm-rtbsd.h
|
||||
@item HOST_BYTE_ORDER
|
||||
ieee-float.c
|
||||
findvar.c
|
||||
@item HPUX_ASM
|
||||
xm-hp300hpux.h
|
||||
@item HPUX_VERSION_5
|
||||
|
@ -1696,8 +1675,6 @@ hp300ux-xdep.c
|
|||
infrun.c
|
||||
@item I80960
|
||||
remote-vx.c
|
||||
@item IEEE_DEBUG
|
||||
ieee-float.c
|
||||
@item IEEE_FLOAT
|
||||
valprint.c
|
||||
@item IGNORE_SYMBOL
|
||||
|
@ -1728,20 +1705,24 @@ values.c
|
|||
dbxread.c
|
||||
@item KERNEL_DEBUGGING
|
||||
tm-ultra3.h
|
||||
|
||||
@item KERNEL_U_ADDR
|
||||
Define this to the address of the @code{u} structure (the ``user struct'',
|
||||
also known as the ``u-page'') in kernel virtual memory. GDB needs to know
|
||||
this so that it can subtract this address from absolute addresses in
|
||||
the upage, that are obtained via ptrace or from core files. On systems
|
||||
that don't need this value, set it to zero.
|
||||
|
||||
@item KERNEL_U_ADDR_BSD
|
||||
Define this to cause GDB to determine the address of @code{u} at runtime,
|
||||
by using Berkeley-style @code{nlist} on the kernel's image in the root
|
||||
directory.
|
||||
|
||||
@item KERNEL_U_ADDR_HPUX
|
||||
Define this to cause GDB to determine the address of @code{u} at runtime,
|
||||
by using HP-style @code{nlist} on the kernel's image in the root
|
||||
directory.
|
||||
|
||||
@item LCC_PRODUCER
|
||||
dwarfread.c
|
||||
@item LOG_FILE
|
||||
|
@ -1760,25 +1741,33 @@ defs.h
|
|||
source.c
|
||||
@item L_LNNO32
|
||||
coffread.c
|
||||
|
||||
@item L_SET
|
||||
This macro is used as the argument to lseek (or, most commonly, bfd_seek).
|
||||
FIXME, it should be replaced by SEEK_SET instead, which is the POSIX equivalent.
|
||||
FIXME, should be replaced by SEEK_SET instead, which is the POSIX equivalent.
|
||||
|
||||
@item MACHKERNELDEBUG
|
||||
hppabsd-tdep.c
|
||||
@item MAINTENANCE
|
||||
dwarfread.c
|
||||
|
||||
@item MAINTENANCE_CMDS
|
||||
If the value of this is 1, then a number of optional maintenance commands
|
||||
are compiled in.
|
||||
|
||||
@item MALLOC_INCOMPATIBLE
|
||||
Define this if the system's prototype for @code{malloc} differs from the
|
||||
@sc{ANSI} definition.
|
||||
|
||||
@item MIPSEL
|
||||
mips-tdep.c
|
||||
|
||||
@item MMAP_BASE_ADDRESS
|
||||
When using HAVE_MMAP, the first mapping should go at this address.
|
||||
|
||||
@item MMAP_INCREMENT
|
||||
when using HAVE_MMAP, this is the increment between mappings.
|
||||
|
||||
@item MONO
|
||||
ser-go32.c
|
||||
@item MOTOROLA
|
||||
|
@ -1791,8 +1780,10 @@ infrun.c
|
|||
exec.c
|
||||
@item NFAILURES
|
||||
regex.c
|
||||
|
||||
@item NORETURN
|
||||
(in defs.h - is this really useful to define/undefine?)
|
||||
|
||||
@item NOTDEF
|
||||
regex.c
|
||||
@item NOTDEF
|
||||
|
@ -1805,6 +1796,7 @@ infrun.c
|
|||
remote-mm.c
|
||||
@item NO_JOB_CONTROL
|
||||
signals.h
|
||||
|
||||
@item NO_MMALLOC
|
||||
GDB will use the @code{mmalloc} library for memory allocation for symbol
|
||||
reading, unless this symbol is defined. Define it on systems
|
||||
|
@ -1816,9 +1808,11 @@ to override the setting of @code{MMALLOC_LIB} to empty, in the Makefile.
|
|||
Therefore, this define is usually set on the command line by overriding
|
||||
@code{MMALLOC_DISABLE} in @file{config/*/*.mh}, rather than by defining
|
||||
it in @file{xm-*.h}.
|
||||
|
||||
@item NO_MMALLOC_CHECK
|
||||
Define this if you are using @code{mmalloc}, but don't want the overhead
|
||||
of checking the heap with @code{mmcheck}.
|
||||
|
||||
@item NO_SIGINTERRUPT
|
||||
remote-adapt.c
|
||||
@item NO_SINGLE_STEP
|
||||
|
@ -1887,6 +1881,7 @@ state.c
|
|||
state.c
|
||||
@item SEM
|
||||
coffread.c
|
||||
|
||||
@item SET_STACK_LIMIT_HUGE
|
||||
When defined, stack limits will be raised to their maximum. Use this
|
||||
if your host supports @code{setrlimit} and you have trouble with
|
||||
|
@ -1894,6 +1889,7 @@ if your host supports @code{setrlimit} and you have trouble with
|
|||
|
||||
Also used in @file{fork-child.c} to return stack limits before child
|
||||
processes are forked.
|
||||
|
||||
@item SHELL_COMMAND_CONCAT
|
||||
infrun.c
|
||||
@item SHELL_FILE
|
||||
|
@ -1904,24 +1900,16 @@ breakpoint.c
|
|||
regex.c
|
||||
@item SIGTRAP_STOP_AFTER_LOAD
|
||||
infrun.c
|
||||
@item SKIP_PROLOGUE
|
||||
tm-m68k.h
|
||||
@item SKIP_PROLOGUE_FRAMELESS_P
|
||||
blockframe.c
|
||||
@item SKIP_TRAMPOLINE_CODE
|
||||
infrun.c
|
||||
@item SOLIB_ADD
|
||||
core.c
|
||||
@item SOLIB_CREATE_INFERIOR_HOOK
|
||||
infrun.c
|
||||
@item STACK_ALIGN
|
||||
valops.c
|
||||
@item START_INFERIOR_TRAPS_EXPECTED
|
||||
infrun.c
|
||||
@item STOP_SIGNAL
|
||||
main.c
|
||||
@item STORE_RETURN_VALUE
|
||||
tm-m68k.h
|
||||
@item SUN4_COMPILER_FEATURE
|
||||
infrun.c
|
||||
@item SUN_FIXED_LBRAC_BUG
|
||||
|
@ -1938,8 +1926,6 @@ symfile.c
|
|||
regex.c
|
||||
@item Sword
|
||||
regex.c
|
||||
@item TDESC
|
||||
infrun.c
|
||||
@item TIOCGETC
|
||||
inflow.c
|
||||
@item TIOCGLTC
|
||||
|
@ -1968,10 +1954,12 @@ xm-news.h
|
|||
inflow.c
|
||||
@item USE_STRUCT_CONVENTION
|
||||
values.c
|
||||
|
||||
@item USG
|
||||
Means that System V (prior to SVR4) include files are in use.
|
||||
(FIXME: This symbol is abused in @file{infrun.c}, @file{regex.c},
|
||||
@file{remote-nindy.c}, and @file{utils.c} for other things, at the moment.)
|
||||
|
||||
@item USIZE
|
||||
xm-m88k.h
|
||||
@item U_FPSTATE
|
||||
|
@ -1980,10 +1968,6 @@ i386-xdep.c
|
|||
dbxread.c
|
||||
@item WRS_ORIG
|
||||
remote-vx.c
|
||||
@item _LANG_c
|
||||
language.c
|
||||
@item _LANG_m2
|
||||
language.c
|
||||
@item __GNUC__
|
||||
news-xdep.c
|
||||
@item __GO32__
|
||||
|
@ -2041,10 +2025,13 @@ system. These macros and their meanings are:
|
|||
Eliminate host conditionals from this list as they are identified.}
|
||||
|
||||
@table @code
|
||||
|
||||
@item PUSH_DUMMY_FRAME
|
||||
Used in @samp{call_function_by_hand} to create an artificial stack frame.
|
||||
|
||||
@item POP_FRAME
|
||||
Used in @samp{call_function_by_hand} to remove an artificial stack frame.
|
||||
|
||||
@item BLOCK_ADDRESS_FUNCTION_RELATIVE
|
||||
dbxread.c
|
||||
@item KERNELDEBUG
|
||||
|
@ -2073,12 +2060,8 @@ altos-xdep.c
|
|||
xm-altos.h
|
||||
@item ASCII_COFF
|
||||
remote-adapt.c
|
||||
@item BADMAG
|
||||
coffread.c
|
||||
@item BCS
|
||||
tm-delta88.h
|
||||
@item BEFORE_MAIN_LOOP_HOOK
|
||||
main.c
|
||||
@item BELIEVE_PCC_PROMOTION
|
||||
coffread.c
|
||||
@item BELIEVE_PCC_PROMOTION_TYPE
|
||||
|
@ -2093,20 +2076,25 @@ dbxread.c
|
|||
tm-m68k.h
|
||||
@item BREAKPOINT
|
||||
tm-m68k.h
|
||||
@item BREAKPOINT_DEBUG
|
||||
breakpoint.c
|
||||
@item BSTRING
|
||||
regex.c
|
||||
@item CALL_DUMMY
|
||||
valops.c
|
||||
@item CALL_DUMMY_LOCATION
|
||||
inferior.h
|
||||
@item CALL_DUMMY_STACK_ADJUST
|
||||
valops.c
|
||||
@item CANNOT_FETCH_REGISTER
|
||||
hppabsd-xdep.c
|
||||
@item CANNOT_STORE_REGISTER
|
||||
findvar.c
|
||||
|
||||
@item CANNOT_FETCH_REGISTER (regno)
|
||||
A C expression that should be nonzero if @var{regno} cannot be
|
||||
fetched from an inferior process.
|
||||
This is only relevant if @code{FETCH_INFERIOR_REGISTERS} is not
|
||||
defined.
|
||||
|
||||
@item CANNOT_STORE_REGISTER (regno)
|
||||
A C expression that should be nonzero if @var{regno} should not be
|
||||
written to the target. This is often the case for program counters,
|
||||
status words, and other special registers. If this is not defined,
|
||||
GDB will assume that all registers may be written.
|
||||
|
||||
@item CFRONT_PRODUCER
|
||||
dwarfread.c
|
||||
@item CHILD_PREPARE_TO_STORE
|
||||
|
@ -2123,18 +2111,12 @@ symm-tdep.c
|
|||
stack.c
|
||||
@item CPLUS_MARKER
|
||||
cplus-dem.c
|
||||
@item CREATE_INFERIOR_HOOK
|
||||
infrun.c
|
||||
@item C_ALLOCA
|
||||
regex.c
|
||||
@item C_GLBLREG
|
||||
coffread.c
|
||||
@item DBXREAD_ONLY
|
||||
partial-stab.h
|
||||
@item DBX_PARM_SYMBOL_CLASS
|
||||
stabsread.c
|
||||
@item DEBUG
|
||||
remote-adapt.c
|
||||
@item DEBUG_INFO
|
||||
partial-stab.h
|
||||
@item DEBUG_PTRACE
|
||||
|
@ -2155,9 +2137,11 @@ remote.c
|
|||
infrun.c
|
||||
@item DO_REGISTERS_INFO
|
||||
infcmd.c
|
||||
|
||||
@item END_OF_TEXT_DEFAULT
|
||||
This is an expression that should designate the end of the text section
|
||||
(? FIXME ?)
|
||||
|
||||
@item EXTRACT_RETURN_VALUE
|
||||
tm-m68k.h
|
||||
@item EXTRACT_STRUCT_VALUE_ADDRESS
|
||||
|
@ -2178,14 +2162,14 @@ a68v-xdep.c
|
|||
mach386-xdep.c
|
||||
@item FP_REGNUM
|
||||
parse.c
|
||||
@item FPU
|
||||
Unused? 6-oct-92 rich@@cygnus.com. FIXME.
|
||||
@item FRAMELESS_FUNCTION_INVOCATION
|
||||
blockframe.c
|
||||
@item FRAME_ARGS_ADDRESS_CORRECT
|
||||
stack.c
|
||||
|
||||
@item FRAME_CHAIN
|
||||
Given FRAME, return a pointer to the calling frame.
|
||||
|
||||
@item FRAME_CHAIN_COMBINE
|
||||
blockframe.c
|
||||
@item FRAME_CHAIN_VALID
|
||||
|
@ -2196,12 +2180,17 @@ frame.h
|
|||
stack.c
|
||||
@item FRAME_GET_BASEREG_VALUE
|
||||
frame.h
|
||||
@item FRAME_NUM_ARGS
|
||||
tm-m68k.h
|
||||
|
||||
@item FRAME_NUM_ARGS (val, fi)
|
||||
For the frame described by fi, set val to the number of arguments
|
||||
that are being passed.
|
||||
|
||||
@item FRAME_SPECIFICATION_DYADIC
|
||||
stack.c
|
||||
|
||||
@item FRAME_SAVED_PC
|
||||
Given FRAME, return the pc saved there. That is, the return address.
|
||||
|
||||
@item FUNCTION_EPILOGUE_SIZE
|
||||
coffread.c
|
||||
@item F_OK
|
||||
|
@ -2214,16 +2203,19 @@ dbxread.c
|
|||
symtab.c
|
||||
@item GCC_PRODUCER
|
||||
dwarfread.c
|
||||
|
||||
@item GDB_TARGET_IS_HPPA
|
||||
This determines whether horrible kludge code in dbxread.c and partial-stab.h
|
||||
is used to mangle multiple-symbol-table files from HPPA's. This should all
|
||||
be ripped out, and a scheme like elfread.c used.
|
||||
|
||||
@item GDB_TARGET_IS_MACH386
|
||||
mach386-xdep.c
|
||||
@item GDB_TARGET_IS_SUN3
|
||||
a68v-xdep.c
|
||||
@item GDB_TARGET_IS_SUN386
|
||||
sun386-xdep.c
|
||||
|
||||
@item GET_LONGJMP_TARGET
|
||||
For most machines, this is a target-dependent parameter. On the DECstation
|
||||
and the Iris, this is a native-dependent parameter, since <setjmp.h> is
|
||||
|
@ -2233,6 +2225,7 @@ This macro determines the target PC address that longjmp() will jump
|
|||
to, assuming that we have just stopped at a longjmp breakpoint. It
|
||||
takes a CORE_ADDR * as argument, and stores the target PC value through
|
||||
this pointer. It examines the current state of the machine as needed.
|
||||
|
||||
@item GET_SAVED_REGISTER
|
||||
findvar.c
|
||||
@item GPLUS_PRODUCER
|
||||
|
@ -2255,8 +2248,6 @@ inflow.c
|
|||
arm-tdep.c
|
||||
@item HOSTING_ONLY
|
||||
xm-rtbsd.h
|
||||
@item HOST_BYTE_ORDER
|
||||
ieee-float.c
|
||||
@item HPUX_ASM
|
||||
xm-hp300hpux.h
|
||||
@item HPUX_VERSION_5
|
||||
|
@ -2265,12 +2256,12 @@ hp300ux-xdep.c
|
|||
infrun.c
|
||||
@item I80960
|
||||
remote-vx.c
|
||||
|
||||
@item IBM6000_TARGET
|
||||
Shows that we are configured for an IBM RS/6000 target. This conditional
|
||||
should be eliminated (FIXME) and replaced by feature-specific macros.
|
||||
It was introduced in haste and we are repenting at leisure.
|
||||
@item IEEE_DEBUG
|
||||
ieee-float.c
|
||||
|
||||
@item IEEE_FLOAT
|
||||
valprint.c
|
||||
@item IGNORE_SYMBOL
|
||||
|
@ -2331,13 +2322,9 @@ altos-xdep.c
|
|||
infrun.c
|
||||
@item NEED_TEXT_START_END
|
||||
exec.c
|
||||
@item NFAILURES
|
||||
regex.c
|
||||
@item NNPC_REGNUM
|
||||
infrun.c
|
||||
@item NOTDEF
|
||||
regex.c
|
||||
@item NOTDEF
|
||||
remote-adapt.c
|
||||
@item NOTDEF
|
||||
remote-mm.c
|
||||
|
@ -2397,15 +2384,15 @@ tm-a29k.h
|
|||
exec.c
|
||||
@item REG_STRUCT_HAS_ADDR
|
||||
findvar.c
|
||||
@item RE_NREGS
|
||||
regex.h
|
||||
@item R_FP
|
||||
dwarfread.c
|
||||
@item R_OK
|
||||
xm-altos.h
|
||||
|
||||
@item SDB_REG_TO_REGNUM
|
||||
Define this to convert sdb register numbers
|
||||
into gdb regnums. If not defined, no conversion will be done.
|
||||
into GDB regnums. If not defined, no conversion will be done.
|
||||
|
||||
@item SEEK_END
|
||||
state.c
|
||||
@item SEEK_SET
|
||||
|
@ -2418,73 +2405,91 @@ infrun.c
|
|||
infrun.c
|
||||
@item SHIFT_INST_REGS
|
||||
breakpoint.c
|
||||
@item SIGN_EXTEND_CHAR
|
||||
regex.c
|
||||
@item SIGTRAP_STOP_AFTER_LOAD
|
||||
infrun.c
|
||||
|
||||
@item SKIP_PROLOGUE
|
||||
tm-m68k.h
|
||||
A C statement that advances the PC across any function entry
|
||||
prologue instructions so as to reach ``real'' code.
|
||||
|
||||
@item SKIP_PROLOGUE_FRAMELESS_P
|
||||
blockframe.c
|
||||
A C statement that should behave similarly, but that can stop
|
||||
as soon as the function is known to have a frame.
|
||||
If not defined, @code{SKIP_PROLOGUE} will be used instead.
|
||||
|
||||
@item SKIP_TRAMPOLINE_CODE
|
||||
infrun.c
|
||||
@item SOLIB_ADD
|
||||
core.c
|
||||
@item SOLIB_CREATE_INFERIOR_HOOK
|
||||
infrun.c
|
||||
@item SP_REGNUM
|
||||
parse.c
|
||||
|
||||
@item STAB_REG_TO_REGNUM
|
||||
Define this to convert stab register numbers (as gotten from `r' declarations)
|
||||
into gdb regnums. If not defined, no conversion will be done.
|
||||
into GDB regnums. If not defined, no conversion will be done.
|
||||
|
||||
@item STACK_ALIGN
|
||||
valops.c
|
||||
@item START_INFERIOR_TRAPS_EXPECTED
|
||||
infrun.c
|
||||
@item STOP_SIGNAL
|
||||
main.c
|
||||
@item STORE_RETURN_VALUE
|
||||
tm-m68k.h
|
||||
|
||||
@item STORE_RETURN_VALUE (type, valbuf)
|
||||
A C expression that stores a function return value of type @var{type},
|
||||
where @var{valbuf} is the address of the value to be stored.
|
||||
|
||||
@item SUN4_COMPILER_FEATURE
|
||||
infrun.c
|
||||
@item SUN_FIXED_LBRAC_BUG
|
||||
dbxread.c
|
||||
@item SVR4_SHARED_LIBS
|
||||
solib.c
|
||||
@item SWITCH_ENUM_BUG
|
||||
regex.c
|
||||
@item SYM1
|
||||
tm-ultra3.h
|
||||
@item SYMBOL_RELOADING_DEFAULT
|
||||
symfile.c
|
||||
@item SYNTAX_TABLE
|
||||
regex.c
|
||||
@item Sword
|
||||
regex.c
|
||||
|
||||
@item TARGET_BYTE_ORDER
|
||||
defs.h
|
||||
The ordering of bytes in the target.
|
||||
This must be defined to be either @code{BIG_ENDIAN} or @code{LITTLE_ENDIAN}.
|
||||
|
||||
@item TARGET_CHAR_BIT
|
||||
defs.h
|
||||
Number of bits in a char; defaults to 8.
|
||||
|
||||
@item TARGET_COMPLEX_BIT
|
||||
defs.h
|
||||
Number of bits in a complex number; defaults to @code{2 * TARGET_FLOAT_BIT}.
|
||||
|
||||
@item TARGET_DOUBLE_BIT
|
||||
defs.h
|
||||
Number of bits in a double float; defaults to @code{8 * TARGET_CHAR_BIT}.
|
||||
|
||||
@item TARGET_DOUBLE_COMPLEX_BIT
|
||||
defs.h
|
||||
Number of bits in a double complex; defaults to @code{2 * TARGET_DOUBLE_BIT}.
|
||||
|
||||
@item TARGET_FLOAT_BIT
|
||||
defs.h
|
||||
Number of bits in a float; defaults to @code{4 * TARGET_CHAR_BIT}.
|
||||
|
||||
@item TARGET_INT_BIT
|
||||
defs.h
|
||||
Number of bits in an integer; defaults to @code{4 * TARGET_CHAR_BIT}.
|
||||
|
||||
@item TARGET_LONG_BIT
|
||||
defs.h
|
||||
Number of bits in a long integer; defaults to @code{4 * TARGET_CHAR_BIT}.
|
||||
|
||||
@item TARGET_LONG_DOUBLE_BIT
|
||||
defs.h
|
||||
Number of bits in a long double float;
|
||||
defaults to @code{2 * TARGET_DOUBLE_BIT}.
|
||||
|
||||
@item TARGET_LONG_LONG_BIT
|
||||
defs.h
|
||||
Number of bits in a long long integer; defaults to @code{2 * TARGET_LONG_BIT}.
|
||||
|
||||
@item TARGET_PTR_BIT
|
||||
defs.h
|
||||
Number of bits in a pointer; defaults to @code{TARGET_INT_BIT}.
|
||||
|
||||
@item TARGET_SHORT_BIT
|
||||
Number of bits in a short integer; defaults to @code{2 * TARGET_CHAR_BIT}.
|
||||
|
||||
@item TARGET_READ_PC
|
||||
@item TARGET_WRITE_PC
|
||||
@item TARGET_WRITE_PC (val, pid)
|
||||
@item TARGET_READ_SP
|
||||
@item TARGET_WRITE_SP
|
||||
@item TARGET_READ_FP
|
||||
|
@ -2498,10 +2503,6 @@ These macros are useful when a target keeps one of these registers in a
|
|||
hard to get at place; for example, part in a segment register and part
|
||||
in an ordinary register.
|
||||
|
||||
@item TARGET_SHORT_BIT
|
||||
defs.h
|
||||
@item TDESC
|
||||
infrun.c
|
||||
@item T_ARG
|
||||
coffread.c
|
||||
@item T_VOID
|
||||
|
@ -2522,10 +2523,6 @@ i386-xdep.c
|
|||
dbxread.c
|
||||
@item WRS_ORIG
|
||||
remote-vx.c
|
||||
@item _LANG_c
|
||||
language.c
|
||||
@item _LANG_m2
|
||||
language.c
|
||||
@item __GO32__
|
||||
inflow.c
|
||||
@item __HPUX_ASM__
|
||||
|
@ -2548,14 +2545,14 @@ m68k-stub.c
|
|||
ns32k-opcode.h
|
||||
@item sgi
|
||||
mips-tdep.c
|
||||
@item sparc
|
||||
regex.c
|
||||
@item sun
|
||||
m68k-tdep.c
|
||||
@item sun386
|
||||
tm-sun386.h
|
||||
|
||||
@item test
|
||||
(Define this to enable testing code in regex.c.)
|
||||
|
||||
@end table
|
||||
|
||||
@node Native Conditionals
|
||||
|
@ -2567,9 +2564,11 @@ are the same. These macros should be defined (or left undefined)
|
|||
in @file{nm-@var{system}.h}.
|
||||
|
||||
@table @code
|
||||
|
||||
@item ATTACH_DETACH
|
||||
If defined, then gdb will include support for the @code{attach} and
|
||||
If defined, then GDB will include support for the @code{attach} and
|
||||
@code{detach} commands.
|
||||
|
||||
@item FETCH_INFERIOR_REGISTERS
|
||||
Define this if the native-dependent code will provide its
|
||||
own routines
|
||||
|
@ -2578,6 +2577,7 @@ own routines
|
|||
If this symbol is @emph{not} defined, and @file{infptrace.c}
|
||||
is included in this configuration, the default routines in
|
||||
@file{infptrace.c} are used for these functions.
|
||||
|
||||
@item GET_LONGJMP_TARGET
|
||||
For most machines, this is a target-dependent parameter. On the DECstation
|
||||
and the Iris, this is a native-dependent parameter, since <setjmp.h> is
|
||||
|
@ -2587,22 +2587,32 @@ This macro determines the target PC address that longjmp() will jump
|
|||
to, assuming that we have just stopped at a longjmp breakpoint. It
|
||||
takes a CORE_ADDR * as argument, and stores the target PC value through
|
||||
this pointer. It examines the current state of the machine as needed.
|
||||
|
||||
@item PROC_NAME_FMT
|
||||
Defines the format for the name of a @file{/proc} device. Should be
|
||||
defined in @file{nm.h} @emph{only} in order to override the default
|
||||
definition in @file{procfs.c}.
|
||||
|
||||
@item PTRACE_FP_BUG
|
||||
mach386-xdep.c
|
||||
|
||||
@item PTRACE_ARG3_TYPE
|
||||
The type of the third argument to the @code{ptrace} system call, if it exists
|
||||
and is different from @code{int}.
|
||||
|
||||
@item REGISTER_U_ADDR
|
||||
Defines the offset of the registers in the ``u area''; @pxref{Host}.
|
||||
|
||||
@item SOLIB_CREATE_INFERIOR_HOOK
|
||||
Define this to expand into any shared-library-relocation code
|
||||
that you want to be run just after the child process has been forked.
|
||||
|
||||
@item USE_PROC_FS
|
||||
This determines whether small routines in @file{*-tdep.c}, which
|
||||
translate register values
|
||||
between GDB's internal representation and the /proc representation,
|
||||
are compiled.
|
||||
|
||||
@item U_REGS_OFFSET
|
||||
This is the offset of the registers in the upage. It need only be
|
||||
defined if the generic ptrace register access routines in
|
||||
|
@ -2614,6 +2624,7 @@ from @file{infptrace.c} is good enough, leave it undefined.
|
|||
The default value means that u.u_ar0 @emph{points to} the location of the
|
||||
registers. I'm guessing that @code{#define U_REGS_OFFSET 0} means that
|
||||
u.u_ar0 @emph{is} the location of the registers.
|
||||
|
||||
@end table
|
||||
|
||||
@node Obsolete Conditionals
|
||||
|
|
|
@ -0,0 +1,155 @@
|
|||
@ignore
|
||||
This file is completely identical to hsuser.texinfo, except that it has the
|
||||
reference to the programming manual removed. There are definately better ways
|
||||
to do this!
|
||||
|
||||
This file documents the user interface to the GNU History library.
|
||||
|
||||
Copyright (C) 1988, 1991 Free Software Foundation, Inc.
|
||||
Authored by Brian Fox.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this manual
|
||||
provided the copyright notice and this permission notice are preserved on
|
||||
all copies.
|
||||
|
||||
Permission is granted to process this file through Tex and print the
|
||||
results, provided the printed document carries copying permission notice
|
||||
identical to this one except for the removal of this paragraph (this
|
||||
paragraph not being relevant to the printed manual).
|
||||
|
||||
Permission is granted to copy and distribute modified versions of this
|
||||
manual under the conditions for verbatim copying, provided also that the
|
||||
GNU Copyright statement is available to the distributee, and provided that
|
||||
the entire resulting derived work is distributed under the terms of a
|
||||
permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this manual
|
||||
into another language, under the above conditions for modified versions.
|
||||
@end ignore
|
||||
|
||||
@node Using History Interactively
|
||||
@appendix Using History Interactively
|
||||
|
||||
This chapter describes how to use the GNU History Library interactively,
|
||||
from a user's standpoint.
|
||||
|
||||
@menu
|
||||
* History Interaction:: What it feels like using History as a user.
|
||||
@end menu
|
||||
|
||||
@node History Interaction
|
||||
@section History Interaction
|
||||
@cindex expansion
|
||||
|
||||
The History library provides a history expansion feature that is similar
|
||||
to the history expansion in Csh. The following text describes the sytax
|
||||
that you use to manipulate the history information.
|
||||
|
||||
History expansion takes place in two parts. The first is to determine
|
||||
which line from the previous history should be used during substitution.
|
||||
The second is to select portions of that line for inclusion into the
|
||||
current one. The line selected from the previous history is called the
|
||||
@dfn{event}, and the portions of that line that are acted upon are
|
||||
called @dfn{words}. The line is broken into words in the same fashion
|
||||
that the Bash shell does, so that several English (or Unix) words
|
||||
surrounded by quotes are considered as one word.
|
||||
|
||||
@menu
|
||||
* Event Designators:: How to specify which history line to use.
|
||||
* Word Designators:: Specifying which words are of interest.
|
||||
* Modifiers:: Modifying the results of susbstitution.
|
||||
@end menu
|
||||
|
||||
@node Event Designators
|
||||
@subsection Event Designators
|
||||
@cindex event designators
|
||||
|
||||
An event designator is a reference to a command line entry in the
|
||||
history list.
|
||||
|
||||
@table @asis
|
||||
|
||||
@item @code{!}
|
||||
Start a history subsititution, except when followed by a space, tab, or
|
||||
the end of the line... @key{=} or @key{(}.
|
||||
|
||||
@item @code{!!}
|
||||
Refer to the previous command. This is a synonym for @code{!-1}.
|
||||
|
||||
@item @code{!n}
|
||||
Refer to command line @var{n}.
|
||||
|
||||
@item @code{!-n}
|
||||
Refer to the command line @var{n} lines back.
|
||||
|
||||
@item @code{!string}
|
||||
Refer to the most recent command starting with @var{string}.
|
||||
|
||||
@item @code{!?string}[@code{?}]
|
||||
Refer to the most recent command containing @var{string}.
|
||||
|
||||
@end table
|
||||
|
||||
@node Word Designators
|
||||
@subsection Word Designators
|
||||
|
||||
A @key{:} separates the event specification from the word designator. It
|
||||
can be omitted if the word designator begins with a @key{^}, @key{$},
|
||||
@key{*} or @key{%}. Words are numbered from the beginning of the line,
|
||||
with the first word being denoted by a 0 (zero).
|
||||
|
||||
@table @code
|
||||
|
||||
@item 0 (zero)
|
||||
The zero'th word. For many applications, this is the command word.
|
||||
|
||||
@item n
|
||||
The @var{n}'th word.
|
||||
|
||||
@item ^
|
||||
The first argument. that is, word 1.
|
||||
|
||||
@item $
|
||||
The last argument.
|
||||
|
||||
@item %
|
||||
The word matched by the most recent @code{?string?} search.
|
||||
|
||||
@item x-y
|
||||
A range of words; @code{-@var{y}} Abbreviates @code{0-@var{y}}.
|
||||
|
||||
@item *
|
||||
All of the words, excepting the zero'th. This is a synonym for @code{1-$}.
|
||||
It is not an error to use @key{*} if there is just one word in the event.
|
||||
The empty string is returned in that case.
|
||||
|
||||
@end table
|
||||
|
||||
@node Modifiers
|
||||
@subsection Modifiers
|
||||
|
||||
After the optional word designator, you can add a sequence of one or more
|
||||
of the following modifiers, each preceded by a @key{:}.
|
||||
|
||||
@table @code
|
||||
|
||||
@item #
|
||||
The entire command line typed so far. This means the current command,
|
||||
not the previous command, so it really isn't a word designator, and doesn't
|
||||
belong in this section.
|
||||
|
||||
@item h
|
||||
Remove a trailing pathname component, leaving only the head.
|
||||
|
||||
@item r
|
||||
Remove a trailing suffix of the form @samp{.}@var{suffix}, leaving the basename.
|
||||
|
||||
@item e
|
||||
Remove all but the suffix.
|
||||
|
||||
@item t
|
||||
Remove all leading pathname components, leaving the tail.
|
||||
|
||||
@item p
|
||||
Print the new command but do not execute it.
|
||||
@end table
|
|
@ -69,13 +69,13 @@ For @sc{sparc} architectures.
|
|||
@item m68k-stub.c
|
||||
@kindex m68k-stub.c
|
||||
@cindex Motorola 680x0
|
||||
@cindex 680x0
|
||||
@cindex m680x0
|
||||
For Motorola 680x0 architectures.
|
||||
|
||||
@item i386-stub.c
|
||||
@kindex i386-stub.c
|
||||
@cindex Intel
|
||||
@cindex 386
|
||||
@cindex i386
|
||||
For Intel 386 and compatible architectures.
|
||||
@end table
|
||||
|
||||
|
@ -131,12 +131,12 @@ Use this auxiliary subroutine to make your program contain a
|
|||
breakpoint. Depending on the particular situation, this may be the only
|
||||
way for @value{GDBN} to get control. For instance, if your target
|
||||
machine has some sort of interrupt button, you won't need to call this;
|
||||
pressing the interrupt button will transfer control to
|
||||
pressing the interrupt button transfers control to
|
||||
@code{handle_exception}---in effect, to @value{GDBN}. On some machines,
|
||||
simply receiving characters on the serial port may also trigger a trap;
|
||||
again, in that situation, you don't need to call @code{breakpoint} from
|
||||
your own program---simply running @samp{target remote} from the host
|
||||
@value{GDBN} session will get control.
|
||||
@value{GDBN} session gets control.
|
||||
|
||||
Call @code{breakpoint} if none of these is true, or if you simply want
|
||||
to make certain your program stops at a predetermined point for the
|
||||
|
@ -149,8 +149,10 @@ start of your debugging session.
|
|||
@cindex remote stub, support routines
|
||||
The debugging stubs that come with @value{GDBN} are set up for a particular
|
||||
chip architecture, but they have no information about the rest of your
|
||||
debugging target machine. To allow the stub to work, you must supply
|
||||
these special low-level subroutines:
|
||||
debugging target machine.
|
||||
|
||||
First of all you need to tell the stub how to communicate with the
|
||||
serial port.
|
||||
|
||||
@table @code
|
||||
@item int getDebugChar()
|
||||
|
@ -164,7 +166,24 @@ different name is used to allow you to distinguish the two if you wish.
|
|||
Write this subroutine to write a single character to the serial port.
|
||||
It may be identical to @code{putchar} for your target system; a
|
||||
different name is used to allow you to distinguish the two if you wish.
|
||||
@end table
|
||||
|
||||
@cindex control C, and remote debugging
|
||||
@cindex interrupting remote targets
|
||||
If you want @value{GDBN} to be able to stop your program while it is
|
||||
running, you need to use an interrupt-driven serial driver, and arrange
|
||||
for it to stop when it receives a @code{^C} (@samp{\003}, the control-C
|
||||
character). That is the character which @value{GDBN} uses to tell the
|
||||
remote system to stop.
|
||||
|
||||
Getting the debugging target to return the proper status to @value{GDBN}
|
||||
probably requires changes to the standard stub; one quick and dirty way
|
||||
is to just execute a breakpoint instruction (the ``dirty'' part is that
|
||||
@value{GDBN} reports a @code{SIGTRAP} instead of a @code{SIGINT}).
|
||||
|
||||
Other routines you need to supply are:
|
||||
|
||||
@table @code
|
||||
@item void exceptionHandler (int @var{exception_number}, void *@var{exception_address})
|
||||
@kindex exceptionHandler
|
||||
Write this function to install @var{exception_address} in the exception
|
||||
|
@ -177,7 +196,7 @@ its meaning is architecture-dependent (for example, different numbers
|
|||
might represent divide by zero, misaligned access, etc). When this
|
||||
exception occurs, control should be transferred directly to
|
||||
@var{exception_address}, and the processor state (stack, registers,
|
||||
etc.) should be just as it is when a processor exception occurs. So if
|
||||
and so on) should be just as it is when a processor exception occurs. So if
|
||||
you want to use a jump instruction to reach @var{exception_address}, it
|
||||
should be a simple jump, not a jump to subroutine.
|
||||
|
||||
|
@ -210,7 +229,7 @@ either obtain it from your hardware manufacturer, or write your own.
|
|||
@end table
|
||||
|
||||
If you do not use the GNU C compiler, you may need other standard
|
||||
library subroutines as well; this will vary from one stub to another,
|
||||
library subroutines as well; this varies from one stub to another,
|
||||
but in general the stubs are likely to use any of the common library
|
||||
subroutines which @code{gcc} generates as inline code.
|
||||
|
||||
|
@ -320,7 +339,7 @@ remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
|
|||
goes back to waiting.
|
||||
|
||||
@node Protocol
|
||||
@subsubsection Outline of the communication protocol
|
||||
@subsubsection Communication protocol
|
||||
|
||||
@cindex debugging stub, example
|
||||
@cindex remote stub, example
|
||||
|
@ -382,10 +401,12 @@ Read @var{count} bytes at location @var{addr}.
|
|||
@item M@var{addr},@var{count}:@dots{}
|
||||
Write @var{count} bytes at location @var{addr}.
|
||||
|
||||
@need 500
|
||||
@item c
|
||||
@itemx c@var{addr}
|
||||
Resume execution at the current address (or at @var{addr} if supplied).
|
||||
|
||||
@need 500
|
||||
@item s
|
||||
@itemx s@var{addr}
|
||||
Step the target program for one instruction, from either the current
|
||||
|
@ -409,7 +430,7 @@ If you have trouble with the serial connection, you can use the command
|
|||
back and forth across the serial line to the remote machine. The
|
||||
packet-debugging information is printed on the @value{GDBN} standard output
|
||||
stream. @code{set remotedebug off} turns it off, and @code{show
|
||||
remotedebug} will show you its current state.
|
||||
remotedebug} shows you its current state.
|
||||
|
||||
@ifset GDBSERVER
|
||||
@node Server
|
||||
|
@ -425,23 +446,28 @@ allows you to connect your program with a remote @value{GDBN} via
|
|||
because it requires essentially the same operating-system facilities
|
||||
that @value{GDBN} itself does. In fact, a system that can run
|
||||
@code{gdbserver} to connect to a remote @value{GDBN} could also run
|
||||
@var{GDBN} locally! @code{gdbserver} is sometimes useful nevertheless,
|
||||
@value{GDBN} locally! @code{gdbserver} is sometimes useful nevertheless,
|
||||
because it is a much smaller program than @value{GDBN} itself. It is
|
||||
also easier to port than all of @var{GDBN}, so you may be able to get
|
||||
also easier to port than all of @value{GDBN}, so you may be able to get
|
||||
started more quickly on a new system by using @code{gdbserver}.
|
||||
Finally, if you develop code for real-time systems, you may find that
|
||||
the tradeoffs involved in real-time operation make it more convenient to
|
||||
do as much development work as possible on another system, for example
|
||||
by cross-compiling. You can use @code{gdbserver} to make a similar
|
||||
choice for debugging.
|
||||
|
||||
@value{GDBN} and @code{gdbserver} communicate via either a serial line
|
||||
or a TCP connection, using the standard @value{GDBN} remote serial
|
||||
protocol.
|
||||
|
||||
@table @emph
|
||||
@item On the target,
|
||||
@item On the target machine,
|
||||
you need to have a copy of the program you want to debug.
|
||||
@code{gdbserver} does not need your program's symbol table, so you can
|
||||
strip the program if necessary to save space. @value{GDBN} on the host
|
||||
system does all the symbol handling.
|
||||
|
||||
To use the server, you must tell it how to communicate with @value{GDB};
|
||||
To use the server, you must tell it how to communicate with @value{GDBN};
|
||||
the name of your program; and the arguments for your program. The
|
||||
syntax is:
|
||||
|
||||
|
@ -450,7 +476,7 @@ target> gdbserver @var{comm} @var{program} [ @var{args} @dots{} ]
|
|||
@end smallexample
|
||||
|
||||
@var{comm} is either a device name (to use a serial line) or a TCP
|
||||
hostname and portnumber. For example, to debug emacs with the argument
|
||||
hostname and portnumber. For example, to debug Emacs with the argument
|
||||
@samp{foo.txt} and communicate with @value{GDBN} over the serial port
|
||||
@file{/dev/com1}:
|
||||
|
||||
|
@ -473,20 +499,22 @@ TCP. The @samp{host:2345} argument means that @code{gdbserver} is to
|
|||
expect a TCP connection from machine @samp{host} to local TCP port 2345.
|
||||
(Currently, the @samp{host} part is ignored.) You can choose any number
|
||||
you want for the port number as long as it does not conflict with any
|
||||
TCP ports already in use on the target system.@footnote{If you choose a
|
||||
port number that conflicts with another service, @code{gdbserver} prints
|
||||
an error message and exits.} You must use the same port number with the
|
||||
host @value{GDBN} @code{target remote} command.
|
||||
TCP ports already in use on the target system (for example, @code{23} is
|
||||
reserved for @code{telnet}).@footnote{If you choose a port number that
|
||||
conflicts with another service, @code{gdbserver} prints an error message
|
||||
and exits.} You must use the same port number with the host @value{GDBN}
|
||||
@code{target remote} command.
|
||||
|
||||
@item On the host,
|
||||
you need an unstripped copy of your program, since
|
||||
@value{GDBN} needs symbols and debugging information. Start up
|
||||
@value{GDBN} as usual, using the name of the local copy of your program
|
||||
as the first argument. (You may also need the
|
||||
@samp{--baud} option if the serial line is running at anything other than 9600 bps.)
|
||||
After that, use @code{target remote} to establish communications with @code{gdbserver}. Its argument is either
|
||||
a device name (usually a serial device, like @file{/dev/ttyb}), or a TCP
|
||||
port descriptof in the form @code{@var{host}:@var{PORT}}. For example:
|
||||
@item On the @value{GDBN} host machine,
|
||||
you need an unstripped copy of your program, since @value{GDBN} needs
|
||||
symbols and debugging information. Start up @value{GDBN} as usual,
|
||||
using the name of the local copy of your program as the first argument.
|
||||
(You may also need the @w{@samp{--baud}} option if the serial line is
|
||||
running at anything other than 9600 bps.) After that, use @code{target
|
||||
remote} to establish communications with @code{gdbserver}. Its argument
|
||||
is either a device name (usually a serial device, like
|
||||
@file{/dev/ttyb}), or a TCP port descriptor in the form
|
||||
@code{@var{host}:@var{PORT}}. For example:
|
||||
|
||||
@smallexample
|
||||
(@value{GDBP}) target remote /dev/ttyb
|
||||
|
@ -500,7 +528,7 @@ communicates with the server via serial line @file{/dev/ttyb}, and
|
|||
@end smallexample
|
||||
|
||||
@noindent
|
||||
communicates via a TCP connection to port 2345 on host @file{the-target}.
|
||||
communicates via a TCP connection to port 2345 on host @w{@file{the-target}}.
|
||||
For TCP connections, you must start up @code{gdbserver} prior to using
|
||||
the @code{target remote} command. Otherwise you may get an error whose
|
||||
text depends on the host system, but which usually looks something like
|
||||
|
@ -617,7 +645,7 @@ a break is detected.
|
|||
|
||||
@ifset AMD29K
|
||||
@node UDI29K Remote
|
||||
@subsection @value{GDBN} and the UDI protocol for AMD29K
|
||||
@subsection The UDI protocol for AMD29K
|
||||
|
||||
@cindex UDI
|
||||
@cindex AMD29K via UDI
|
||||
|
@ -640,7 +668,7 @@ to its pathname.
|
|||
@end table
|
||||
|
||||
@node EB29K Remote
|
||||
@subsection @value{GDBN} and the EBMON protocol for AMD29K
|
||||
@subsection The EBMON protocol for AMD29K
|
||||
|
||||
@cindex EB29K board
|
||||
@cindex running 29K programs
|
||||
|
@ -760,7 +788,7 @@ Byte Write Available = Yes
|
|||
@end example
|
||||
|
||||
Then exit the @code{cu} or @code{tip} program (done in the example by
|
||||
typing @code{~.} at the @code{EBMON} prompt). @code{EBMON} will keep
|
||||
typing @code{~.} at the @code{EBMON} prompt). @code{EBMON} keeps
|
||||
running, ready for @value{GDBN} to take over.
|
||||
|
||||
For this example, we've assumed what is probably the most convenient
|
||||
|
@ -769,7 +797,7 @@ system: a PC/NFS connection that establishes ``drive @code{G:}'' on the
|
|||
PC as a file system on the Unix host. If you do not have PC/NFS or
|
||||
something similar connecting the two systems, you must arrange some
|
||||
other way---perhaps floppy-disk transfer---of getting the 29K program
|
||||
from the Unix system to the PC; @value{GDBN} will @emph{not} download it over the
|
||||
from the Unix system to the PC; @value{GDBN} does @emph{not} download it over the
|
||||
serial line.
|
||||
|
||||
@node gdb-EB29K
|
||||
|
@ -784,6 +812,7 @@ cd /usr/joe/work29k
|
|||
@value{GDBP} myfoo
|
||||
@end example
|
||||
|
||||
@need 500
|
||||
Now you can use the @code{target} command:
|
||||
|
||||
@example
|
||||
|
@ -849,7 +878,7 @@ concentrator) using the syntax @code{@var{hostname}:@var{portnumber}}.
|
|||
|
||||
The @code{load} and @code{attach} commands are @emph{not} defined for
|
||||
this target; you must load your program into the ST2000 as you normally
|
||||
would for standalone operation. @value{GDBN} will read debugging information
|
||||
would for standalone operation. @value{GDBN} reads debugging information
|
||||
(such as symbols) from a separate, debugging version of the program
|
||||
available on your host computer.
|
||||
@c FIXME!! This is terribly vague; what little content is here is
|
||||
|
@ -871,7 +900,7 @@ manual for available commands.
|
|||
@cindex connect (to STDBUG)
|
||||
Connect the controlling terminal to the STDBUG command monitor. When
|
||||
you are done interacting with STDBUG, typing either of two character
|
||||
sequences will get you back to the @value{GDBN} command prompt:
|
||||
sequences gets you back to the @value{GDBN} command prompt:
|
||||
@kbd{@key{RET}~.} (Return, followed by tilde and period) or
|
||||
@kbd{@key{RET}~@key{C-d}} (Return, followed by tilde and control-D).
|
||||
@end table
|
||||
|
@ -894,23 +923,21 @@ The following information on connecting to VxWorks was current when
|
|||
this manual was produced; newer releases of VxWorks may use revised
|
||||
procedures.
|
||||
|
||||
The remote debugging interface (RDB) routines are installed and executed
|
||||
on the VxWorks target. These routines are included in the VxWorks library
|
||||
@file{rdb.a} and are incorporated into the system image when source-level
|
||||
debugging is enabled in the VxWorks configuration.
|
||||
|
||||
@kindex INCLUDE_RDB
|
||||
If you wish, you can define @code{INCLUDE_RDB} in the VxWorks
|
||||
configuration file @file{configAll.h} to include the RDB interface
|
||||
routines and spawn the source debugging task @code{tRdbTask} when
|
||||
VxWorks is booted. For more information on configuring and remaking
|
||||
VxWorks, see the manufacturer's manual.
|
||||
To use @value{GDBN} with VxWorks, you must rebuild your VxWorks kernel
|
||||
to include the remote debugging interface routines in the VxWorks
|
||||
library @file{rdb.a}. To do this, define @code{INCLUDE_RDB} in the
|
||||
VxWorks configuration file @file{configAll.h} and rebuild your VxWorks
|
||||
kernel. The resulting kernel contains @file{rdb.a}, and spawns the
|
||||
source debugging task @code{tRdbTask} when VxWorks is booted. For more
|
||||
information on configuring and remaking VxWorks, see the manufacturer's
|
||||
manual.
|
||||
@c VxWorks, see the @cite{VxWorks Programmer's Guide}.
|
||||
|
||||
Once you have included the RDB interface in your VxWorks system image
|
||||
and set your Unix execution search path to find @value{GDBN}, you are ready
|
||||
to run @value{GDBN}. From your Unix host, run @code{gdb} (or
|
||||
@code{vxgdb}, depending on your installation).
|
||||
Once you have included @file{rdb.a} in your VxWorks system image and set
|
||||
your Unix execution search path to find @value{GDBN}, you are ready to
|
||||
run @value{GDBN}. From your Unix host, run @code{gdb} (or @code{vxgdb},
|
||||
depending on your installation).
|
||||
|
||||
@value{GDBN} comes up showing the prompt:
|
||||
|
||||
|
@ -934,6 +961,7 @@ network. To connect to a target whose host name is ``@code{tt}'', type:
|
|||
(vxgdb) target vxworks tt
|
||||
@end example
|
||||
|
||||
@need 750
|
||||
@value{GDBN} displays messages like these:
|
||||
|
||||
@smallexample
|
||||
|
@ -941,6 +969,7 @@ Attaching remote machine across net...
|
|||
Connected to tt.
|
||||
@end smallexample
|
||||
|
||||
@need 1000
|
||||
@value{GDBN} then attempts to read the symbol tables of any object modules
|
||||
loaded into the VxWorks target since it was last booted. @value{GDBN} locates
|
||||
these files by searching the directories listed in the command search
|
||||
|
@ -994,7 +1023,7 @@ Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
|
|||
|
||||
You can also use the @code{load} command to reload an object module
|
||||
after editing and recompiling the corresponding source file. Note that
|
||||
this will cause @value{GDBN} to delete all currently-defined breakpoints,
|
||||
this makes @value{GDBN} delete all currently-defined breakpoints,
|
||||
auto-displays, and convenience variables, and to clear the value
|
||||
history. (This is necessary in order to preserve the integrity of
|
||||
debugger data structures that reference the target system's symbol
|
||||
|
@ -1013,33 +1042,44 @@ follows:
|
|||
|
||||
@noindent
|
||||
where @var{task} is the VxWorks hexadecimal task ID. The task can be running
|
||||
or suspended when you attach to it. If running, it will be suspended at
|
||||
or suspended when you attach to it. Running tasks are suspended at
|
||||
the time of attachment.
|
||||
@end ifset
|
||||
|
||||
@ifset H8
|
||||
@node Hitachi Remote
|
||||
@subsection @value{GDBN} and Hitachi Microprocessors
|
||||
@subsection @value{GDBN} and Hitachi microprocessors
|
||||
@value{GDBN} needs to know these things to talk to your
|
||||
Hitachi SH, H8/300, or H8/500:
|
||||
|
||||
@enumerate
|
||||
@item
|
||||
that you want to use @samp{target hms}, the remote debugging interface
|
||||
for Hitachi microprocessors (this is the default when GDB is configured
|
||||
specifically for the Hitachi SH, H8/300, or H8/500);
|
||||
for Hitachi microprocessors, or @samp{target e7000}, the in-circuit
|
||||
emulator for the Hitachi SH and the Hitachi 300H. (@samp{target hms} is
|
||||
the default when GDB is configured specifically for the Hitachi SH,
|
||||
H8/300, or H8/500.)
|
||||
|
||||
@item
|
||||
what serial device connects your host to your Hitachi board (the first
|
||||
serial device available on your host is the default);
|
||||
serial device available on your host is the default).
|
||||
|
||||
@ignore
|
||||
@c this is only for Unix hosts, not currently of interest.
|
||||
@ifclear H8EXCLUSIVE
|
||||
@c this is only for Unix hosts, not of interest to Hitachi
|
||||
@item
|
||||
what speed to use over the serial device.
|
||||
@end ignore
|
||||
@end ifclear
|
||||
@end enumerate
|
||||
|
||||
@menu
|
||||
* Hitachi Boards:: Connecting to Hitachi boards.
|
||||
* Hitachi ICE:: Using the E7000 In-Circuit Emulator.
|
||||
* Hitachi Special:: Special @value{GDBN} commands for Hitachi micros.
|
||||
@end menu
|
||||
|
||||
@node Hitachi Boards
|
||||
@subsubsection Connecting to Hitachi boards
|
||||
|
||||
@ifclear H8EXCLUSIVE
|
||||
@c only for Unix hosts
|
||||
@kindex device
|
||||
|
@ -1150,9 +1190,55 @@ normally. The communications protocol provides no other way for @value{GDBN}
|
|||
to detect program completion.
|
||||
@end itemize
|
||||
|
||||
In either case, @value{GDBN} will see the effect of a @sc{reset} on the
|
||||
In either case, @value{GDBN} sees the effect of a @sc{reset} on the
|
||||
development board as a ``normal exit'' of your program.
|
||||
@end ifset
|
||||
|
||||
@node Hitachi ICE
|
||||
@subsubsection Using the E7000 in-circuit emulator
|
||||
|
||||
@kindex target e7000
|
||||
You can use the E7000 in-circuit emulator to develop code for either the
|
||||
Hitachi SH or the H8/300H. Use one of these forms of the @samp{target
|
||||
e7000} command to connect @value{GDBN} to your E7000:
|
||||
|
||||
@table @code
|
||||
@item target e7000 @var{port} @var{speed}
|
||||
Use this form if your E7000 is connected to a serial port. The
|
||||
@var{port} argument identifies what serial port to use (for example,
|
||||
@samp{com2}). The third argument is the line speed in bits per second
|
||||
(for example, @samp{9600}).
|
||||
|
||||
@item target e7000 @var{hostname}
|
||||
If your E7000 is installed as a host on a TCP/IP network, you can just
|
||||
specify its hostname; @value{GDBN} uses @code{telnet} to connect.
|
||||
@end table
|
||||
|
||||
@node Hitachi Special
|
||||
@subsubsection Special @value{GDBN} commands for Hitachi micros
|
||||
|
||||
Some @value{GDBN} commands are available only on the H8/300 or the
|
||||
H8/500 configurations:
|
||||
|
||||
@table @code
|
||||
@kindex set machine
|
||||
@kindex show machine
|
||||
@item set machine h8300
|
||||
@itemx set machine h8300h
|
||||
Condition @value{GDBN} for one of the two variants of the H8/300
|
||||
architecture with @samp{set machine}. You can use @samp{show machine}
|
||||
to check which variant is currently in effect.
|
||||
|
||||
@kindex set memory @var{mod}
|
||||
@cindex memory models, H8/500
|
||||
@item set memory @var{mod}
|
||||
@itemx show memory
|
||||
Specify which H8/500 memory model (@var{mod}) you are using with
|
||||
@samp{set memory}; check which memory model is in effect with @samp{show
|
||||
memory}. The accepted values for @var{mod} are @code{small},
|
||||
@code{big}, @code{medium}, and @code{compact}.
|
||||
@end table
|
||||
|
||||
@end ifset
|
||||
|
||||
@ifset MIPS
|
||||
|
@ -1164,6 +1250,11 @@ development board as a ``normal exit'' of your program.
|
|||
MIPS board attached to a serial line. This is available when
|
||||
you configure @value{GDBN} with @samp{--target=mips-idt-ecoff}.
|
||||
|
||||
@need 1000
|
||||
Use these @value{GDBN} commands to specify the connection to your target board:
|
||||
|
||||
@table @code
|
||||
@item target mips @var{port}
|
||||
@kindex target mips @var{port}
|
||||
To run a program on the board, start up @code{@value{GDBP}} with the
|
||||
name of your program as the argument. To connect to the board, use the
|
||||
|
@ -1172,19 +1263,62 @@ the serial port connected to the board. If the program has not already
|
|||
been downloaded to the board, you may use the @code{load} command to
|
||||
download it. You can then use all the usual @value{GDBN} commands.
|
||||
|
||||
You can also specify @var{port} as a TCP connection (for instance, to a
|
||||
serial line managed by a terminal concentrator), using the syntax
|
||||
@code{@var{hostname}:@var{portnumber}}.
|
||||
For example, this sequence connects to the target board through a serial
|
||||
port, and loads and runs a program called @var{prog} through the
|
||||
debugger:
|
||||
|
||||
@example
|
||||
host$ @value{GDBP} @var{prog}
|
||||
GDB is free software and @dots{}
|
||||
(gdb) target mips /dev/ttyb
|
||||
(gdb) load @var{prog}
|
||||
(gdb) run
|
||||
@end example
|
||||
|
||||
@item target mips @var{hostname}:@var{portnumber}
|
||||
On some @value{GDBN} host configurations, you can specify a TCP
|
||||
connection (for instance, to a serial line managed by a terminal
|
||||
concentrator) instead of a serial port, using the syntax
|
||||
@samp{@var{hostname}:@var{portnumber}}.
|
||||
@end table
|
||||
|
||||
@noindent
|
||||
@value{GDBN} also supports these special commands for MIPS targets:
|
||||
|
||||
@table @code
|
||||
@item set mipsfpu off
|
||||
@itemx show mipsfpu
|
||||
@kindex set mipsfpu off
|
||||
@kindex show mipsfpu
|
||||
@cindex MIPS remote floating point
|
||||
@cindex floating point, MIPS remote
|
||||
If your target board does not support the MIPS floating point
|
||||
coprocessor, you should use the command @samp{set mipsfpu off} (if you
|
||||
need this, you may wish to put the command in your @value{GDBINIT}
|
||||
file). This tells @value{GDBN} how to find the return value of
|
||||
functions which return floating point values. It also allows
|
||||
@value{GDBN} to avoid saving the floating point registers when calling
|
||||
functions on the board. (As usual, you can inquire about the
|
||||
@code{mipsfpu} variable with @samp{show mipsfpu}.)
|
||||
|
||||
@item set remotedebug @var{n}
|
||||
@itemx show remotedebug
|
||||
@kindex set remotedebug
|
||||
@kindex show remotedebug
|
||||
@cindex @code{remotedebug}, MIPS protocol
|
||||
@cindex MIPS @code{remotedebug} protocol
|
||||
@c FIXME! For this to be useful, you must know something about the MIPS
|
||||
@c FIXME...protocol. Where is it described?
|
||||
You can see some debugging information about communications with the board
|
||||
by setting the @code{remotedebug} variable. If you set it to 1 using
|
||||
@samp{set remotedebug 1} every packet will be displayed. If you set it
|
||||
to 2 every character will be displayed. You can check the current value
|
||||
by setting the @code{remotedebug} variable. If you set it to @code{1} using
|
||||
@samp{set remotedebug 1}, every packet is displayed. If you set it
|
||||
to @code{2}, every character is displayed. You can check the current value
|
||||
at any time with the command @samp{show remotedebug}.
|
||||
|
||||
@item set timeout @var{seconds}
|
||||
@itemx set retransmit-timeout @var{seconds}
|
||||
@itemx show timeout
|
||||
@itemx show retransmit-timeout
|
||||
@cindex @code{timeout}, MIPS protocol
|
||||
@cindex @code{retransmit-timeout}, MIPS protocol
|
||||
@kindex set timeout
|
||||
|
@ -1200,15 +1334,11 @@ You can inspect both values with @code{show timeout} and @code{show
|
|||
retransmit-timeout}. (These commands are @emph{only} available when
|
||||
@value{GDBN} is configured for @samp{--target=mips-idt-ecoff}.)
|
||||
|
||||
@kindex set mipsfpu off
|
||||
@cindex MIPS remote floating point
|
||||
@cindex floating point, MIPS remote
|
||||
If your target board does not support the MIPS floating point
|
||||
coprocessor, you should use the command @samp{set mipsfpu off} (you may
|
||||
wish to put this in your @value{GDBINIT} file). This tells @value{GDBN}
|
||||
how to find the return value of functions which return floating point
|
||||
values. It also allows @value{GDBN} to avoid saving the floating point
|
||||
registers when calling functions on the board.
|
||||
The timeout set by @code{set timeout} does not apply when @value{GDBN}
|
||||
is waiting for your program to stop. In that case, @value{GDBN} waits
|
||||
forever because it has no way of knowing how long the program is going
|
||||
to run before stopping.
|
||||
@end table
|
||||
@end ifset
|
||||
|
||||
@ifset SIMS
|
||||
|
@ -1289,6 +1419,6 @@ Execution time in 60ths of a second.
|
|||
|
||||
You can refer to these values in @value{GDBN} expressions with the usual
|
||||
conventions; for example, @w{@samp{b fputc if $cycles>5000}} sets a
|
||||
conditional breakpoint that will suspend only after at least 5000
|
||||
conditional breakpoint that suspends only after at least 5000
|
||||
simulated clock ticks.
|
||||
@end ifset
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
@ifinfo
|
||||
@format
|
||||
START-INFO-DIR-ENTRY
|
||||
* Stabs:: The "stabs" debugging information format.
|
||||
* Stabs: (stabs). The "stabs" debugging information format.
|
||||
END-INFO-DIR-ENTRY
|
||||
@end format
|
||||
@end ifinfo
|
||||
|
@ -43,7 +43,7 @@ regarded as a program in the language TeX).
|
|||
@page
|
||||
@tex
|
||||
\def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
|
||||
\xdef\manvers{\$Revision: 1.1.1.1 $} % For use in headers, footers too
|
||||
\xdef\manvers{\$Revision: 2.120 $} % For use in headers, footers too
|
||||
{\parskip=0pt
|
||||
\hfill Cygnus Support\par
|
||||
\hfill \manvers\par
|
||||
|
@ -84,7 +84,8 @@ This document describes the stabs debugging format.
|
|||
and GNU stabs in XCOFF
|
||||
* Sun Differences:: Differences between GNU stabs and Sun
|
||||
native stabs
|
||||
* Stabs In ELF:: Stabs in an ELF file.
|
||||
* Stab Sections:: In some object file formats, stabs are
|
||||
in sections.
|
||||
* Symbol Types Index:: Index of symbolic stab symbol type names.
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
@ -95,7 +96,7 @@ This document describes the stabs debugging format.
|
|||
|
||||
@dfn{Stabs} refers to a format for information that describes a program
|
||||
to a debugger. This format was apparently invented by
|
||||
@c FIXME! <<name of inventor>> at
|
||||
Peter Kessler at
|
||||
the University of California at Berkeley, for the @code{pdx} Pascal
|
||||
debugger; the format has spread widely since then.
|
||||
|
||||
|
@ -106,11 +107,14 @@ descriptors (@pxref{Type Descriptors}) are believed to be completely
|
|||
comprehensive. Stabs for COBOL-specific features and for variant
|
||||
records (used by Pascal and Modula-2) are poorly documented here.
|
||||
|
||||
@c FIXME: Need to document all OS9000 stuff in GDB; see all references
|
||||
@c to os9k_stabs in stabsread.c.
|
||||
|
||||
Other sources of information on stabs are @cite{Dbx and Dbxtool
|
||||
Interfaces}, 2nd edition, by Sun, 1988, and @cite{AIX Version 3.2 Files
|
||||
Reference}, Fourth Edition, September 1992, "dbx Stabstring Grammar" in
|
||||
the a.out section, page 2-31. This document is believed to incorporate
|
||||
the information from those two sources except where it explictly directs
|
||||
the information from those two sources except where it explicitly directs
|
||||
you to them for more information.
|
||||
|
||||
@menu
|
||||
|
@ -202,14 +206,14 @@ The overall format of the string field for most stab types is:
|
|||
"@var{name}:@var{symbol-descriptor} @var{type-information}"
|
||||
@end example
|
||||
|
||||
@var{name} is the name of the symbol represented by the stab.
|
||||
@var{name} can be omitted, which means the stab represents an unnamed
|
||||
object. For example, @samp{:t10=*2} defines type 10 as a pointer to
|
||||
type 2, but does not give the type a name. Omitting the @var{name}
|
||||
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.
|
||||
@var{name} is the name of the symbol represented by the stab; it can
|
||||
contain a pair of colons (@pxref{Nested Symbols}). @var{name} can be
|
||||
omitted, which means the stab represents an unnamed object. For
|
||||
example, @samp{:t10=*2} defines type 10 as a pointer to type 2, but does
|
||||
not give the type a name. Omitting the @var{name} 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.
|
||||
|
||||
The @var{symbol-descriptor} following the @samp{:} is an alphabetic
|
||||
character that tells more specifically what kind of symbol the stab
|
||||
|
@ -226,7 +230,9 @@ reference, referring directly to a type that has already been defined.
|
|||
The @samp{@var{type-number}=} 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{=} and nested definitions.
|
||||
may be followed by @samp{=} and nested definitions. Also, the Lucid
|
||||
compiler will repeat @samp{@var{type-number}=} more than once if it
|
||||
wants to define several type numbers at once.
|
||||
|
||||
In a type definition, if the character that follows the equals sign is
|
||||
non-numeric then it is a @var{type-descriptor}, and tells what kind of
|
||||
|
@ -250,9 +256,6 @@ those from the C++ type descriptor @samp{@@}. The attributes are:
|
|||
@var{boundary} is an integer specifying the alignment. I assume it
|
||||
applies to all variables of this type.
|
||||
|
||||
@item s@var{size}
|
||||
Size in bits of a variable of this type.
|
||||
|
||||
@item p@var{integer}
|
||||
Pointer class (for checking). Not sure what this means, or how
|
||||
@var{integer} is interpreted.
|
||||
|
@ -261,19 +264,31 @@ Pointer class (for checking). Not sure what this means, or how
|
|||
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.
|
||||
|
||||
@item s@var{size}
|
||||
Size in bits of a variable of this type. This is fully supported by GDB
|
||||
4.11 and later.
|
||||
|
||||
@item S
|
||||
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.
|
||||
@end table
|
||||
|
||||
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 cretinously limit the strings to
|
||||
about 80 characters, so compilers which must work with such dbx's need
|
||||
to split the @code{.stabs} directive into several @code{.stabs}
|
||||
directives. Each stab duplicates exactly all but the
|
||||
string field. The string field of
|
||||
every stab except the last is marked as continued with a
|
||||
double-backslash at the end. Removing the backslashes and concatenating
|
||||
the string fields of each stab produces the original,
|
||||
long string.
|
||||
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} directive
|
||||
into several @code{.stabs} 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{?} instead of backslash.
|
||||
|
||||
@node C Example
|
||||
@section A Simple Example in C Source
|
||||
|
@ -370,6 +385,7 @@ blocks of code.
|
|||
* Procedures::
|
||||
* Nested Procedures::
|
||||
* Block Structure::
|
||||
* Alternate Entry Points:: Entering procedures except at the beginning.
|
||||
@end menu
|
||||
|
||||
@node Main Program
|
||||
|
@ -472,10 +488,10 @@ file. @code{C_BINCL} and @code{C_EINCL} do not nest.
|
|||
|
||||
@findex N_SLINE
|
||||
An @code{N_SLINE} symbol represents the start of a source line. The
|
||||
desc field contains the line number and the value
|
||||
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
|
||||
to the function in which the @code{N_SLINE} symbol occurs.
|
||||
desc field contains the line number and the value contains the code
|
||||
address for the start of that source line. On most machines the address
|
||||
is absolute; for stabs in sections (@pxref{Stab Sections}), it is
|
||||
relative to the function in which the @code{N_SLINE} symbol occurs.
|
||||
|
||||
@findex N_DSLINE
|
||||
@findex N_BSLINE
|
||||
|
@ -517,7 +533,7 @@ one has complained).
|
|||
|
||||
A function is represented by an @samp{F} symbol descriptor for a global
|
||||
(extern) function, and @samp{f} for a static (local) function. The
|
||||
value is the address of the start of the function. For @code{a.out}, it
|
||||
value is the address of the start of the function. For a.out, 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
|
||||
|
@ -526,8 +542,8 @@ 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. See @ref{Stabs In ELF} for more information on linker
|
||||
relocation of stabs in ELF files.
|
||||
the file, or just absolute. See @ref{ELF Linker Relocation} for more
|
||||
information on linker relocation of stabs in ELF files.
|
||||
|
||||
The type information of the stab represents the return type of the
|
||||
function; thus @samp{foo:f5} means that foo is a function returning type
|
||||
|
@ -639,6 +655,11 @@ produces the stabs:
|
|||
|
||||
@findex N_LBRAC
|
||||
@findex N_RBRAC
|
||||
@c For GCC 2.5.8 or so stabs-in-coff, these are absolute instead of
|
||||
@c function relative (as documented below). But GDB has never been able
|
||||
@c to deal with that (it had wanted them to be relative to the file, but
|
||||
@c I just fixed that (between GDB 4.12 and 4.13)), so it is function
|
||||
@c relative just like ELF and SOM and the below documentation.
|
||||
The program's block structure is represented by the @code{N_LBRAC} (left
|
||||
brace) and the @code{N_RBRAC} (right brace) stab types. The variables
|
||||
defined inside a block precede the @code{N_LBRAC} symbol for most
|
||||
|
@ -648,8 +669,8 @@ RISC machine, and Sun @code{acc} compilers, put the variables after the
|
|||
@code{N_RBRAC} symbols are the start and end addresses of the code of
|
||||
the block, respectively. For most machines, they are relative to the
|
||||
starting address of this source file. For the Gould NP1, they are
|
||||
absolute. For Sun's stabs-in-ELF, they are relative to the function in
|
||||
which they occur.
|
||||
absolute. For stabs in sections (@pxref{Stab Sections}), they are
|
||||
relative to the function in which they occur.
|
||||
|
||||
The @code{N_LBRAC} and @code{N_RBRAC} stabs that describe the block
|
||||
scope of a procedure are located after the @code{N_FUN} stab that
|
||||
|
@ -660,6 +681,19 @@ Sun documents the desc field of @code{N_LBRAC} and
|
|||
However, dbx seems to not care, and GCC always sets desc to
|
||||
zero.
|
||||
|
||||
@node Alternate Entry Points
|
||||
@section Alternate Entry Points
|
||||
|
||||
Some languages, like Fortran, have the ability to enter procedures at
|
||||
some place other than the beginning. One can declare an alternate entry
|
||||
point. The @code{N_ENTRY} stab is for this; however, the Sun FORTRAN compiler
|
||||
doesn't use it. According to AIX documentation, only the name of a
|
||||
@code{C_ENTRY} stab is significant; the address of the alternate entry
|
||||
point comes from the corresponding external symbol. A previous revision
|
||||
of this document said that the value of an @code{N_ENTRY} stab was the
|
||||
address of the alternate entry point, but I don't know the source for
|
||||
that information.
|
||||
|
||||
@node Constants
|
||||
@chapter Constants
|
||||
|
||||
|
@ -822,6 +856,11 @@ 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
|
||||
produce an external symbol.
|
||||
|
||||
Some compilers, like GCC, output @code{N_GSYM} stabs only once, where
|
||||
the variable is defined. Other compilers, like SunOS4 /bin/cc, output a
|
||||
@code{N_GSYM} stab for each compilation unit which references the
|
||||
variable.
|
||||
|
||||
@node Register Variables
|
||||
@section Register Variables
|
||||
|
||||
|
@ -884,7 +923,9 @@ type declarations using @code{C_DECL}) can also be between the
|
|||
|
||||
Initialized static variables are represented by the @samp{S} and
|
||||
@samp{V} symbol descriptors. @samp{S} means file scope static, and
|
||||
@samp{V} means procedure scope static.
|
||||
@samp{V} means procedure scope static. One exception: in XCOFF, IBM's
|
||||
xlc compiler always uses @samp{V}, and whether it is file scope or not
|
||||
is distinguished by whether the stab is located within a function.
|
||||
|
||||
@c This is probably not worth mentioning; it is only true on the sparc
|
||||
@c for `double' variables which although declared const are actually in
|
||||
|
@ -920,8 +961,15 @@ yield the following stabs:
|
|||
.stabs "var_noinit:S1",40,0,0,_var_noinit # @r{40 is N_LCSYM}
|
||||
@end example
|
||||
|
||||
In XCOFF files, each symbol has a section number, so the stab type
|
||||
need not indicate the section.
|
||||
In XCOFF files, the stab type need not indicate the section;
|
||||
@code{C_STSYM} can be used for all statics. Also, each static variable
|
||||
is enclosed in a static block. A @code{C_BSTAT} (emitted with a
|
||||
@samp{.bs} assembler directive) symbol begins the static block; its
|
||||
value is the symbol number of the csect symbol whose value is the
|
||||
address of the static block, its section is the section of the variables
|
||||
in that static block, and its name is @samp{.bs}. A @code{C_ESTAT}
|
||||
(emitted with a @samp{.es} assembler directive) symbol ends the static
|
||||
block; its name is @samp{.es} and its value and section are ignored.
|
||||
|
||||
In ECOFF files, the storage class is used to specify the section, so the
|
||||
stab type need not indicate the section.
|
||||
|
@ -937,7 +985,7 @@ The clean way to do all this would be to have a the value of a symbol
|
|||
descriptor @samp{S} symbol be an offset relative to the start of the
|
||||
file, just like everything else, but that introduces obvious
|
||||
compatibility problems. For more information on linker stab relocation,
|
||||
@xref{Stabs In ELF}.
|
||||
@xref{ELF Linker Relocation}.
|
||||
|
||||
@node Based Variables
|
||||
@section Fortran Based Variables
|
||||
|
@ -1091,15 +1139,34 @@ 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
|
||||
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
|
||||
(@samp{@var{arg}:p} followed by @samp{@var{arg}:}); this includes GCC1
|
||||
(not GCC2) on the sparc when passing a small structure and GCC2
|
||||
(sometimes) when the argument type is @code{float} and it is passed as a
|
||||
@code{double} and converted to @code{float} by the prologue (in the
|
||||
latter case the type of the @samp{@var{arg}:p} symbol is @code{double}
|
||||
and the type of the @samp{@var{arg}:} symbol is @code{float}).
|
||||
If a parameter is passed as one type and converted to a smaller type by
|
||||
the prologue (for example, the parameter is declared as a @code{float},
|
||||
but the calling conventions specify that it is passed as a
|
||||
@code{double}), then GCC2 (sometimes) uses a pair of symbols. The first
|
||||
symbol uses symbol descriptor @samp{p} and the type which is passed.
|
||||
The second symbol has the type and location which the parameter actually
|
||||
has after the prologue. For example, suppose the following C code
|
||||
appears with no prototypes involved:
|
||||
|
||||
@example
|
||||
void
|
||||
subr (f)
|
||||
float f;
|
||||
@{
|
||||
@end example
|
||||
|
||||
if @code{f} is passed as a double at stack offset 8, and the prologue
|
||||
converts it to a float in register number 0, then the stabs look like:
|
||||
|
||||
@example
|
||||
.stabs "f:p13",160,0,3,8 # @r{160 is @code{N_PSYM}, here 13 is @code{double}}
|
||||
.stabs "f:r12",64,0,3,0 # @r{64 is @code{N_RSYM}, here 12 is @code{float}}
|
||||
@end example
|
||||
|
||||
In both stabs 3 is the line number where @code{f} is declared
|
||||
(@pxref{Line Numbers}).
|
||||
|
||||
@findex N_LSYM, for parameter
|
||||
GCC, at least on the 960, has another solution to the same problem. It
|
||||
uses a single @samp{p} symbol descriptor for an argument which is stored
|
||||
as a local variable but uses @code{N_LSYM} instead of @code{N_PSYM}. In
|
||||
|
@ -1503,9 +1570,9 @@ use a new negative type number.
|
|||
@code{integer}. 32 bit signed integral type.
|
||||
|
||||
@item -16
|
||||
@code{boolean}. 32 bit type. How is the truth value encoded? Is it
|
||||
the least significant bit or is it a question of whether the whole value
|
||||
is zero or non-zero?
|
||||
@code{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.
|
||||
|
||||
@item -17
|
||||
@code{short real}. IEEE single precision.
|
||||
|
@ -1604,6 +1671,9 @@ Pascal set type. @var{type-information} must be a small type such as an
|
|||
enumeration or a subrange, and the type is a bitmask whose length is
|
||||
specified by the number of elements in @var{type-information}.
|
||||
|
||||
In CHILL, if it is a bitstring instead of a set, also use the @samp{S}
|
||||
type attribute (@pxref{String Field}).
|
||||
|
||||
@item * @var{type-information}
|
||||
Pointer to @var{type-information}.
|
||||
@end table
|
||||
|
@ -1618,6 +1688,10 @@ yet been defined.
|
|||
Another way is with the @samp{x} type descriptor, which is followed by
|
||||
@samp{s} for a structure tag, @samp{u} for a union tag, or @samp{e} for
|
||||
a enumerator tag, followed by the name of the tag, followed by @samp{:}.
|
||||
If the name contains @samp{::} between a @samp{<} and @samp{>} pair (for
|
||||
C++ templates), such a @samp{::} does not end the name---only a single
|
||||
@samp{:} ends the name; see @ref{Nested Symbols}.
|
||||
|
||||
For example, the following C declarations:
|
||||
|
||||
@example
|
||||
|
@ -1798,6 +1872,10 @@ string. I don't know the difference.
|
|||
Pascal Stringptr. What is this? This is an AIX feature.
|
||||
@end table
|
||||
|
||||
Languages, such as CHILL which have a string type which is basically
|
||||
just an array of characters use the @samp{S} type attribute
|
||||
(@pxref{String Field}).
|
||||
|
||||
@node Enumerations
|
||||
@section Enumerations
|
||||
|
||||
|
@ -1829,13 +1907,29 @@ structure, enumeration, or union tag. The type descriptor @samp{e},
|
|||
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
|
||||
the enumeration. The format is @samp{@var{name}:@var{value},}. The
|
||||
list of elements ends with @samp{;}.
|
||||
list of elements ends with @samp{;}. The fact that @var{value} is
|
||||
specified as an integer can cause problems if the value is large. GCC
|
||||
2.5.2 tries to output it in octal in that case with a leading zero,
|
||||
which is probably a good thing, although GDB 4.11 supports octal only in
|
||||
cases where decimal is perfectly good. Negative decimal values are
|
||||
supported by both GDB and dbx.
|
||||
|
||||
There is no standard way to specify the size of an enumeration type; it
|
||||
is determined by the architecture (normally all enumerations types are
|
||||
32 bits). There should be a way to specify an enumeration type of
|
||||
another size; type attributes would be one way to do this. @xref{Stabs
|
||||
Format}.
|
||||
32 bits). Type attributes can be used to specify an enumeration type of
|
||||
another size for debuggers which support them; see @ref{String Field}.
|
||||
|
||||
Enumeration types are unusual in that they define symbols for the
|
||||
enumeration values (@code{first}, @code{second}, and @code{third} in the
|
||||
above example), and even though these symbols are visible in the file as
|
||||
a whole (rather than being in a more local namespace like structure
|
||||
member names), they are defined in the type definition for the
|
||||
enumeration type rather than each having their own symbol. In order to
|
||||
be fast, GDB will only get symbols from such types (in its initial scan
|
||||
of the stabs) if the type is the first thing defined after a @samp{T} or
|
||||
@samp{t} symbol descriptor (the above example fulfills this
|
||||
requirement). If the type does not have a name, the compiler should
|
||||
emit it in a nameless stab (@pxref{String Field}); GCC does this.
|
||||
|
||||
@node Structures
|
||||
@section Structures
|
||||
|
@ -1891,6 +1985,15 @@ The @code{s_next} field is a pointer to the same kind of structure that
|
|||
the field is an element of. So the definition of structure type 16
|
||||
contains a type definition for an element which is a pointer to type 16.
|
||||
|
||||
If a field is a static member (this is a C++ feature in which a single
|
||||
variable appears to be a field of every structure of a given type) it
|
||||
still starts out with the field name, a colon, and the type, but then
|
||||
instead of a comma, bit position, comma, and bit size, there is a colon
|
||||
followed by the name of the variable which each such field refers to.
|
||||
|
||||
If the structure has methods (a C++ feature), they follow the non-method
|
||||
fields; see @ref{Cplusplus}.
|
||||
|
||||
@node Typedefs
|
||||
@section Giving a Type a Name
|
||||
|
||||
|
@ -2084,7 +2187,8 @@ relocatable address and the linker turns it into an absolute address.
|
|||
@menu
|
||||
* Transformations On Static Variables::
|
||||
* Transformations On Global Variables::
|
||||
* ELF Transformations:: In ELF, things are a bit different.
|
||||
* Stab Section Transformations:: For some object file formats,
|
||||
things are a bit different.
|
||||
@end menu
|
||||
|
||||
@node Transformations On Static Variables
|
||||
|
@ -2160,16 +2264,17 @@ entry now holds an absolute address:
|
|||
0000e008 D _g_foo
|
||||
@end example
|
||||
|
||||
@node ELF Transformations
|
||||
@subsection Transformations of Stabs in ELF Files
|
||||
@node Stab Section Transformations
|
||||
@subsection Transformations of Stabs in separate sections
|
||||
|
||||
For ELF files, use @code{objdump --stabs} instead of @code{nm} to show
|
||||
the stabs in an object or executable file. @code{objdump} is a GNU
|
||||
utility; Sun does not provide any equivalent.
|
||||
For object file formats using stabs in separate sections (@pxref{Stab
|
||||
Sections}), use @code{objdump --stabs} instead of @code{nm} to show the
|
||||
stabs in an object or executable file. @code{objdump} is a GNU utility;
|
||||
Sun does not provide any equivalent.
|
||||
|
||||
The following example is for a stab whose value is an address is
|
||||
relative to the compilation unit (@pxref{Stabs In ELF}). For example,
|
||||
if the source line
|
||||
relative to the compilation unit (@pxref{ELF Linker Relocation}). For
|
||||
example, if the source line
|
||||
|
||||
@example
|
||||
static int ld = 5;
|
||||
|
@ -2207,10 +2312,14 @@ Symnum n_type n_othr n_desc n_value n_strx String
|
|||
@chapter GNU C++ Stabs
|
||||
|
||||
@menu
|
||||
* Class Names:: C++ class names are both tags and typedefs.
|
||||
* Nested Symbols:: C++ symbol names can be within other types.
|
||||
* Basic Cplusplus Types::
|
||||
* Simple Classes::
|
||||
* Class Instance::
|
||||
* Methods:: Method definition
|
||||
* Method Type Descriptor:: The @samp{#} type descriptor
|
||||
* Member Type Descriptor:: The @samp{@@} type descriptor
|
||||
* Protections::
|
||||
* Method Modifiers::
|
||||
* Virtual Methods::
|
||||
|
@ -2219,24 +2328,53 @@ Symnum n_type n_othr n_desc n_value n_strx String
|
|||
* Static Members::
|
||||
@end menu
|
||||
|
||||
Type descriptors added for C++ descriptions:
|
||||
@node Class Names
|
||||
@section C++ Class Names
|
||||
|
||||
@table @code
|
||||
@item #
|
||||
method type (@code{##} if minimal debug)
|
||||
In C++, a class name which is declared with @code{class}, @code{struct},
|
||||
or @code{union}, is not only a tag, as in C, but also a type name. Thus
|
||||
there should be stabs with both @samp{t} and @samp{T} symbol descriptors
|
||||
(@pxref{Typedefs}).
|
||||
|
||||
@item @@
|
||||
Member (class and variable) type. It is followed by type information
|
||||
for the offset basetype, a comma, and type information for the type of
|
||||
the field being pointed to. (FIXME: this is acknowledged to be
|
||||
gibberish. Can anyone say what really goes here?).
|
||||
To save space, there is a special abbreviation for this case. If the
|
||||
@samp{T} symbol descriptor is followed by @samp{t}, then the stab
|
||||
defines both a type name and a tag.
|
||||
|
||||
Note that there is a conflict between this and type attributes
|
||||
(@pxref{String Field}); both use type descriptor @samp{@@}.
|
||||
Fortunately, the @samp{@@} type descriptor used in this C++ sense always
|
||||
will be followed by a digit, @samp{(}, or @samp{-}, and type attributes
|
||||
never start with those things.
|
||||
@end table
|
||||
For example, the C++ code
|
||||
|
||||
@example
|
||||
struct foo @{int x;@};
|
||||
@end example
|
||||
|
||||
can be represented as either
|
||||
|
||||
@example
|
||||
.stabs "foo:T19=s4x:1,0,32;;",128,0,0,0 # @r{128 is N_LSYM}
|
||||
.stabs "foo:t19",128,0,0,0
|
||||
@end example
|
||||
|
||||
or
|
||||
|
||||
@example
|
||||
.stabs "foo:Tt19=s4x:1,0,32;;",128,0,0,0
|
||||
@end example
|
||||
|
||||
@node Nested Symbols
|
||||
@section Defining a Symbol Within Another Type
|
||||
|
||||
In C++, a symbol (such as a type name) can be defined within another type.
|
||||
@c FIXME: Needs example.
|
||||
|
||||
In stabs, this is sometimes represented by making the name of a symbol
|
||||
which contains @samp{::}. Such a pair of colons does not end the name
|
||||
of the symbol, the way a single colon would (@pxref{String Field}). I'm
|
||||
not sure how consistently used or well thought out this mechanism is.
|
||||
So that a pair of colons in this position always has this meaning,
|
||||
@samp{:} cannot be used as a symbol descriptor.
|
||||
|
||||
For example, if the string for a stab is @samp{foo::bar::baz:t5=*6},
|
||||
then @code{foo::bar::baz} is the name of the symbol, @samp{t} is the
|
||||
symbol descriptor, and @samp{5=*6} is the type information.
|
||||
|
||||
@node Basic Cplusplus Types
|
||||
@section Basic Types For C++
|
||||
|
@ -2333,12 +2471,11 @@ method.
|
|||
|
||||
When the field name is a method name it is followed by two colons rather
|
||||
than one. This is followed by a new type definition for the method.
|
||||
This is a number followed by an equal sign and the type descriptor
|
||||
@samp{#}, indicating a method type, and a second @samp{#}, indicating
|
||||
that this is the @dfn{minimal} type of method definition used by GCC2,
|
||||
not larger method definitions used by earlier versions of GCC. This is
|
||||
followed by a type reference showing the return type of the method and a
|
||||
semi-colon.
|
||||
This is a number followed by an equal sign and the type of the method.
|
||||
Normally this will be a type declared using the @samp{#} type
|
||||
descriptor; see @ref{Method Type Descriptor}; static member functions
|
||||
are declared using the @samp{f} type descriptor instead; see
|
||||
@ref{Function Types}.
|
||||
|
||||
The format of an overloaded operator method name differs from that of
|
||||
other methods. It is @samp{op$::@var{operator-name}.} where
|
||||
|
@ -2475,49 +2612,86 @@ pointer.
|
|||
|
||||
<< The examples that follow are based on A1.C >>
|
||||
|
||||
@node Method Type Descriptor
|
||||
@section The @samp{#} Type Descriptor
|
||||
|
||||
This is like the @samp{f} type descriptor for functions (@pxref{Function
|
||||
Types}), except that a function which uses the @samp{#} type descriptor
|
||||
takes an extra argument as its first argument, for the @code{this}
|
||||
pointer. The @samp{#} type descriptor is optionally followed by the
|
||||
types of the arguments, then another @samp{#}. If the types of the
|
||||
arguments are omitted, so that the second @samp{#} immediately follows
|
||||
the @samp{#} which is the type descriptor, the arguments are being
|
||||
omitted (to save space) and can be deduced from the mangled name of the
|
||||
method. After the second @samp{#} there is type information for the
|
||||
return type of the method and a semicolon.
|
||||
|
||||
Note that although such a type will normally be used to describe fields
|
||||
in structures, unions, or classes, for at least some versions of the
|
||||
compiler it can also be used in other contexts.
|
||||
|
||||
@node Member Type Descriptor
|
||||
@section The @samp{@@} Type Descriptor
|
||||
|
||||
The @samp{@@} type descriptor is for a member (class and variable) type.
|
||||
It is followed by type information for the offset basetype, a comma, and
|
||||
type information for the type of the field being pointed to. (FIXME:
|
||||
this is acknowledged to be gibberish. Can anyone say what really goes
|
||||
here?).
|
||||
|
||||
Note that there is a conflict between this and type attributes
|
||||
(@pxref{String Field}); both use type descriptor @samp{@@}.
|
||||
Fortunately, the @samp{@@} type descriptor used in this C++ sense always
|
||||
will be followed by a digit, @samp{(}, or @samp{-}, and type attributes
|
||||
never start with those things.
|
||||
|
||||
@node Protections
|
||||
@section Protections
|
||||
|
||||
|
||||
In the simple class definition shown above all member data and
|
||||
functions were publicly accessable. The example that follows
|
||||
contrasts public, protected and privately accessable fields and shows
|
||||
how these protections are encoded in C++ stabs.
|
||||
|
||||
@c FIXME: What does "part of the string" mean?
|
||||
Protections for class member data are signified by two characters
|
||||
embedded in the stab defining the class type. These characters are
|
||||
located after the name: part of the string. @samp{/0} means private,
|
||||
@samp{/1} means protected, and @samp{/2} means public. If these
|
||||
characters are omited this means that the member is public. The
|
||||
following C++ source:
|
||||
If the character following the @samp{@var{field-name}:} part of the
|
||||
string is @samp{/}, then the next character is the visibility. @samp{0}
|
||||
means private, @samp{1} means protected, and @samp{2} means public.
|
||||
Debuggers should ignore visibility characters they do not recognize, and
|
||||
assume a reasonable default (such as public) (GDB 4.11 does not, but
|
||||
this should be fixed in the next GDB release). If no visibility is
|
||||
specified the field is public. The visibility @samp{9} means that the
|
||||
field has been optimized out and is public (there is no way to specify
|
||||
an optimized out field with a private or protected visibility).
|
||||
Visibility @samp{9} is not supported by GDB 4.11; this should be fixed
|
||||
in the next GDB release.
|
||||
|
||||
The following C++ source:
|
||||
|
||||
@example
|
||||
class all_data @{
|
||||
class vis @{
|
||||
private:
|
||||
int priv_dat;
|
||||
int priv;
|
||||
protected:
|
||||
char prot_dat;
|
||||
char prot;
|
||||
public:
|
||||
float pub_dat;
|
||||
float pub;
|
||||
@};
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
generates the following stab to describe the class type all_data.
|
||||
generates the following stab:
|
||||
|
||||
@display
|
||||
.stabs "class_name:sym_desc(type)type_def(19)=type_desc(struct)struct_bytes
|
||||
data_name:/protection(private)type_ref(int),bit_offset,num_bits;
|
||||
data_name:/protection(protected)type_ref(char),bit_offset,num_bits;
|
||||
data_name:(/num omited, private)type_ref(float),bit_offset,num_bits;;"
|
||||
N_LSYM,NIL,NIL,NIL
|
||||
@end display
|
||||
@example
|
||||
# @r{128 is N_LSYM}
|
||||
.stabs "vis:T19=s12priv:/01,0,32;prot:/12,32,8;pub:12,64,32;;",128,0,0,0
|
||||
@end example
|
||||
|
||||
@smallexample
|
||||
.stabs "all_data:t19=s12
|
||||
priv_dat:/01,0,32;prot_dat:/12,32,8;pub_dat:12,64,32;;",128,0,0,0
|
||||
@end smallexample
|
||||
@samp{vis:T19=s12} indicates that type number 19 is a 12 byte structure
|
||||
named @code{vis} The @code{priv} field has public visibility
|
||||
(@samp{/0}), type int (@samp{1}), and offset and size @samp{,0,32;}.
|
||||
The @code{prot} field has protected visibility (@samp{/1}), type char
|
||||
(@samp{2}) and offset and size @samp{,32,8;}. The @code{pub} field has
|
||||
type float (@samp{12}), and offset and size @samp{,64,32;}.
|
||||
|
||||
Protections for member functions are signified by one digit embeded in
|
||||
the field part of the stab describing the method. The digit is 0 if
|
||||
|
@ -2696,14 +2870,21 @@ This additional information is embeded in the class stab following the
|
|||
number of bytes in the struct. First the number of base classes
|
||||
appears bracketed by an exclamation point and a comma.
|
||||
|
||||
Then for each base type there repeats a series: two digits, a number,
|
||||
a comma, another number, and a semi-colon.
|
||||
Then for each base type there repeats a series: a virtual character, a
|
||||
visibilty character, a number, a comma, another number, and a
|
||||
semi-colon.
|
||||
|
||||
The first of the two digits is 1 if the base class is virtual and 0 if
|
||||
not. The second digit is 2 if the derivation is public and 0 if not.
|
||||
The virtual character is @samp{1} if the base class is virtual and
|
||||
@samp{0} if not. The visibility character is @samp{2} if the derivation
|
||||
is public, @samp{1} if it is protected, and @samp{0} if it is private.
|
||||
Debuggers should ignore virtual or visibility characters they do not
|
||||
recognize, and assume a reasonable default (such as public and
|
||||
non-virtual) (GDB 4.11 does not, but this should be fixed in the next
|
||||
GDB release).
|
||||
|
||||
The number following the first two digits is the offset from the start
|
||||
of the object to the part of the object pertaining to the base class.
|
||||
The number following the virtual and visibility characters is the offset
|
||||
from the start of the object to the part of the object pertaining to the
|
||||
base class.
|
||||
|
||||
After the comma, the second number is a type_descriptor for the base
|
||||
type. Finally a semi-colon ends the series, which repeats for each
|
||||
|
@ -2847,9 +3028,10 @@ description in the class stab shows this ordering.
|
|||
@appendix Table of Stab Types
|
||||
|
||||
The following are all the possible values for the stab type field, for
|
||||
@code{a.out} files, in numeric order. This does not apply to XCOFF, but
|
||||
it does apply to stabs in ELF. Stabs in ECOFF use these values but add
|
||||
0x8f300 to distinguish them from non-stab symbols.
|
||||
a.out files, in numeric order. This does not apply to XCOFF, but
|
||||
it does apply to stabs in sections (@pxref{Stab Sections}). Stabs in
|
||||
ECOFF use these values but add 0x8f300 to distinguish them from non-stab
|
||||
symbols.
|
||||
|
||||
The symbolic names are defined in the file @file{include/aout/stabs.def}.
|
||||
|
||||
|
@ -2909,18 +3091,23 @@ Symbol is indirected to another symbol
|
|||
Common---visible after shared library dynamic link
|
||||
|
||||
@item 0x14 N_SETA
|
||||
@itemx 0x15 N_SETA | N_EXT
|
||||
Absolute set element
|
||||
|
||||
@item 0x16 N_SETT
|
||||
@itemx 0x17 N_SETT | N_EXT
|
||||
Text segment set element
|
||||
|
||||
@item 0x18 N_SETD
|
||||
@itemx 0x19 N_SETD | N_EXT
|
||||
Data segment set element
|
||||
|
||||
@item 0x1a N_SETB
|
||||
@itemx 0x1b N_SETB | N_EXT
|
||||
BSS segment set element
|
||||
|
||||
@item 0x1c N_SETV
|
||||
@itemx 0x1d N_SETV | N_EXT
|
||||
Pointer to set vector
|
||||
|
||||
@item 0x1e N_WARNING
|
||||
|
@ -3036,7 +3223,7 @@ Parameter variable; see @ref{Parameters}.
|
|||
End of an include file; see @ref{Include Files}.
|
||||
|
||||
@item 0xa4 N_ENTRY
|
||||
Alternate entry point; see @ref{N_ENTRY}.
|
||||
Alternate entry point; see @ref{Alternate Entry Points}.
|
||||
|
||||
@item 0xc0 N_LBRAC
|
||||
Beginning of a lexical block; see @ref{Block Structure}.
|
||||
|
@ -3102,6 +3289,9 @@ for more information about their use.
|
|||
@itemx -
|
||||
Variable on the stack; see @ref{Stack Variables}.
|
||||
|
||||
@item :
|
||||
C++ nested symbol; see @xref{Nested Symbols}
|
||||
|
||||
@item a
|
||||
Parameter passed by reference in register; see @ref{Reference Parameters}.
|
||||
|
||||
|
@ -3176,6 +3366,9 @@ Register variable; see @ref{Register Variables}.
|
|||
@item S
|
||||
File scope variable; see @ref{Statics}.
|
||||
|
||||
@item s
|
||||
Local variable (OS9000).
|
||||
|
||||
@item t
|
||||
Type name; see @ref{Typedefs}.
|
||||
|
||||
|
@ -3211,7 +3404,7 @@ Type reference; see @ref{String Field}.
|
|||
Reference to builtin type; see @ref{Negative Type Numbers}.
|
||||
|
||||
@item #
|
||||
Method (C++); see @ref{Cplusplus}.
|
||||
Method (C++); see @ref{Method Type Descriptor}.
|
||||
|
||||
@item *
|
||||
Pointer; see @ref{Miscellaneous Types}.
|
||||
|
@ -3221,7 +3414,7 @@ Reference (C++).
|
|||
|
||||
@item @@
|
||||
Type Attributes (AIX); see @ref{String Field}. Member (class and variable)
|
||||
type (GNU C++); see @ref{Cplusplus}.
|
||||
type (GNU C++); see @ref{Member Type Descriptor}.
|
||||
|
||||
@item a
|
||||
Array; see @ref{Arrays}.
|
||||
|
@ -3231,13 +3424,15 @@ Open array; see @ref{Arrays}.
|
|||
|
||||
@item b
|
||||
Pascal space type (AIX); see @ref{Miscellaneous Types}. Builtin integer
|
||||
type (Sun); see @ref{Builtin Type Descriptors}.
|
||||
type (Sun); see @ref{Builtin Type Descriptors}. Const and volatile
|
||||
qualfied type (OS9000).
|
||||
|
||||
@item B
|
||||
Volatile-qualified type; see @ref{Miscellaneous Types}.
|
||||
|
||||
@item c
|
||||
Complex builtin type; see @ref{Builtin Type Descriptors}.
|
||||
Complex builtin type (AIX); see @ref{Builtin Type Descriptors}.
|
||||
Const-qualified type (OS9000).
|
||||
|
||||
@item C
|
||||
COBOL Picture type. See AIX documentation for details.
|
||||
|
@ -3267,7 +3462,8 @@ Builtin floating point type; see @ref{Builtin Type Descriptors}.
|
|||
COBOL Group. See AIX documentation for details.
|
||||
|
||||
@item i
|
||||
Imported type; see @ref{Cross-References}.
|
||||
Imported type (AIX); see @ref{Cross-References}. Volatile-qualified
|
||||
type (OS9000).
|
||||
|
||||
@item k
|
||||
Const-qualified type; see @ref{Miscellaneous Types}.
|
||||
|
@ -3322,6 +3518,9 @@ Wide character; see @ref{Builtin Type Descriptors}.
|
|||
@item x
|
||||
Cross-reference; see @ref{Cross-References}.
|
||||
|
||||
@item Y
|
||||
Used by IBM's xlC C++ compiler (for structures, I think).
|
||||
|
||||
@item z
|
||||
gstring; see @ref{Strings}.
|
||||
@end table
|
||||
|
@ -3347,7 +3546,7 @@ The third line is the stab format with the significant stab fields
|
|||
named and the rest NIL.
|
||||
|
||||
Subsequent lines expand upon the meaning and possible values for each
|
||||
significant stab field. @samp{#} stands in for the type descriptor.
|
||||
significant stab field.
|
||||
|
||||
Finally, any further information.
|
||||
|
||||
|
@ -3362,7 +3561,6 @@ Finally, any further information.
|
|||
* N_MOD2:: Modula2 information "for imc"
|
||||
* N_CATCH:: GNU C++ "catch" clause
|
||||
* N_SSYM:: Structure or union element
|
||||
* N_ENTRY:: Alternate entry point
|
||||
* N_SCOPE:: Modula2 scope information (Sun only)
|
||||
* Gould:: non-base register symbols used on Gould systems
|
||||
* N_LENG:: Length of preceding entry
|
||||
|
@ -3426,6 +3624,10 @@ desc -> unit_number
|
|||
value -> 0 (main unit)
|
||||
1 (any other unit)
|
||||
@end example
|
||||
|
||||
See @cite{Dbx and Dbxtool Interfaces}, 2nd edition, by Sun, 1988, for
|
||||
more information.
|
||||
|
||||
@end deffn
|
||||
|
||||
@node N_BROWS
|
||||
|
@ -3502,16 +3704,6 @@ The value is the offset in the structure.
|
|||
<<?looking at structs and unions in C I didn't see these>>
|
||||
@end deffn
|
||||
|
||||
@node N_ENTRY
|
||||
@section N_ENTRY
|
||||
|
||||
@deffn @code{.stabn} N_ENTRY
|
||||
@findex N_ENTRY
|
||||
Alternate entry point.
|
||||
The value is its address.
|
||||
<<?>>
|
||||
@end deffn
|
||||
|
||||
@node N_SCOPE
|
||||
@section N_SCOPE
|
||||
|
||||
|
@ -3628,15 +3820,6 @@ the mapping is @code{N_@var{stabtype}} becomes @code{C_@var{stabtype}}.
|
|||
Some stab types in a.out are not supported in XCOFF; most of these use
|
||||
@code{C_DECL}.
|
||||
|
||||
@c FIXME: Get C_* types for the block, figure out whether it is always
|
||||
@c used (I suspect not), explain clearly, and move to node Statics.
|
||||
Exception: initialised static @code{N_STSYM} and un-initialized static
|
||||
@code{N_LCSYM} both map to the @code{C_STSYM} storage class. But the
|
||||
distinction is preserved because in XCOFF @code{N_STSYM} and
|
||||
@code{N_LCSYM} must be emited in a named static block. Begin the block
|
||||
with @samp{.bs s[RW] data_section_name} for @code{N_STSYM} or @samp{.bs
|
||||
s bss_section_name} for @code{N_LCSYM}. End the block with @samp{.es}.
|
||||
|
||||
@c FIXME: I think they are trying to say something about whether the
|
||||
@c assembler defaults the value to the location counter.
|
||||
@item
|
||||
|
@ -3708,18 +3891,36 @@ incremented for each new type defined in the compilation. GNU C stabs
|
|||
use the type number alone, with no source file number.
|
||||
@end itemize
|
||||
|
||||
@node Stabs In ELF
|
||||
@appendix Using Stabs With The ELF Object File Format
|
||||
@node Stab Sections
|
||||
@appendix Using Stabs in Their Own Sections
|
||||
|
||||
The ELF object file format allows tools to create object files with
|
||||
custom sections containing any arbitrary data. To use stabs in ELF
|
||||
object files, the tools create two custom sections, a section named
|
||||
@code{.stab} which contains an array of fixed length structures, one
|
||||
struct per stab, and a section named @code{.stabstr} containing all the
|
||||
variable length strings that are referenced by stabs in the @code{.stab}
|
||||
section. The byte order of the stabs binary data matches the byte order
|
||||
of the ELF file itself, as determined from the @code{EI_DATA} field in
|
||||
the @code{e_ident} member of the ELF header.
|
||||
Many object file formats allow tools to create object files with custom
|
||||
sections containing any arbitrary data. For any such object file
|
||||
format, stabs can be embedded in special sections. This is how stabs
|
||||
are used with ELF and SOM, and aside from ECOFF and XCOFF, is how stabs
|
||||
are used with COFF.
|
||||
|
||||
@menu
|
||||
* Stab Section Basics:: How to embed stabs in sections
|
||||
* ELF Linker Relocation:: Sun ELF hacks
|
||||
@end menu
|
||||
|
||||
@node Stab Section Basics
|
||||
@appendixsec How to Embed Stabs in Sections
|
||||
|
||||
The assembler creates two custom sections, a section named @code{.stab}
|
||||
which contains an array of fixed length structures, one struct per stab,
|
||||
and a section named @code{.stabstr} containing all the variable length
|
||||
strings that are referenced by stabs in the @code{.stab} section. The
|
||||
byte order of the stabs binary data depends on the object file format.
|
||||
For ELF, it matches the byte order of the ELF file itself, as determined
|
||||
from the @code{EI_DATA} field in the @code{e_ident} member of the ELF
|
||||
header. For SOM, it is always big-endian (is this true??? FIXME). For
|
||||
COFF, it matches the byte order of the COFF headers. The meaning of the
|
||||
fields is the same as for a.out (@pxref{Symbol Table Format}), except
|
||||
that the @code{n_strx} field is relative to the strings for the current
|
||||
compilation unit (which can be found using the synthetic N_UNDF stab
|
||||
described below), rather than the entire string table.
|
||||
|
||||
The first stab in the @code{.stab} section for each compilation unit is
|
||||
synthetic, generated entirely by the assembler, with no corresponding
|
||||
|
@ -3735,6 +3936,8 @@ Offset in the @code{.stabstr} section to the source filename.
|
|||
|
||||
@item n_other
|
||||
Unused field, always zero.
|
||||
This may eventually be used to hold overflows from the count in
|
||||
the @code{n_desc} field.
|
||||
|
||||
@item n_desc
|
||||
Count of upcoming symbols, i.e., the number of remaining stabs for this
|
||||
|
@ -3753,38 +3956,75 @@ The ELF section header for the @code{.stab} section has its
|
|||
@code{sh_link} member set to the section number of the @code{.stabstr}
|
||||
section, and the @code{.stabstr} section has its ELF section
|
||||
header @code{sh_type} member set to @code{SHT_STRTAB} to mark it as a
|
||||
string table.
|
||||
string table. SOM and COFF have no way of linking the sections together
|
||||
or marking them as string tables.
|
||||
|
||||
To keep linking fast, it is a bad idea to have the linker relocating
|
||||
stabs, so (except for a few cases, see below) none of the addresses in
|
||||
the @code{n_value} field of the stabs are relocated by the linker.
|
||||
Instead they are relative to the source file (or some entity smaller
|
||||
than a source file, like a function). To find the address of each
|
||||
section corresponding to a given source file, the compiler puts out
|
||||
symbols giving the address of each section for a given source file.
|
||||
Since these are ELF (not stab) symbols, the linker relocates them
|
||||
correctly without having to touch the stabs section. They are named
|
||||
@code{Bbss.bss} for the bss section, @code{Ddata.data} for the data
|
||||
section, and @code{Drodata.rodata} for the rodata section. For the text
|
||||
section, there is no such symbol (but there should be, see below). For
|
||||
an example of how these symbols work, @xref{ELF Transformations}. GCC
|
||||
does not provide these symbols; it instead relies on the stabs getting
|
||||
relocated, which slows down linking. Thus addresses which would
|
||||
normally be relative to @code{Bbss.bss}, etc., are already relocated.
|
||||
The Sun linker provided with Solaris 2.2 and earlier relocates stabs
|
||||
using normal ELF relocation information, as it would do for any section.
|
||||
Sun has been threatening to kludge their linker to not do this (to speed
|
||||
up linking), even though the correct way to avoid having the linker do
|
||||
these relocations is to have the compiler no longer output relocatable
|
||||
values. Last I heard they had been talked out of the linker kludge.
|
||||
See Sun point patch 101052-01 and Sun bug 1142109. This affects
|
||||
@samp{S} symbol descriptor stabs (@pxref{Statics}) and functions
|
||||
(@pxref{Procedures}). In the latter case, to adopt the clean solution
|
||||
(making the value of the stab relative to the start of the compilation
|
||||
unit), it would be necessary to invent a @code{Ttext.text} symbol,
|
||||
analogous to the @code{Bbss.bss}, etc., symbols. I recommend this
|
||||
rather than using a zero value and getting the address from the ELF
|
||||
symbols.
|
||||
For COFF, the @code{.stab} and @code{.stabstr} sections are simply
|
||||
concatenated by the linker. GDB then uses the @code{n_desc} fields to
|
||||
figure out the extent of the original sections. Similarly, the
|
||||
@code{n_value} fields of the header symbols are added together in order
|
||||
to get the actual position of the strings in a desired @code{.stabstr}
|
||||
section. Although this design obviates any need for the linker to relocate
|
||||
or otherwise manipulate @code{.stab} and @code{.stabstr} sections, it also
|
||||
requires some care to ensure that the offsets are calculated correctly.
|
||||
For instance, if the linker were to pad in between the @code{.stabstr}
|
||||
sections before concatenating, then the offsets to strings in the middle
|
||||
of the executable's @code{.stabstr} section would be wrong.
|
||||
|
||||
@node ELF Linker Relocation
|
||||
@appendixsec Having the Linker Relocate Stabs in ELF
|
||||
|
||||
This section describes some Sun hacks for Stabs in ELF; it does not
|
||||
apply to COFF or SOM.
|
||||
|
||||
To keep linking fast, you don't want the linker to have to relocate very
|
||||
many stabs. Making sure this is done for @code{N_SLINE},
|
||||
@code{N_RBRAC}, and @code{N_LBRAC} stabs is the most important thing
|
||||
(see the descriptions of those stabs for more information). But Sun's
|
||||
stabs in ELF has taken this further, to make all addresses in the
|
||||
@code{n_value} field (functions and static variables) relative to the
|
||||
source file. For the @code{N_SO} symbol itself, Sun simply omits the
|
||||
address. To find the address of each section corresponding to a given
|
||||
source file, the compiler puts out symbols giving the address of each
|
||||
section for a given source file. Since these are ELF (not stab)
|
||||
symbols, the linker relocates them correctly without having to touch the
|
||||
stabs section. They are named @code{Bbss.bss} for the bss section,
|
||||
@code{Ddata.data} for the data section, and @code{Drodata.rodata} for
|
||||
the rodata section. For the text section, there is no such symbol (but
|
||||
there should be, see below). For an example of how these symbols work,
|
||||
@xref{Stab Section Transformations}. GCC does not provide these symbols;
|
||||
it instead relies on the stabs getting relocated. Thus addresses which
|
||||
would normally be relative to @code{Bbss.bss}, etc., are already
|
||||
relocated. The Sun linker provided with Solaris 2.2 and earlier
|
||||
relocates stabs using normal ELF relocation information, as it would do
|
||||
for any section. Sun has been threatening to kludge their linker to not
|
||||
do this (to speed up linking), even though the correct way to avoid
|
||||
having the linker do these relocations is to have the compiler no longer
|
||||
output relocatable values. Last I heard they had been talked out of the
|
||||
linker kludge. See Sun point patch 101052-01 and Sun bug 1142109. With
|
||||
the Sun compiler this affects @samp{S} symbol descriptor stabs
|
||||
(@pxref{Statics}) and functions (@pxref{Procedures}). In the latter
|
||||
case, to adopt the clean solution (making the value of the stab relative
|
||||
to the start of the compilation unit), it would be necessary to invent a
|
||||
@code{Ttext.text} symbol, analogous to the @code{Bbss.bss}, etc.,
|
||||
symbols. I recommend this rather than using a zero value and getting
|
||||
the address from the ELF symbols.
|
||||
|
||||
Finding the correct @code{Bbss.bss}, etc., symbol is difficult, because
|
||||
the linker simply concatenates the @code{.stab} sections from each
|
||||
@file{.o} file without including any information about which part of a
|
||||
@code{.stab} section comes from which @file{.o} file. The way GDB does
|
||||
this is to look for an ELF @code{STT_FILE} symbol which has the same
|
||||
name as the last component of the file name from the @code{N_SO} symbol
|
||||
in the stabs (for example, if the file name is @file{../../gdb/main.c},
|
||||
it looks for an ELF @code{STT_FILE} symbol named @code{main.c}). This
|
||||
loses if different files have the same name (they could be in different
|
||||
directories, a library could have been copied from one system to
|
||||
another, etc.). It would be much cleaner to have the @code{Bbss.bss}
|
||||
symbols in the stabs themselves. Having the linker relocate them there
|
||||
is no more work than having the linker relocate ELF symbols, and it
|
||||
solves the problem of having to associate the ELF and stab symbols.
|
||||
However, no one has yet designed or implemented such a scheme.
|
||||
|
||||
@node Symbol Types Index
|
||||
@unnumbered Symbol Types Index
|
||||
|
|
Loading…
Reference in New Issue