Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: {PATCH] gdbint.texi [was Re: RFC: MI output during program execution]
Date: Sun, 14 May 2006 07:35:00 -0000	[thread overview]
Message-ID: <17510.53117.846489.479963@farnswood.snap.net.nz> (raw)
In-Reply-To: <20060504150414.GE32605@nevyn.them.org>

 > >    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
  


  parent reply	other threads:[~2006-05-14  6:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <17458.60694.135878.624750@farnswood.snap.net.nz>
     [not found] ` <20060404220637.GA12064@nevyn.them.org>
     [not found]   ` <17486.36188.127822.347550@farnswood.snap.net.nz>
     [not found]     ` <20060504150414.GE32605@nevyn.them.org>
     [not found]       ` <17508.18716.564160.93092@farnswood.snap.net.nz>
     [not found]         ` <20060512124331.GA3460@nevyn.them.org>
2006-05-13  2:28           ` New branch " Nick Roberts
2006-05-13  8:03             ` Daniel Jacobowitz
2006-05-15 16:58               ` PAUL GILLIAM
2006-05-13  9:07             ` Eli Zaretskii
2006-05-13  9:21               ` Nick Roberts
2006-05-13 10:34                 ` Eli Zaretskii
2006-05-13 10:59                   ` Nick Roberts
2006-05-14  7:35       ` Nick Roberts [this message]
2006-05-14 19:45         ` {PATCH] gdbint.texi " Eli Zaretskii
2006-05-15  0:56           ` {PATCH] gdbint.texi Nick Roberts
2006-05-15 10:19             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17510.53117.846489.479963@farnswood.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox