When you want to make @value{GDBN} work ``native'' on a particular machine, you
have to include all three kinds of information.
+@section Source Tree Structure
+@cindex @value{GDBN} source tree structure
+
+The @value{GDBN} source directory has a mostly flat structure---there
+are only a few subdirectories. A file's name usually gives a hint as
+to what it does; for example, @file{stabsread.c} reads stabs,
+@file{dwarfread.c} reads DWARF, etc.
+
+Files that are related to some common task have names that share
+common substrings. For example, @file{*-thread.c} files deal with
+debugging threads on various platforms; @file{*read.c} files deal with
+reading various kinds of symbol and object files; @file{inf*.c} files
+deal with direct control of the @dfn{inferior program} (@value{GDBN}
+parlance for the program being debugged).
+
+There are several dozens of files in the @file{*-tdep.c} family.
+@samp{tdep} stands for @dfn{target-dependent code}---each of these
+files implements debug support for a specific target architecture
+(sparc, mips, etc). Usually, only one of these will be used in a
+specific @value{GDBN} configuration (sometimes two, closely related).
+
+Similarly, there are many @file{*-nat.c} files, each one for native
+debugging on a specific system (e.g., @file{sparc-linux-nat.c} is for
+native debugging of Sparc machines running the Linux kernel).
+
+The few subdirectories of the source tree are:
+
+@table @file
+@item cli
+Code that implements @dfn{CLI}, the @value{GDBN} Command-Line
+Interpreter. @xref{User Interface, Command Interpreter}.
+
+@item gdbserver
+Code for the @value{GDBN} remote server.
+
+@item gdbtk
+Code for Insight, the @value{GDBN} TK-based GUI front-end.
+
+@item mi
+The @dfn{GDB/MI}, the @value{GDBN} Machine Interface interpreter.
+
+@item signals
+Target signal translation code.
+
+@item tui
+Code for @dfn{TUI}, the @value{GDBN} Text-mode full-screen User
+Interface. @xref{User Interface, TUI}.
+@end table
@node Algorithms
and called functions.
@cindex frame, unwind
-@value{GDBN}'s current frame model is the result of an incremental
-cleanup of working code, not a fresh design, so it's a little weird.
-
-The natural model would have a frame object, with methods that read
-and write that frame's registers. Reading or writing the youngest
-frame's registers would simply read or write the processor's current
-registers, since the youngest frame is running directly on the
-processor. Older frames might have some registers saved on the stack
-by younger frames, so accessing the older frames' registers would do a
-mix of memory accesses and register accesses, as appropriate.
+@value{GDBN}'s frame model, a fresh design, was implemented with the
+need to support @sc{dwarf}'s Call Frame Information in mind. In fact,
+the term ``unwind'' is taken directly from that specification.
+Developers wishing to learn more about unwinders, are encouraged to
+read the the @sc{dwarf} specification.
@findex frame_register_unwind
-Instead, @value{GDBN}'s model is that you find a frame's registers by
-``unwinding'' them from the next younger frame. That is, to access
-the registers of frame #1 (the next-to-youngest frame), you actually
-apply @code{frame_register_unwind} to frame #0 (the youngest frame).
-But then the obvious question is: how do you access the registers of
-the youngest frame itself? How do you ``unwind'' them when they're
-not wound up?
+@findex get_frame_register
+@value{GDBN}'s model is that you find a frame's registers by
+``unwinding'' them from the next younger frame. That is,
+@samp{get_frame_register} which returns the value of a register in
+frame #1 (the next-to-youngest frame), is implemented by calling frame
+#0's @code{frame_register_unwind} (the youngest frame). But then the
+obvious question is: how do you access the registers of the youngest
+frame itself?
@cindex sentinel frame
@findex get_frame_type
is a sentinel frame, then @code{get_frame_type (@var{f}) ==
SENTINEL_FRAME}.
-@findex create_new_frame
-@vindex FRAME_FP
-@code{FRAME_FP} in the machine description has no meaning to the
-machine-independent part of @value{GDBN}, except that it is used when
-setting up a new frame from scratch, as follows:
-
-@smallexample
-create_new_frame (read_register (DEPRECATED_FP_REGNUM), read_pc ()));
-@end smallexample
-
-@cindex frame pointer register
-Other than that, all the meaning imparted to @code{DEPRECATED_FP_REGNUM}
-is imparted by the machine-dependent code. So,
-@code{DEPRECATED_FP_REGNUM} can have any value that is convenient for
-the code that creates new frames. (@code{create_new_frame} calls
-@code{DEPRECATED_INIT_EXTRA_FRAME_INFO} if it is defined; that is where
-you should use the @code{DEPRECATED_FP_REGNUM} value, if your frames are
-nonstandard.)
-
-@cindex frame chain
-Given a @value{GDBN} frame, define @code{DEPRECATED_FRAME_CHAIN} to
-determine the address of the calling function's frame. This will be
-used to create a new @value{GDBN} frame struct, and then
-@code{DEPRECATED_INIT_EXTRA_FRAME_INFO} and
-@code{DEPRECATED_INIT_FRAME_PC} will be called for the new frame.
-
@section Prologue Analysis
@cindex prologue analysis
code starting from its entry point, and looks for instructions that
allocate frame space, save the stack pointer in a frame pointer
register, save registers, and so on. Obviously, this can't be done
-accurately in general, but it's tractible to do well enough to be very
+accurately in general, but it's tractable to do well enough to be very
helpful. Prologue analysis predates the GNU toolchain's support for
CFI; at one time, prologue analysis was the only mechanism
@value{GDBN} used for stack unwinding at all, when the function
@item
It's easier to see that the analyzer is correct: you just see
-whether the analyzer properly (albiet conservatively) simulates
+whether the analyzer properly (albeit conservatively) simulates
the effect of each instruction.
@item
of open files and devices.
There are a number of ways in which checkpoints may be implemented
-in gdb, eg. as corefiles, as forked processes, and as some opaque
+in gdb, e.g.@: as corefiles, as forked processes, and as some opaque
method implemented on the target side.
A corefile can be used to save an image of target memory and register
is used to implement checkpoints on Linux, and in principle might
be used on other systems.
-Some targets, eg.@: simulators, might have their own built-in
+Some targets, e.g.@: simulators, might have their own built-in
method for saving checkpoints, and gdb might be able to take
advantage of that capability without necessarily knowing any
details of how it is done.
$ echo $u $V $D
5.1 5_2 2002-03-03
$ echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
--D $D-gmt gdb_$V-$D-branchpoint insight+dejagnu
+-D $D-gmt gdb_$V-$D-branchpoint insight
cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
--D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight+dejagnu
+-D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight
$ ^echo ^^
...
$ echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
--b -r gdb_$V-$D-branchpoint gdb_$V-branch insight+dejagnu
+-b -r gdb_$V-$D-branchpoint gdb_$V-branch insight
cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
--b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight+dejagnu
+-b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight
$ ^echo ^^
...
$
@itemize @bullet
@item
-by using @kbd{-D YYYY-MM-DD-gmt} the branch is forced to an exact
+By using @kbd{-D YYYY-MM-DD-gmt}, the branch is forced to an exact
date/time.
@item
-the trunk is first taged so that the branch point can easily be found
+The trunk is first tagged so that the branch point can easily be found.
@item
-Insight (which includes GDB) and dejagnu are all tagged at the same time
+Insight, which includes @value{GDBN}, is tagged at the same time.
@item
-@file{version.in} gets bumped to avoid version number conflicts
+@file{version.in} gets bumped to avoid version number conflicts.
@item
-the reading of @file{.cvsrc} is disabled using @file{-f}
+The reading of @file{.cvsrc} is disabled using @file{-f}.
@end itemize
@subheading Update @file{version.in}
@itemize @bullet
@item
@file{0000-00-00} is used as a date to pump prime the version.in update
-mechanism
+mechanism.
@item
@file{.90} and the previous branch version are used as fairly arbitrary
-initial branch version number
+initial branch version number.
@end itemize
@itemize @bullet
@item
-a daily timestamp is added to the file @file{version.in}
+A daily timestamp is added to the file @file{version.in}.
@item
-the new branch is included in the snapshot process
+The new branch is included in the snapshot process.
@end itemize
@noindent
@itemize @bullet
@item
-the branch tag
+The branch tag.
@item
-how to check out the branch using CVS
+How to check out the branch using CVS.
@item
-the date/number of weeks until the release
+The date/number of weeks until the release.
@item
-the branch commit policy
-still holds.
+The branch commit policy still holds.
@end itemize
@section Stabilize the branch
@subsubheading Check out the relevant modules:
@smallexample
-$ for m in gdb insight dejagnu
+$ for m in gdb insight
do
( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
done
@itemize @bullet
@item
-the version
+The version.
@item
-the update date
+The update date.
@item
-who did it
+Who did it.
@end itemize
@smallexample
$ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
@end smallexample
-@item dejagnu/src/dejagnu/configure.in
-
-Dejagnu is more complicated. The version number is a parameter to
-@code{AM_INIT_AUTOMAKE}. Tweak it to read something like gdb-5.1.91.
-
-Don't forget to re-generate @file{configure}.
-
-Don't forget to include a @file{ChangeLog} entry.
-
-@smallexample
-$ emacs dejagnu/src/dejagnu/configure.in
-...
-c-x 4 a
-...
-c-x c-s c-x c-c
-$ ( cd dejagnu/src/dejagnu && autoconf )
-@end smallexample
-
@end table
@subsubheading Do the dirty work
do
( cd $m/src && gmake -f src-release $m.tar )
done
-$ ( m=dejagnu; cd $m/src && gmake -f src-release $m.tar.bz2 )
@end smallexample
If the top level source directory does not have @file{src-release}
do
( cd $m/src && gmake -f Makefile.in $m.tar )
done
-$ ( m=dejagnu; cd $m/src && gmake -f Makefile.in $m.tar.bz2 )
@end smallexample
@subsubheading Check the source files
$ cp */src/*.tar .
$ cp */src/*.bz2 .
$ ls -F
-dejagnu/ dejagnu-gdb-5.2.tar.bz2 gdb/ gdb-5.2.tar insight/ insight-5.2.tar
+gdb/ gdb-5.2.tar insight/ insight-5.2.tar
$ for m in gdb insight
do
bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
This file, which is posted as the official announcement, includes:
@itemize @bullet
@item
-General announcement
+General announcement.
@item
News. If making an @var{M}.@var{N}.1 release, retain the news from
earlier @var{M}.@var{N} release.
@item
-Errata
+Errata.
@end itemize
@item htdocs/index.html
These files include:
@itemize @bullet
@item
-announcement of the most recent release
+Announcement of the most recent release.
@item
-news entry (remember to update both the top level and the news directory).
+News entry (remember to update both the top level and the news directory).
@end itemize
These pages also need to be regenerate using @code{index.sh}.
@end smallexample
Insight is used since that contains more of the release than
-@value{GDBN} (@code{dejagnu} doesn't get tagged but I think we can live
-with that).
+@value{GDBN}.
@subsubheading Mention the release on the trunk
the available commands, and it has proven all too common for a change
to cause a significant regression that went unnoticed for some time.
-The @value{GDBN} testsuite uses the DejaGNU testing framework.
-DejaGNU is built using @code{Tcl} and @code{expect}. The tests
-themselves are calls to various @code{Tcl} procs; the framework runs all the
-procs and summarizes the passes and fails.
+The @value{GDBN} testsuite uses the DejaGNU testing framework. The
+tests themselves are calls to various @code{Tcl} procs; the framework
+runs all the procs and summarizes the passes and fails.
@section Using the Testsuite
projects / binutils.git / blobdiff