* Support Libraries::
* Coding::
* Porting GDB::
+* Releasing GDB::
* Testsuite::
* Hints::
* Index::
Several files control @value{GDBN}'s configuration for host systems:
@table @file
-@vindex XDEPFILES
@item gdb/config/@var{arch}/@var{xyz}.mh
Specifies Makefile fragments needed when hosting on machine @var{xyz}.
-In particular, this lists the required machine-dependent object files,
-by defining @samp{XDEPFILES=@dots{}}. Also specifies the header file
-which describes host @var{xyz}, by defining @code{XM_FILE=
-xm-@var{xyz}.h}. You can also define @code{CC}, @code{SYSV_DEFINE},
-@code{XM_CFLAGS}, @code{XM_ADD_FILES}, @code{XM_CLIBS}, @code{XM_CDEPS},
-etc.; see @file{Makefile.in}.
+Optionally specifies the header file which describes host @var{xyz}, by
+defining @code{XM_FILE= xm-@var{xyz}.h}. You can also define @code{CC},
+@code{SYSV_DEFINE}, @code{XM_CFLAGS}, @code{XM_ADD_FILES},
+@code{XM_CLIBS}, @code{XM_CDEPS}, etc.; see @file{Makefile.in}.
@item gdb/config/@var{arch}/xm-@var{xyz}.h
(@file{xm.h} is a link to this file, created by @code{configure}). Contains C
macro definitions describing the host system environment, such as byte
order, host C compiler and library.
-@item gdb/@var{xyz}-xdep.c
-Contains any miscellaneous C code required for this machine as a host.
-On most machines it doesn't exist at all. If it does exist, put
-@file{@var{xyz}-xdep.o} into the @code{XDEPFILES} line in
-@file{gdb/config/@var{arch}/@var{xyz}.mh}.
@end table
@subheading Generic Host Support Files
@code{bfd_seek}). FIXME, should be replaced by SEEK_SET instead,
which is the POSIX equivalent.
-@item MALLOC_INCOMPATIBLE
-Define this if the system's prototype for @code{malloc} differs from the
-@sc{ansi} definition.
-
@item MMAP_BASE_ADDRESS
When using HAVE_MMAP, the first mapping should go at this address.
@cindex cleanups
Cleanups are a structured way to deal with things that need to be done
-later. When your code does something (like @code{malloc} some memory,
-or open a file) that needs to be undone later (e.g., free the memory or
-close the file), it can make a cleanup. The cleanup will be done at
-some future point: when the command is finished, when an error occurs,
-or when your code decides it's time to do cleanups.
+later.
-You can also discard cleanups, that is, throw them away without doing
-what they say. This is only done if you ask that it be done.
+When your code does something (e.g., @code{xmalloc} some memory, or
+@code{open} a file) that needs to be undone later (e.g., @code{xfree}
+the memory or @code{close} the file), it can make a cleanup. The
+cleanup will be done at some future point: when the command is finished
+and control returns to the top level; when an error occurs and the stack
+is unwound; or when your code decides it's time to explicitly perform
+cleanups. Alternatively you can elect to discard the cleanups you
+created.
Syntax:
@item @var{old_chain} = make_cleanup (@var{function}, @var{arg});
Make a cleanup which will cause @var{function} to be called with
@var{arg} (a @code{char *}) later. The result, @var{old_chain}, is a
-handle that can be passed to @code{do_cleanups} or
-@code{discard_cleanups} later. Unless you are going to call
-@code{do_cleanups} or @code{discard_cleanups} yourself, you can ignore
-the result from @code{make_cleanup}.
+handle that can later be passed to @code{do_cleanups} or
+@code{discard_cleanups}. Unless you are going to call
+@code{do_cleanups} or @code{discard_cleanups}, you can ignore the result
+from @code{make_cleanup}.
@findex do_cleanups
@item do_cleanups (@var{old_chain});
-Perform all cleanups done since @code{make_cleanup} returned
-@var{old_chain}. E.g.:
+Do all cleanups added to the chain since the corresponding
+@code{make_cleanup} call was made.
+
+@findex discard_cleanups
+@item discard_cleanups (@var{old_chain});
+Same as @code{do_cleanups} except that it just removes the cleanups from
+the chain and does not call the specified functions.
+@end table
+
+Cleanups are implemented as a chain. The handle returned by
+@code{make_cleanups} includes the cleanup passed to the call and any
+later cleanups appended to the chain (but not yet discarded or
+performed). E.g.:
@example
make_cleanup (a, 0);
-old = make_cleanup (b, 0);
-do_cleanups (old);
+@{
+ struct cleanup *old = make_cleanup (b, 0);
+ make_cleanup (c, 0)
+ ...
+ do_cleanups (old);
+@}
@end example
@noindent
-will call @code{b()} but will not call @code{a()}. The cleanup that
-calls @code{a()} will remain in the cleanup chain, and will be done
-later unless otherwise discarded.@refill
+will call @code{c()} and @code{b()} but will not call @code{a()}. The
+cleanup that calls @code{a()} will remain in the cleanup chain, and will
+be done later unless otherwise discarded.@refill
+
+Your function should explicitly do or discard the cleanups it creates.
+Failing to do this leads to non-deterministic behavior since the caller
+will arbitrarily do or discard your functions cleanups. This need leads
+to two common cleanup styles.
+
+The first style is try/finally. Before it exits, your code-block calls
+@code{do_cleanups} with the old cleanup chain and thus ensures that your
+code-block's cleanups are always performed. For instance, the following
+code-segment avoids a memory leak problem (even when @code{error} is
+called and a forced stack unwind occurs) by ensuring that the
+@code{xfree} will always be called:
-@findex discard_cleanups
-@item discard_cleanups (@var{old_chain});
-Same as @code{do_cleanups} except that it just removes the cleanups from
-the chain and does not call the specified functions.
-@end table
+@example
+struct cleanup *old = make_cleanup (null_cleanup, 0);
+data = xmalloc (sizeof blah);
+make_cleanup (xfree, data);
+... blah blah ...
+do_cleanups (old);
+@end example
+
+The second style is try/except. Before it exits, your code-block calls
+@code{discard_cleanups} with the old cleanup chain and thus ensures that
+any created cleanups are not performed. For instance, the following
+code segment, ensures that the file will be closed but only if there is
+an error:
+
+@example
+FILE *file = fopen ("afile", "r");
+struct cleanup *old = make_cleanup (close_file, file);
+... blah blah ...
+discard_cleanups (old);
+return file;
+@end example
Some functions, e.g. @code{fputs_filtered()} or @code{error()}, specify
that they ``should not be called when cleanups are not in place''. This
@code{makeinfo} will split the document into one overall file and five
or so included files.
+@node Releasing GDB
+
+@chapter Releasing @value{GDBN}
+@cindex making a new release of gdb
+
+@section Before the branch
+
+The most important objective at this stage is to find and fix simple
+changes that become a pain to track once the branch is created. For
+instance, configuration problems that stop @value{GDBN} from even
+building. If you can't get the problem fixed, document it in the
+@file{PROBLEMS} file.
+
+@subheading Obsolete any code
+
+Mark as @kbd{OBSOLETE} any uninteresting targets or code files. This
+has a number of steps and is slow --- mainly to ensure that people have
+had a reasonable chance to respond. Remember, everything on the
+internet takes a week.
+
+@itemize @bullet
+@item
+announce the change on @email{gdb@@sources.redhat.com, GDB mailing list}
+@item
+wait a week
+@item
+announce the change on @email{gdb-announce@@sources.redhat.com, GDB
+Announcement mailing list}
+@item
+wait a week or so
+@item
+post / commit the change
+@end itemize
+
+@subheading Refresh any imported files.
+
+A number of files are taken from external repositories. They include:
+
+@itemize @bullet
+@item
+@file{texinfo/texinfo.tex}
+@item
+@file{config.guess} et.@: al.@:
+@end itemize
+
+and should be refreshed.
+
+@subheading Organize and announce the schedule.
+
+The following is a possible schedule. It is based on the rule-of-thumb
+that everything on the Internet takes a week. You may want to even
+increase those times further since an analysis of the actual data
+strongly suggests that the below is far to aggressive.
+
+@itemize @bullet
+@item
+announce it
+@item
+wait a week
+@item
+announce branch date
+@item
+wait a week
+@item
+Cut the branch
+@item
+wait a week
+@item
+start enjoying all the fun
+@end itemize
+
+As an aside, the branch tag name is probably regrettable vis:
+@file{gdb_N_M-YYYY-MM-DD-@{branch,branchpoint@}}.
+
+
+@section Building a Release
+
+@subheading Establish a few defaults.
+
+@example
+$ b=gdb_5_1_0_1-2002-01-03-branch
+$ v=5.1.0.1
+$ cd /sourceware/snapshot-tmp/gdbadmin-tmp/$b
+$ which autoconf
+/home/gdbadmin/bin/autoconf
+@end example
+
+NB: Check the autoconf version carefully. You want to be using
+@file{gdbadmin}'s version (which is really the version taken from the
+binutils snapshot). SWARE may have a different version installed.
+
+@subheading Check out the relevant modules:
+
+@example
+$ for m in gdb insight dejagnu; do
+( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
+done
+@end example
+
+NB: The reading of @file{.cvsrc} is disabled (@file{-f}) so that there
+isn't any confusion between what is written here and what CVS really
+does.
+
+@subheading Update the file @file{gdb/version.in} where applicable.
+
+@example
+$ for m in gdb insight; do echo $v > $m/src/gdb/version.in ; done
+@end example
+
+
+@subheading Mutter something about creating a @file{ChangeLog} entry. (both trunk and branch).
+
+@example
+$ emacs gdb/src/gdb/version.in
+c-x 4 a
+Bump version to 5.1.0.1.
+c-x c-s c-x c-c
+@end example
+
+ditto for @file{insight/src/gdb/version.in}
+
+@subheading Mutter something about updating @file{README}
+
+For dejagnu, edit @file{dejagnu/src/dejagnu/configure.in} and set it to
+gdb-$v and then regenerate configure. Mention this in the dejagnu
+@file{ChangeLog}.
+
+@example
+$ emacs dejagnu/src/dejagnu/configure.in
+...
+c-x 4 a
+Bump version to 5.1.0.1.
+* configure: Re-generate.
+c-x c-s c-x c-c
+$ ( cd dejagnu/src/dejagnu && autoconf )
+@end example
+
+@subheading Build the snapshot:
+
+@example
+$ for m in gdb insight dejagnu; do
+( cd $m/src && gmake -f Makefile.in $m.tar.bz2 )
+done
+@end example
+
+@subheading Do another @kbd{CVS update} to see what the damage is.
+
+@example
+$ ( cd gdb/src && cvs -q update )
+@end example
+
+You're looking for files that have mysteriously disappeared as the
+@kbd{distclean} has the habit of deleting files it shouldn't. Watch out
+for the @file{version.in} update cronjob.
+
+@subheading Copy all the @file{.bz2} files to the ftp directory:
+
+@example
+cp */src/*.bz2 ~ftp/.....
+@end example
+
+@subheading Something about @kbd{gzip}'ing them.
+
+@subheading Something about web pages?
+
+@subheading Something about documentation?
+
+@subheading Cleanup the release tree
+
+In particular you'll need to:
+
+@itemize @bullet
+@item
+Commit the changes to @file{ChangeLog} and @file{version.in}
+@item
+Tag the repository.
+@end itemize
+
+
+@section After the release
+
+Remove any @kbd{OBSOLETE} code.
+
+
@node Testsuite
@chapter Testsuite
projects / deliverable / binutils-gdb.git / blobdiff