This is the mail archive of the gdb-testers@sources.redhat.com 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]

Re: [Fwd: GDB 5.2.92 available]


Looks fine to me.  Recommended for release.

Proofread a little and tested a little.  I picked some nits about version
numbers in doco.  Stick my nits on the shelf for a week and then see if
any of them are worth caring about.

In my test results, gdb.base/selftest.exp is acting up, very probably
a glitch in my test bed.  gdb.threads/killed.exp has an unstable test
and is worth keeping an eye on in mainline.

Michael C

===

Proofreading

  I diff'ed gdb-5.2.91.tar.bz2 versus gdb-5.2.92 and proofread the diff.

  The changes are:

    many subsititions 5.2.91 => 5.3.
    delete reference to pr gdb/725
    add David Carlton as C++ maintainer
    doc/gdb.info file got its tag table regenerated
      (because strlen("5.2.91") != strlen("5.3")

  All copacetic.

  More interesting would be any places which still say 5.2.91 (or older
  versions) and need updating.

    % cd 5.3
    % grep -r '5\.[012]' *

  I found 4 places which refer to gdb version number and aren't
  being updated.  All of them are in doco files and appear harmless.

    gdb/TODO
      This isn't a version number problem; the file is just showing its age.

    gdb/config/djgpp/README
      This file includes examples with gdb version number in them (gdb 5.2).
      It says specifically that users should change "5.2" to the version
      that they are working with, so there should be little user confusion.
      It would be nice to put this file on the list of files for
      automagically bumping version numbers.

    doc/gdbint.texinfo
      node "Releasing GDB" refers to versions 5.1 (previous) and 5.2
      (current) and draws its examples from that.  Presumably anyone who
      reads "Releasing GDB" understands that version numbers do change
      with time.  :)

    gdb/mi/gdbmi.texinfo
      This file has an example from gdb 5.2.1.  No big deal.

Testing

  I ran through a small test matrix

    target   => native
    host     => i686-pc-linux-gnu%rh-8
    gdb      => 5.2.91, 5.3
    gcc      => 2.95.3, 3.2.1, 3.2-7-rh
    binutils => 2.13.90.0.2-rh, 2.13.1
    gformat  => dwarf-2, stabs+
    glibc    => 2.2.93-5-rh
    count    => 20 = 1*1*2*(2*2+1)*2*1

  Note that I did not test with cvs versions of gcc or binutils.

  The tables are here:

    http://www.shout.net/~mec/sunday/2002-12-11/index.html

  The most interesting tables is "compare by gdb version".
  "compare by date: two dates" shows changes from 5.2.91 to last week.
  (any such changes are due to testbed changes + unstable tests).

  gdb.base/pc-fp.exp: get value of $fp (0xNNNNNNNN)

    Noise, stack address in test name noise.  The test passes with
    different names in different configurations.

  gdb.base/selftest.exp: unknown source line near main
  gdb.base/selftest.exp: step into xmalloc call

    I just upgraded my test bed baseline compiler from gcc 2.95.3 to
    gcc 3.2.1.  This is the compiler that I build gdb with, not the
    set of compilers that I build test programs with.  gdb.base/selftest.exp
    is sensitive to this compiler and so 5.2.91 regressed from the last
    report to this one.  More analysis needed.  5.3 is behaving the same
    as 5.2.91.

  gdb.c++/annota2.exp: annotate-quit

    pr gdb/544: gdb.c++/annota2.exp: annotate-quit test sometimes fails
    http://sources/redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=544

    Nothing new here.

  gdb.java/jmisc.exp: Couldn't compile /berman/migchain/source/gdb-N.NN/...
  gdb.java/jmisc1.exp: Couldn't compile /berman/migchain/source/gdb-N.NN/...
  gdb.java/jmisc2.exp: Couldn't compile /berman/migchain/source/gdb-N.NN/...

    gcc 2.95.3 did not include the java compiler, so these tests have
    result UNTESTED.  The test name includes the gdb source directory
    so there is version number noise.

  gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily

    This test PASSed with 5.2.91 and FAILed with 5.3 in these configurations:
      gcc=2.95.3 binutils=vendor gformat=dwarf-2,
      gcc=3.2.1  binutils=vendor gformat=dwarf-2
      gcc=vendor binutils=vendor gformat=dwarf-2

    This test FAILed with 5.2.91 and PASSed with 5.3 in these configurations:
      gcc=vendor binutils=vendor gformat=stabs+

    I don't have analysis for this.

  gdb.threads/schedlock.exp: *

    This test is unstable and unusable in gdb 5.2.91 and gdb 5.3.


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