This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

{PATCH] gdbint.texi [was Re: RFC: MI output during program execution]


 > >    cvs rtag nickrob-200604026-branchpoint gdb+dejagnu
 > 
 > Right.  You can just use the gdb module nowadays; the only difference
 > is that gdb+dejagnu will include tcl by accident.  Expect and DejaGNU
 > aren't in the tree any more.  Could I persuade you to update the
 > manual?

Actually I must have looked http://sourceware.org/gdb/current/ which still
refers to gdb+dejagnu, so need updating.

gdbint.texinfo uses gdb as a module name in the node "Versions and Branches"
but still refers to dejagnu elsewhere so I've tried to remove all those which
are inappropriate.  Andrew specifically refers to releases 5.0, 5.1 and 5.2 but
I've not tried to generalise this or update to more recent numbers but Joel
might like to do this as he goes through the process for GDB 6.5.

I've also changed a bit of punctuation and spelling.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2006-05-14  Nick Roberts  <nickrob@snap.net.nz>

	* gdbint.texinfo: Remove details for including DejaGnu.

*** gdbint.texinfo	24 Apr 2006 12:18:04 +1200	1.242
--- gdbint.texinfo	14 May 2006 18:26:44 +1200	
***************
*** 279,285 ****
  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
  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
--- 279,285 ----
  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 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
***************
*** 405,411 ****
  
  @item
  It's easier to see that the analyzer is correct: you just see
! whether the analyzer properly (albiet conservatively) simulates
  the effect of each instruction.
  
  @item
--- 405,411 ----
  
  @item
  It's easier to see that the analyzer is correct: you just see
! whether the analyzer properly (albeit conservatively) simulates
  the effect of each instruction.
  
  @item
***************
*** 918,924 ****
  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
  method implemented on the target side.
  
  A corefile can be used to save an image of target memory and register
--- 918,924 ----
  of open files and devices.
  
  There are a number of ways in which checkpoints may be implemented
! 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
***************
*** 931,937 ****
  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 
  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.
--- 931,937 ----
  is used to implement checkpoints on Linux, and in principle might
  be used on other systems.
  
! 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.
***************
*** 6026,6040 ****
  $  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
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
! -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight+dejagnu
  $  ^echo ^^
  ...
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight+dejagnu
  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
  $  ^echo ^^
  ...
  $
--- 6026,6040 ----
  $  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
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
! -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
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight
  $  ^echo ^^
  ...
  $
***************
*** 6042,6057 ****
  
  @itemize @bullet
  @item
! 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
  @item
! Insight (which includes GDB) and dejagnu are all tagged at the same time
  @item
! @file{version.in} gets bumped to avoid version number conflicts
  @item
! the reading of @file{.cvsrc} is disabled using @file{-f}
  @end itemize
  
  @subheading Update @file{version.in}
--- 6042,6057 ----
  
  @itemize @bullet
  @item
! By using @kbd{-D YYYY-MM-DD-gmt} the branch is forced to an exact
  date/time.
  @item
! The trunk is first tagged so that the branch point can easily be found.
  @item
! Insight which includes GDB is tagged at the same time.
  @item
! @file{version.in} gets bumped to avoid version number conflicts.
  @item
! The reading of @file{.cvsrc} is disabled using @file{-f}.
  @end itemize
  
  @subheading Update @file{version.in}
***************
*** 6079,6088 ****
  @itemize @bullet
  @item
  @file{0000-00-00} is used as a date to pump prime the version.in update
! mechanism
  @item
  @file{.90} and the previous branch version are used as fairly arbitrary
! initial branch version number
  @end itemize
  
  
--- 6079,6088 ----
  @itemize @bullet
  @item
  @file{0000-00-00} is used as a date to pump prime the version.in update
! mechanism.
  @item
  @file{.90} and the previous branch version are used as fairly arbitrary
! initial branch version number.
  @end itemize
  
  
***************
*** 6097,6105 ****
  
  @itemize @bullet
  @item
! a daily timestamp is added to the file @file{version.in}
  @item
! the new branch is included in the snapshot process
  @end itemize
  
  @noindent
--- 6097,6105 ----
  
  @itemize @bullet
  @item
! A daily timestamp is added to the file @file{version.in}.
  @item
! The new branch is included in the snapshot process.
  @end itemize
  
  @noindent
***************
*** 6140,6153 ****
  
  @itemize @bullet
  @item
! the branch tag
  @item
! how to check out the branch using CVS
  @item
! the date/number of weeks until the release
  @item
! the branch commit policy
! still holds.
  @end itemize
  
  @section Stabilize the branch
--- 6140,6152 ----
  
  @itemize @bullet
  @item
! The branch tag.
  @item
! How to check out the branch using CVS.
  @item
! The date/number of weeks until the release.
  @item
! The branch commit policy still holds.
  @end itemize
  
  @section Stabilize the branch
***************
*** 6206,6212 ****
  @subsubheading Check out the relevant modules:
  
  @smallexample
! $  for m in gdb insight dejagnu
  do
  ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
  done
--- 6205,6211 ----
  @subsubheading Check out the relevant modules:
  
  @smallexample
! $  for m in gdb insight
  do
  ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
  done
***************
*** 6250,6260 ****
  
  @itemize @bullet
  @item
! the version
  @item
! the update date
  @item
! who did it
  @end itemize
  
  @smallexample
--- 6249,6259 ----
  
  @itemize @bullet
  @item
! The version.
  @item
! The update date.
  @item
! Who did it.
  @end itemize
  
  @smallexample
***************
*** 6290,6313 ****
  $  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
--- 6289,6294 ----
***************
*** 6319,6325 ****
  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}
--- 6300,6305 ----
***************
*** 6330,6336 ****
  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
--- 6310,6315 ----
***************
*** 6365,6371 ****
  $  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
  $  for m in gdb insight
  do
  bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
--- 6344,6350 ----
  $  cp */src/*.tar .
  $  cp */src/*.bz2 .
  $  ls -F
! 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
***************
*** 6470,6481 ****
  This file, which is posted as the official announcement, includes:
  @itemize @bullet
  @item
! 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
  @end itemize
  
  @item htdocs/index.html
--- 6449,6460 ----
  This file, which is posted as the official announcement, includes:
  @itemize @bullet
  @item
! 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.
  @end itemize
  
  @item htdocs/index.html
***************
*** 6484,6492 ****
  These files include:
  @itemize @bullet
  @item
! announcement of the most recent release
  @item
! 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}.
  
--- 6463,6471 ----
  These files include:
  @itemize @bullet
  @item
! Announcement of the most recent release.
  @item
! 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}.
  
***************
*** 6573,6580 ****
  @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).
  
  @subsubheading Mention the release on the trunk
  
--- 6552,6558 ----
  @end smallexample
  
  Insight is used since that contains more of the release than
! @value{GDBN}.
  
  @subsubheading Mention the release on the trunk
  
***************
*** 6627,6636 ****
  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.
  
  @section Using the Testsuite
  
--- 6605,6613 ----
  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.  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
  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]