gdb, native i686-pc-linux-gnu

Michael Elizabeth Chastain mec.gnu@mindspring.com
Tue Jan 27 01:31:00 GMT 2004


. Highlights of This Spin

  I separated the version of gdb and the version of the test suite.
  This enables me to compare (gdb 6.0, suite HEAD) versus
  (gdb HEAD, suite HEAD), which is much better than comparing
  (gdb 6.0, suite 6.0) versus (gdb HEAD, suite HEAD).

  It might help to think of "gdb" and "gdb-test-suite" as two separate
  packages which happen to be bundled together.

  I need "gdb-test-suite" to work with the released version of gdb as
  well as the current CVS versions (HEAD and carlton_dictionary-branch
  and drow-cplus-branch).  So if you change the output of gdb and change
  a test script to match, the test script should keep accepting the
  output of gdb 6.0 as well.

  I run each version of gdb with its matched version of gdb-test-suite
  and also with gdb HEAD.  The total list is:

    gdb 6.0 suite 6.0
    gdb 6.0 suite HEAD
    gdb HEAD suite HEAD
    gdb carlton_dictionary-branch suite carlton_dictionary-branch
    gdb carlton_dictionary-branch suite HEAD
    gdb drow-cplus-branch suite drow-cplus-branch
    gdb drow-cplus-branch suite HEAD

  This does add some complexity to interpreting test runs.  My XML
  record for a gdb test run has 17 attributes!  I've got more dimensions
  than Stephen Hawking on LSD.

  Meanwhile, gcc gcc-3_3-branch, gcc gcc-3_4-branch, and gcc HEAD have
  no regressions from the previous spin to this spin.  Same for all the
  gdb's.

  The current tables are always at

    http://www.shout.net/~mec/sunday/current/index.html

. Old Bugs Fixed

  . gcc gcc-3_4-branch

    Someone fixed a line number bug.

  . gcc HEAD

    Someone fixed a line number bug.

. New Bugs Detected

  None.

. PR Count

  Query executed 2004-01-27 01:24:10 UTC

  1534 matches found
    23 analyzed
   699 closed
    28 feedback
   768 open
     3 paperwork
    13 suspended
  1534 TOTAL

. Libiberty Testing

  . target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
      binutils HEAD                  742 tests, 0 failures
      gcc gcc-3_3-branch             649 tests, 0 failures
      gcc gcc-3_4-branch             742 tests, 0 failures
      gcc HEAD                       742 tests, 0 failures
      gdb HEAD                       742 tests, 0 failures
      gdb carlton_dictionary-branch  726 tests, 0 failures
      gdb drow-cplus-branch          742 tests, 0 failures

    For gcc tests, the test results are with binutils 2.14.
    The binutils version should not make a difference.

. Gdb Testing

  My tables are at

    http://www.shout.net/~mec/sunday/2004-01-23/index.html

  The previous tables are at

    http://www.shout.net/~mec/sunday/2004-01-19/index.html

  . Non-Pass Results

    gdb 6.0
      suite 6.0                         351 non-PASS results
      suite HEAD                        499 non-PASS results
    gdb carlton_dictionary-branch
      suite carlton_dictionary-branch   462 non-PASS results
      suite HEAD                        423 non-PASS results
    gdb drow-cplus-branch
      suite drow-cplus-branch           654 non-PASS results
      suite HEAD                        676 non-PASS results
    gdb HEAD
      suite HEAD                        430 non-PASS results

    I run each version of gdb with two test suites: the test suite that
    comes with that version of gdb and the test suite that comes with
    gdb HEAD.

  . gdb 6.0

    . suite 6.0

      . gdb.base/break.exp: breakpoint at start of multi line while conditional
        gdb.base/break.exp: breakpoint into
          FAIL -> PASS

          These results improved with gcc gcc-3_4-branch gcc HEAD, both
          dwarf-2 and stabs+.  Someone fixed a bug in these versions of gcc.

      . gdb.cp/annota3.exp: annotate-quit
          PASS -> FAIL

          Fluctuation in test result probably due to a signal handling
          race in the command loop.

            http://sources.redhat.com/gdb/bugs/544
            gdb.c++/annota2.exp: annotate-quit test sometimes fails

      . gdb.mi/mi*-pthreads.exp: check mi_thread_command_set: -thread-select [3456]
          blank -> PASS
          PASS -> blank

          When gdb operates on an inferior program with threads, gdb uses
          hidden breakpoints in the thread library to track events such as
          thread creation and thread destruction.

          This causes some programs to behave differently because they
          aren't prepared to handle the additional signals caused by the
          hidden breakpoints.  The test program for mi*-pthreads.exp is
          such a program.

            http://sources.redhat.com/ml/gdb/2003-09/msg00279.html
            http://sources.redhat.com/gdb/bugs/259

      . gdb.threads/print-threads.exp: Hit kill breakpoint, 10 (slow with kill breakpoint)
          PASS -> blank
      . gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
          blank -> PASS
          PASS -> blank

          Fluctuation with unknown cause.  Probably harmless.

      . gdb.threads/schedlock.exp: *
          PASS
        gdb.threads/schedlock.exp: thread 0 ran (didn't run)
        gdb.threads/schedlock.exp: thread 1 ran (didn't run)
        gdb.threads/schedlock.exp: thread 2 ran (didn't run)
        gdb.threads/schedlock.exp: thread 3 ran (didn't run)
        gdb.threads/schedlock.exp: thread 4 ran (didn't run)
        gdb.threads/schedlock.exp: thread 5 ran (didn't run)
          PASS
          FAIL

          All tests PASSed in all configurations except for the "thread N
          ran" tests.  Here are the counts per thread.

                      PASS  FAIL
            thread 0     3    29
            thread 1    28     4
            thread 2    30     2
            thread 3    32     0
            thread 4    31     2
            thread 5    32     0

    . suite HEAD

      This is the first spin with gdb 6.0 suite HEAD, so I have no
      comparison with a previous spin.

  . gdb HEAD

    . suite HEAD

      . gdb.base/break.exp: breakpoint at start of multi line while conditional
        gdb.base/break.exp: breakpoint into
          FAIL -> PASS
        gdb.base/sepdebug.exp: breakpoint at start of multi line while conditional
        gdb.base/sepdebug.exp: breakpoint into
          FAIL -> PASS

          Same analysis as gdb 6.0.

      . gdb.cp/annota2.exp: annotate-quit
          PASS -> KFAIL
        gdb.cp/annota3.exp: annotate-quit
          PASS -> FAIL

          Same analysis as gdb 6.0.

      . gdb.cp/namespace.exp: print 'C::cc'
        gdb.cp/namespace.exp: print 'E::cde'
        gdb.cp/namespace.exp: print 'F::cXf'
        gdb.cp/namespace.exp: print C::D::cd
        gdb.cp/namespace.exp: print C::cc
        gdb.cp/namespace.exp: print E::cde
        gdb.cp/namespace.exp: print E::ce
        gdb.cp/namespace.exp: print F::cXf
        gdb.cp/namespace.exp: print F::cXfX
        gdb.cp/namespace.exp: print c
        gdb.cp/namespace.exp: print cOtherFile
        gdb.cp/namespace.exp: print cX
        gdb.cp/namespace.exp: print cd
        gdb.cp/namespace.exp: print shadow
        gdb.cp/namespace.exp: ptype C
        gdb.cp/namespace.exp: ptype C::CClass
        gdb.cp/namespace.exp: ptype C::CClass::NestedClass
        gdb.cp/namespace.exp: ptype C::NestedClass
        gdb.cp/namespace.exp: ptype C::OtherFileClass
        gdb.cp/namespace.exp: ptype CCLass
        gdb.cp/namespace.exp: ptype CCLass::NestedClass
        gdb.cp/namespace.exp: ptype E
        gdb.cp/namespace.exp: ptype OtherFileClass
          FAIL -> PASS

          These tests improved their results with gcc gcc-3_4-branch
          -gdwarf-2 and gcc HEAD -gdwarf-2.  David C improved the test
          program so that gcc cannot optimize away unused types.
          Beyond that, someone may have improved gdb or gcc as well.

      . gdb.cp/rtti.exp: continue to breakpoint: end of constructors
          PASS -> blank
        gdb.cp/rtti.exp: continue to breakpoint: end of constructors in func
        gdb.cp/rtti.exp: continue to breakpoint: end of constructors in main
          blank -> PASS
          blank -> PASS
        gdb.cp/rtti.exp: print *obj
          blank -> PASS
          blank -> FAIL

          David C improved the test script.

          Test "print *obj" PASSed with:
            gcc 2.95.3 -gdwarf-2
            gcc 3.2-7-rh -gdwarf-2
            gcc 3.3.2 -gdwarf-2
          Test "print *obj" FAILed with:
            gcc gcc-3_4-branch -gdwarf-2
            gcc HEAD -gdwarf-2
            gcc 2.95.3 -gstabs+
            gcc v3 -gstabs+

      . gdb.mi/mi-stack.exp: stack locals listing 2
          blank -> PASS

          Nick R added a test.

      . gdb.mi/mi-var-child.exp: listing of names and values of children
          blank -> PASS

          Nick R added a test.

      . gdb.threads/schedlock.exp: *
          PASS
        gdb.threads/schedlock.exp: thread 0 ran (didn't run)
        gdb.threads/schedlock.exp: thread 1 ran (didn't run)
        gdb.threads/schedlock.exp: thread 2 ran (didn't run)
        gdb.threads/schedlock.exp: thread 3 ran (didn't run)
        gdb.threads/schedlock.exp: thread 4 ran (didn't run)
        gdb.threads/schedlock.exp: thread 5 ran (didn't run)
          PASS
          FAIL

          All tests PASSed in all configurations except for the "thread N
          ran" tests.  Here are the counts per thread.

                      PASS  FAIL
            thread 0     5    27
            thread 1    29     3
            thread 2    30     2
            thread 3    31     1
            thread 4    30     2
            thread 5    32     0

  . gdb carlton_dictionary-branch

    . suite carlton_dictionary-branch

      . gdb.base/break.exp: breakpoint at start of multi line while conditional
        gdb.base/break.exp: breakpoint into
          FAIL -> PASS

          Same analysis as gdb 6.0.

      . gdb.threads/schedlock.exp: *
          PASS
        gdb.threads/schedlock.exp: thread 0 ran (didn't run)
        gdb.threads/schedlock.exp: thread 1 ran (didn't run)
        gdb.threads/schedlock.exp: thread 2 ran (didn't run)
        gdb.threads/schedlock.exp: thread 3 ran (didn't run)
        gdb.threads/schedlock.exp: thread 4 ran (didn't run)
        gdb.threads/schedlock.exp: thread 5 ran (didn't run)
          PASS
          FAIL

          All tests PASSed in all configurations except for the "thread N
          ran" tests.  Here are the counts per thread.

                      PASS  FAIL
            thread 0     3     7
            thread 1     8     2
            thread 2    10     0
            thread 3    10     0
            thread 4     8     2
            thread 5    10     0

    . suite HEAD

      This is the first spin with gdb carlton_dictionary-branch suite
      HEAD, so I have no comparison with a previous spin.

  . gdb drow-cplus-branch

    . suite drow-cplus-branch

      . gdb.base/break.exp: breakpoint at start of multi line while conditional
        gdb.base/break.exp: breakpoint into
          FAIL -> PASS

          Same analysis as gdb 6.0.

      . gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
          blank -> PASS

          Fluctuation with unknown cause.  Probably harmless.

      . gdb.threads/schedlock.exp: *
          PASS
        gdb.threads/schedlock.exp: thread 0 ran (didn't run)
        gdb.threads/schedlock.exp: thread 1 ran (didn't run)
        gdb.threads/schedlock.exp: thread 2 ran (didn't run)
        gdb.threads/schedlock.exp: thread 3 ran (didn't run)
        gdb.threads/schedlock.exp: thread 4 ran (didn't run)
        gdb.threads/schedlock.exp: thread 5 ran (didn't run)
          PASS
          FAIL

          All tests PASSed in all configurations except for the "thread N
          ran" tests.  Here are the counts per thread.

                      PASS  FAIL
            thread 0     1     9
            thread 1     9     1
            thread 2     9     1
            thread 3    10     0
            thread 4    10     0
            thread 5     9     0

    . suite HEAD

      This is the first spin with gdb drow-cplus-branch suite HEAD, so I
      have no comparison with a previous spin.

. Test Matrix

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  dejagnu    => dejagnu 1.4.3
  expect     => expect 5.39
  tcl        => tlc 8.4.5
  suite      => 6.0, HEAD, carlton_dictionary-branch, drow-cplus-branch
  gdb        => 6.0, HEAD, carlton_dictionary-branch, drow-cplus-branch
  cc         => gcc 2.95.3, gcc 3.2-7-rh, gcc 3.3.2, gcc gcc-3_3-branch, gcc gcc-3_4-branch, gcc HEAD
  as         => binutils 2.13.90.0.2-rh, binutils 2.14, binutils HEAD
  ld         => binutils 2.13.90.0.2-rh, binutils 2.14, binutils HEAD
  libc       => glibc 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2
  count         136

  'target' and 'host' are gnu configuration triples.

  'osversion' is the host operating system name, which is additional
  information beyond 'host'.

  'tcl', 'expect', and 'dejagnu' are host packages to run tests.

  'suite' is the version name of the gdb test suite.

  'gdb' is a version name.

  'cc', 'as', 'ld', and 'libc' are package names.

  versions starting with a digit are official releases or snapshots.
  versions starting with a digit and ending with '-rh' are
    vendor-supplied official releases on my red hat linux host.
  versions named 'HEAD' are the cvs HEAD, also known as 'mainline' or 'trunk'.
  versions with any other name are cvs branches.

  'gformat' is the debugging information format.
  'glevel' is the debugging level.

  'count' is the total number of configurations tested.

  as/ld are always matched.

  The vendor gcc is available only with vendor as/ld.

  gdb carlton_dictionary_branch and gdb drow-cplus-branch are tested
  only with binutils 2.14, which means they are not tested with vendor
  gcc.

  Each version gdb is tested with its own gdb-test-suite and also with
  gdb-test-suite HEAD.

. Package Versions

  . This Spin

    binutils  HEAD                       2004-01-22 23:13:58 UTC
    gcc       HEAD                       2004-01-23 03:08:37 UTC
    gcc       gcc-3_3-branch             2004-01-23 03:15:28 UTC
    gcc       gcc-3_4-branch             2004-01-23 03:21:08 UTC
    gdb       HEAD                       2004-01-24 03:11:40 UTC
    gdb       carlton_dictionary-branch  2004-01-24 03:13:52 UTC
    gdb       drow-cplus-branch          2004-01-24 03:15:58 UTC

  . Last Spin

    binutils  HEAD                       2004-01-19 06:08:35 UTC
    gcc       HEAD                       2004-01-19 06:29:00 UTC
    gcc       gcc-3_3-branch             2004-01-19 06:36:23 UTC
    gcc       gcc-3_4-branch             2004-01-19 06:41:21 UTC
    gdb       HEAD                       2004-01-19 20:58:13 UTC
    gdb       carlton_dictionary-branch  2004-01-19 21:00:35 UTC
    gdb       drow-cplus-branch          2004-01-19 21:03:25 UTC

. Host Software

  . host=i686-pc-linux-gnu, osversion=red-hat-8.0

    make 3.79.1
    binutils 2.14
    gcc 3.3.2
    flex 2.5.4
    bison 1.875
    tcl 8.4.5
    expect 5.39
    dejagnu 1.4.3

  The sources.redhat.com cvs repository has its own versions of tcl,
  expect, and dejagnu.  I don't have the resources to test with both
  tcl/expect/dejagnu stacks, so I choose the stock stack for my test
  bed.
  
  The sources.redhat.com version of tcl is nearly identical to tcl
  8.4.1.  The sources.redhat.com version of expect dates from
  1998-06-15.  The sources.redhat.com version of dejagnu is nearly
  identical to dejagnu 1.4.3.

  I have packaged and published my scripts to manage the baseline
  software.  They are called Migchain (Michael's Gnu Toolchain) and
  Migbat (Michael's Gnu Build and Test), and they are licensed under the
  GPL.

    ftp://ftp.shout.net/pub/users/mec/migchain/migchain-0.8.tar.gz
    ftp://ftp.shout.net/pub/users/mec/migbat/migbat-0.8.tar.gz

. Test Bed Changes Since Last Report

  I separated gdb and gdb-test-suite.

  I tried to enhance the result cruncher to keep the test names in the
  same order as the input files, but the problem kicked my ass.  One
  problem is that tests change their name for several reasons.  Another
  problem is that many test scripts like to pop up a FAIL without a
  corresponding PASS if something goes really wrong.
  
  Another problem is that the natural Perl data structures take too much
  memory, so I have to use a lot of "vec" strings, and "vec" strings can
  hold integers and nothing else.  I swear, the data structures end up
  looking like FORTRAN.



More information about the Gcc-testresults mailing list