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]

gdb, native i686-pc-linux-gnu


. Highlights of This Spin

  binutils binutils-2_15-branch showed some cvs activity, but I am not
  picking up the branch again unless I hear that there might actually be
  another release from this branch.

  gcc HEAD had a change in debug info for c++ synthetic methods.  gcc
  used to emit debug info for these methods even if the methods were not
  actually generated.  It no longer does this.  In particular, empty
  classes now have empty debug info.  This caused some differences in
  gdb behavior: some cosmetic changes and some actual bugs.

  My current tables are always at

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

. Gdb Regression Summary

  gdb drow_intercu-20040221-branch versus gdb HEAD
    not analyzed

  gdb HEAD versus gdb gdb_6_2-branch
    no regressions

  gdb gdb_6_2-branch versus gdb 6.1.1
    gdb/1650

. Gcc Regression Summary

  gcc HEAD versus gcc 3.4.1
    gcc/13974 gcc/14049 gcc/14860
    gdb/1656 gdb/1734 gdb/1735

  gcc gcc-3_4-branch versus gcc 3.4.1
    no improvements and no regressions

  gcc 3.4.1 versus gcc 3.3.4
    gcc/12267 gcc/13708 gcc/13956
    gdb/1537 gdb/1540

  gcc gcc-3_3-branch versus gcc 3.3.4
    no improvements and no regressions

  gcc 3.3.4 versus gcc 2.95.3
    not analyzed

. Binutils Regression Summary

  binutils HEAD versus binutils 2.15
    no improvements and no regressions

. Old Bugs Fixed Since Last Spin

  . gdb HEAD

    http://sources.redhat.com/gdb/bugs/1505
    [regression] gdb prints a bad backtrace for a thread

      Fixed.

. New Bugs Detected Since Last Spin

  . gdb 6.1.1

    http://sources.redhat.com/gdb/bugs/1734
    gdb loses the name of an empty class

      This is a bug in gdb 6.1.1 and gdb 6.2 with empty classes.  It
      happens with gcc HEAD because empty classes now have empty debug
      info.

    http://sources.redhat.com/gdb/bugs/1735
    schedlock.c, thread-specific.c don't compile with gcc HEAD

      gcc HEAD sprouted a new warning.

. PR Count

  Query executed 2004-08-06 10:45:59 UTC

  1735 matches found
    20 analyzed
   821 closed
    24 feedback
   850 open
     3 paperwork
    17 suspended
  1735 TOTAL

. Libiberty Testing

  . target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
      binutils HEAD                     746 tests, 0 failures
      gcc gcc-3_3-branch                649 tests, 0 failures
      gcc gcc-3_4-branch                745 tests, 0 failures
      gcc HEAD                          746 tests, 0 failures
      gdb HEAD                          746 tests, 0 failures
      gdb drow_intercu-20040221-branch  745 tests, 0 failures
      gdb gdb_6_2-branch                746 tests, 0 failures

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

. Gdb Testing

  My tables are at

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

  The previous tables are at

    http://www.shout.net/~mec/sunday/2004-07-15/index.html

  . Non-Pass Results

    gdb 6.1.1
      suite 6.1.1                         1055 non-PASS results
      suite HEAD                           987 non-PASS results
    gdb gdb_6_2-banch
      suite gdb_6_2-branch                1030 non-PASS results
      suite HEAD                           979 non-PASS results
    gdb HEAD
      suite HEAD                           979 non-PASS results
    gdb drow_intercu-20040221-branch
      suite drow_intercu-20040221-branch  1066 non-PASS results
      suite HEAD                           989 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.1.1

    . suite 6.1.1

      . gdb.base/bigcore.exp: extract next heap
        gdb.base/bigcore.exp: extract prev heap
          PASS -> blank
        gdb.base/bigcore.exp: extract next heap (stop at 50)
        gdb.base/bigcore.exp: extract prev heap (stop at 50)
          blank -> PASS

          Not analyzed.  Probably harmless.

      . gdb.cp/class2.exp: print object with no data fields
          PASS -> FAIL
        gdb.cp/rtti.exp: print *obj
        gdb.cp/rtti.exp: print *obj3
          PASS -> FAIL
        gdb.cp/rtti.exp: print *e2
          PASS -> KFAIL

          This happened with gcc HEAD -gdwarf-2.
          
          For an empty class, gcc HEAD used to emit debug info for some
          synthetic methods.  Now gcc HEAD emits a DW_TAG_structure_type
          with no members at all.  gdb 6.1.1 prints "<incomplete type>"
          for this, which is a bug in gdb 6.1.1.  gdb 6.2 is okay, so I
          don't have to file a gdb PR.

      . gdb.cp/classes.exp: ptype *
        gdb.cp/derivation.exp: ptype *
        gdb.cp/inherit.exp: print type of anonymous union
        gdb.cp/inherit.exp: ptype *
        gdb.cp/local.exp: ptype *
        gdb.cp/namespace.exp: ptype *
        gdb.cp/overload.exp: ptype *
        gdb.cp/pr-1553.exp: ptype *
        gdb.cp/templates.exp: ptype *
        gdb.cp/virtfunc.exp: ptype *
          PASS -> PASS
          PASS -> FAIL
          FAIL -> PASS
          KFAIL -> FAIL

          This happened with gcc HEAD -gdwarf-2 and gcc HEAD -gstabs+.

          This is cosmetic fallout from synthetic method debug info.
          First, with gcc -gstabs+, ptype shows the synthetic methods.
          So changes in the synthetic method debug info cause changes in
          gdb output.

          Second, and more subtle, gdb chooses whether to print "class"
          or "struct" for a c++ class or struct.  The decision logic is
          not just "use the keyword from the original source code", but
          depends on details such as whether the class/struct has any
          member functions or not.  The removal of synthetic member
          functions caused some ptype output to change from "class" to
          "struct".  Also, the removal of the synthetic member functions
          caused the optional initial access specifier in "class ... {
          private:" or "struct ...  { public:" to change in some cases.

          Both these changes are cosmetic.  I've already updated
          gdb.cp/*.exp in suite HEAD.  I've got a further update in
          progress to write a new cp_test_ptype_class which will be much
          more flexible than the existing code.

      . gdb.cp/inherit.exp: print g_vB
        gdb.cp/inherit.exp: print g_vC
        gdb.cp/inherit.exp: print g_vE
          PASS -> FAIL

          This happened with gcc HEAD -gstabs+.

          This is a cosmetic change in gdb output.

      . gdb.cp/pr-1210.exp: print *obj
        gdb.cp/pr-1210.exp: print obj->myB
          PASS -> FAIL

          This happened with gcc HEAD -gdwarf-2.

            http://sources.redhat.com/gdb/bugs/1734
            gdb loses the name of an empty class

          This is a bug in gdb exposed by the changes in gcc HEAD debug
          info.  Empty classes now have empty debug info.

      . gdb.threads/schedlock.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
        gdb.threads/thread-specific.exp: Couldn't compile /.../gdb.threads/thread-specific.c: unrecognized error
          blank -> UNSUPPORTED
        gdb.threads/schedlock.exp: *
        gdb.threads/thread-specific.exp
          * -> blank

          This happened with gcc HEAD.

            http://sources.redhat.com/gdb/bugs/1735
            schedlock.c, thread-specific.c don't compile with gcc HEAD

          gcc HEAD sprouted a new warning.

      . 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 non-gcc-HEAD configurations except for
          the "thread N ran" tests.  Here are the counts per thread.

                   t0  t1  t2  t3  t4  t5
            PASS    0  22  22  22  22  22
            FAIL   22   0   0   0   0   0

  . gdb 6.1.1

    . suite HEAD

      . gdb.arch/i386-prologue.exp: continue to gdb1718
          blank -> PASS
        gdb.arch/i386-prologue.exp: backtrace in gdb1718
          blank -> FAIL
        gdb.arch/i386-prologue.exp: saved registers in gdb 1718
          blank -> KFAIL

          Mark Kettenis improved the test script.

      . gdb.base/logical.exp: *
          blank -> PASS
          PASS -> blank

          Andrew Cagney improved the test script.

      . gdb.base/radix.exp: *
          blank -> PASS
          blank -> KFAIL
          PASS -> blank
          XFAIL -> blank

          Michael Chastain improved the test script.

      . gdb.base/restore.exp: *
          blank -> PASS
          PASS -> blank

          Andrew Cagney improved the test script.

      . gdb.base/selftest.exp: *
          PASS -> blank
        gdb.gdb/selftest.exp: *
          blank -> PASS

          Andrew Cagney moved the test script.

      . gdb.base/signals.exp: *
          blank -> PASS
          blank -> FAIL
          blank -> KFAIL
          blank -> XFAIL
          PASS -> blank
          XFAIL -> blank

          Andrew Cagney improved the test script.

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

          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.cp/class2.exp: print object with no data fields
          PASS -> FAIL
        gdb.cp/rtti.exp: print *obj
        gdb.cp/rtti.exp: print *obj3
          PASS -> FAIL
        gdb.cp/rtti.exp: print *e2
          PASS -> KFAIL

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . gdb.cp/classes.exp: ptype obj_with_enum
        gdb.cp/derivation.exp: ptype a_instance
        gdb.cp/inherit.exp: print g_vB
        gdb.cp/inherit.exp: print g_vC
        gdb.cp/inherit.exp: print g_vE
        gdb.cp/local.exp: ptype InnerLocal
        gdb.cp/overload.exp: ptype foo_instance1
        gdb.cp/templates.exp: ptype T5<int>
        gdb.cp/templates.exp: ptype T5i
          FAIL -> PASS
          PASS -> PASS

          This happened with gcc HEAD -gstabs+.  This is a mixture of
          gcc HEAD synthetic info debug changes and test suite changes
          in response.

      . gdb.cp/inherit.exp: ptype tagless struct
        gdb.cp/inherit.exp: ptype variable of type tagless struct
          PASS -> PASS

          Michael Chastain improved the test script.

      . gdb.cp/pr-1210.exp: print *obj
        gdb.cp/pr-1210.exp: print obj->myB
          PASS -> FAIL

          Same analysis as gdb 6.1.1 suite 6.1.1.

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

          Fluctuation with unknown cause.  Probably harmless.

      . gdb.threads/schedlock.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
        gdb.threads/thread-specific.exp: Couldn't compile /.../gdb.threads/thread-specific.c: unrecognized error
        gdb.threads/watchthreads.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
          blank -> UNSUPPORTED
        gdb.threads/schedlock.exp: *
        gdb.threads/thread-specific.exp
          * -> blank

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . 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 non-gcc-HEAD configurations except for
          the "thread N ran" tests.  Here are the counts per thread.

                   t0  t1  t2  t3  t4  t5
            PASS    1   9  10  10  10  10
            FAIL    9   1   0   0   0   0

      . gdb.threads/watchthreads.exp: *
          blank -> PASS
          blank -> FAIL

          Jeff Johnston wrote a new test script.

  . gdb gdb_6_2-branch

    . suite gdb_6_2-branch 

      . gdb.cp/classes.exp: ptype *
        gdb.cp/derivation.exp: ptype *
        gdb.cp/inherit.exp: print type of anonymous union
        gdb.cp/inherit.exp: ptype *
        gdb.cp/local.exp: ptype *
        gdb.cp/namespace.exp: ptype *
        gdb.cp/overload.exp: ptype *
        gdb.cp/templates.exp: ptype *
        gdb.cp/virtfunc.exp: ptype *
          PASS -> PASS
          PASS -> FAIL
          KFAIL -> FAIL

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . gdb.cp/inherit.exp: print g_vB
        gdb.cp/inherit.exp: print g_vC
        gdb.cp/inherit.exp: print g_vE
          PASS -> FAIL

          This happened with gcc HEAD -gstabs+.

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . gdb.cp/pr-1210.exp: print *obj
        gdb.cp/pr-1210.exp: print obj->myB
          PASS -> FAIL

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . gdb.threads/manythreads.exp: GDB exits after stopping multithreaded program
        gdb.threads/manythreads.exp: stop threads 1
        gdb.threads/manythreads.exp: stop threads 2
          PASS -> FAIL
          FAIL -> PASS
          FAIL -> FAIL

          This is a bug in gdb.  It happens intermittently.

            http://sources.redhat.com/gdb/bugs/1650
            manythreads.exp

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

          Same analysis as gdb 6.1.1 suite HEAD.

      . gdb.threads/schedlock.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
        gdb.threads/thread-specific.exp: Couldn't compile /.../gdb.threads/thread-specific.c: unrecognized error
          blank -> UNSUPPORTED
        gdb.threads/schedlock.exp: *
        gdb.threads/thread-specific.exp
          * -> blank

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . 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 non-gcc-HEAD configurations except for
          the "thread N ran" tests.  Here are the counts per thread.

                   t0  t1  t2  t3  t4  t5
            PASS    0  20  22  22  21  22
            FAIL   22   2   0   0   1   0

  . gdb gdb_6_2-branch

    . suite HEAD

      . gdb.arch/i386-prologue.exp: *
        gdb.base/logical.exp: *
        gdb.base/radix.exp: *
        gdb.base/restore.exp: *
        gdb.base/selftest.exp: *
        gdb.base/signals.exp: *
        gdb.cp/inherit.exp: *
        gdb.gdb/selftest.exp: *
        gdb.threads/watchthreads.exp: *
          * -> *

          Same analyses as gdb 6.1.1 suite HEAD.

      . gdb.cp/classes.exp: ptype obj_with_enum
        gdb.cp/derivation.exp: ptype a_instance
        gdb.cp/inherit.exp: print g_vB
        gdb.cp/inherit.exp: print g_vC
        gdb.cp/inherit.exp: print g_vE
        gdb.cp/local.exp: ptype InnerLocal
        gdb.cp/overload.exp: ptype foo_instance1
        gdb.cp/templates.exp: ptype T5<int>
        gdb.cp/templates.exp: ptype T5i
          FAIL -> PASS
          PASS -> PASS

          Same analysis as gdb 6.1.1 suite HEAD.

      . gdb.cp/pr-1210.exp: print *obj
        gdb.cp/pr-1210.exp: print obj->myB
          PASS -> FAIL

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . gdb.threads/manythreads.exp: GDB exits after stopping multithreaded program
        gdb.threads/manythreads.exp: stop threads 1
        gdb.threads/manythreads.exp: stop threads 2
          PASS -> FAIL
          FAIL -> PASS
          FAIL -> FAIL

          Same analysis as gdb gdb_6_2-branch suite gdb_6_2-branch.

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

          Same analysis as gdb 6.1.1 suite HEAD.

      . gdb.threads/schedlock.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
        gdb.threads/thread-specific.exp: Couldn't compile /.../gdb.threads/thread-specific.c: unrecognized error
        gdb.threads/watchthreads.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
          blank -> UNSUPPORTED
        gdb.threads/schedlock.exp: *
        gdb.threads/thread-specific.exp
          * -> blank

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . 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 non-gcc-HEAD configurations except for
          the "thread N ran" tests.  Here are the counts per thread.

                   t0  t1  t2  t3  t4  t5
            PASS    3  10  10   9   7  10
            FAIL    7   0   0   1   3   0

      . gdb.threads/watchthreads.exp: *
          blank -> PASS
          blank -> FAIL

          Same analysis as gdb 6.1.1 suite HEAD.

  . gdb HEAD

    . suite HEAD

      . gdb.arch/i386-prologue.exp: *
        gdb.base/logical.exp: *
        gdb.base/radix.exp: *
        gdb.base/restore.exp: *
        gdb.base/selftest.exp: *
        gdb.base/signals.exp: *
        gdb.cp/inherit.exp: *
        gdb.gdb/selftest.exp: *
        gdb.threads/watchthreads.exp: *
          * -> *

          Same analyses as gdb 6.1.1 suite HEAD.

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

          Same analysis as gdb 6.1.1 suite HEAD.

      . gdb.cp/classes.exp: ptype obj_with_enum
        gdb.cp/derivation.exp: ptype a_instance
        gdb.cp/inherit.exp: print g_vB
        gdb.cp/inherit.exp: print g_vC
        gdb.cp/inherit.exp: print g_vE
        gdb.cp/local.exp: ptype InnerLocal
        gdb.cp/overload.exp: ptype foo_instance1
        gdb.cp/templates.exp: ptype T5<int>
        gdb.cp/templates.exp: ptype T5i
          FAIL -> PASS
          PASS -> PASS

          Same analysis as gdb 6.1.1 suite HEAD.

      . gdb.cp/pr-1210.exp: print *obj
        gdb.cp/pr-1210.exp: print obj->myB
          PASS -> FAIL

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . gdb.threads/manythreads.exp: GDB exits after stopping multithreaded program
        gdb.threads/manythreads.exp: stop threads 1
        gdb.threads/manythreads.exp: stop threads 2
          PASS -> FAIL
          FAIL -> PASS
          FAIL -> FAIL

          Same analysis as gdb gdb_6_2-branch suite gdb_6_2-branch.

      . gdb.threads/pthreads.exp: apply backtrace command to all three threads
          FAIL -> PASS

          A bug was fixed in gdb HEAD.

            http://sources.redhat.com/gdb/bugs/1505
            [regression] gdb prints a bad backtrace for a thread

          gdb properly terminates the backtrace now.

      . gdb.threads/schedlock.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
        gdb.threads/thread-specific.exp: Couldn't compile /.../gdb.threads/thread-specific.c: unrecognized error
        gdb.threads/watchthreads.exp: Couldn't compile /.../gdb.threads/schedlock.c: unrecognized error
          blank -> UNSUPPORTED
        gdb.threads/schedlock.exp: *
        gdb.threads/thread-specific.exp
          * -> blank

          Same analysis as gdb 6.1.1 suite 6.1.1.

      . 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 non-gcc-HEAD configurations except for
          the "thread N ran" tests.  Here are the counts per thread.

                   t0  t1  t2  t3  t4  t5
            PASS    1  21  22  22  22  22
            FAIL   21   1   0   0   0   0

      . gdb.threads/watchthreads.exp: *
          blank -> PASS
          blank -> FAIL

          Same analysis as gdb 6.1.1 suite HEAD.

  . gdb drow_intercu-20040221-branch

      The last change on this branch was 2004-04-19.

    . suite drow_intercu-20040221-branch

      I examined the tables and found nothing noteworthy.

    . suite HEAD

      I examined the tables and found nothing noteworthy.

. Package Versions

  . This Spin

    binutils  HEAD                          2004-07-31 12:53:06 UTC
    gcc       HEAD                          2004-07-31 13:04:19 UTC
    gcc       gcc-3_4-branch                2004-07-31 13:18:10 UTC
    gcc       gcc-3_3-branch                2004-07-31 13:31:33 UTC
    gdb       HEAD                          2004-08-01 09:36:53 UTC
    gdb       drow_intercu-20040221-branch  2004-08-01 09:49:56 UTC
    gdb       gdb_6_2-branch                2004-08-01 09:56:19 UTC

  . Last Spin

    binutils  HEAD                          2004-07-14 08:03:49 UTC
    gcc       HEAD                          2004-07-14 08:18:08 UTC
    gcc       gcc-3_4-branch                2004-07-14 08:37:13 UTC
    gcc       gcc-3_3-branch                2004-07-14 08:53:05 UTC
    gdb       HEAD                          2004-07-15 01:39:42 UTC
    gdb       drow_intercu-20040221-branch  2004-07-15 01:53:29 UTC
    gdb       gdb_6_2-branch                2004-07-15 02:00:17 UTC

. Test Matrix

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  dejagnu    => dejagnu 1.4.4
  expect     => expect 5.41
  tcl        => tcl 8.4.6
  gdb        => 6.1.1, gdb_6_2-branch, HEAD, drow_intercu-20040221-branch
  suite      => 6.1.1, gdb_6_2-branch, HEAD, drow_intercu-20040221-branch
  cc         => gcc 2.95.3, gcc 3.2-7-rh, gcc 3.3.4, gcc gcc-3_3-branch, gcc 3.4.1, gcc gcc-3_4-branch, gcc HEAD
  as         => binutils 2.13.90.0.2-rh, binutils 2.15, binutils HEAD
  ld         => binutils 2.13.90.0.2-rh, binutils 2.15, binutils HEAD
  libc       => glibc 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2
  count      => 126

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

  The vendor as/ld are tested only with vendor gcc.

  I test gdb gdb 6.1.1 suite 6.1.1, gdb_6_2-branch suite gdb_6-2-branch,
  and gdb HEAD suite HEAD with the full spectrum of as and ld.  I test
  other gdb/suite configurations only with as binutils 2.15 + ld
  binutils 2.15.

. Host Software

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

    make 3.79.1
    binutils 2.15
    gcc 3.3.4
    flex 2.5.4
    bison 1.875
    texinfo 4.7
    tcl 8.4.6
    expect 5.41
    dejagnu 1.4.4

  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 upgraded some host packages: binutils from 2.14 to 2.15, gcc from
  3.3.3 to 3.3.4, and texinfo from the vendor-supplied version to 4.7.
  These are the packages that I build gdb with, not the packages that I
  test gdb with.  This upgrade did not affect any test results.


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