sunday project, gdb, 2002-12-31

[Michael Elizabeth Chastain <mec at shout dot net>]

Another week with no regressions in the gdb test results,
not from gdb bugs, gcc bugs, or any other causes.

Highlights of this report:

. I dropped gdb_5_3-branch.  This branch has been inactive since the
  release of gdb 5.3.

. gdb.mi/mi-pthreads.exp: check_mi_thread_command_set: -thread-select [3456]
  are still flaky in gdb HEAD.  Keith S and Elena Z fixed a similar problem
  recently so I will ask if this rings any bells with them.

My tables are here:

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

Happy New Year.  Remember to add '2003' to the copyright line on all
the files that you commit which have copyright lines!

Michael C

. Summary

  . Test Matrix

    . Matrix

      target      => native
      host        => i686-pc-linux-gnu
      osversion   => red-hat-8.0
      gdb         => 5.3, HEAD%20021231
      gcc         => 2.95.3, 3.2-7-rh, 3.2.1, gcc-3_2-branch%20021231, gcc-3_3-branch%20021231, HEAD%20021231
      binutils    => 2.13.90.0.2-rh, 2.13.2, HEAD%20021231
      libc        => 2.2.93-5-rh
      gformat     => dwarf-2, stabs+
      count          64 = 1 * 1 * 1 * 2 * (5*3+1*1) * 1 * 2

    . Notes

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

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

      'gdb', 'gcc', 'binutils', and 'libc' are version names.
      versions start with a number are official releases or snapshots.
      versions which start with a number and end with '-rh' are the
        vendor-supplied versions on my red hat linux host.
      versions named 'HEAD' are the cvs HEAD.
      versions with any other name are cvs branches.
      cvs versions show the checkout date after a '%' delimiter.

      'gformat' is the debugging information format.

      'count' is the total number of configurations tested.
      The vendor gcc is available only with vendor binutils,
        thus the '(5*3+1*1)' term for gcc/binutils combinations.

    . libiberty

      Not tested yet (I need to update my test script).

    . gdb

      . Tables

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

      . Overview

        gdb 5.3:   0 build aborts, 0 test aborts, 378 non-PASS results
        gdb HEAD:  0 build aborts, 0 test aborts, 395 non-PASS results

        A non-PASS result is any result except PASS.  This includes
        ERROR, WARNING, NOTE, FAIL, KPASS, KFAIL, XPASS, XFAIL, UNRESOLVED,
        UNTESTED, UNSUPPORTED, and unknown results.

      . Old bugs fixed

	None.

      . New bugs detected

	None.

. Test bed changes since last report

  I upgraded from binutils 2.13.1 to binutils 2.13.2 with no problems.
  I tweaked the table generator this week to match up these versions of
  binutils in the comparison tables.

  I dropped binutils binutils-2_13-branch.  Daniel Jacobowitz, the
  release manager for binutils, said that he does not anticipate another
  release from this branch.  This enables me to shrink the enormous
  matrix.

    http://sources.redhat.com/ml/binutils/2002-12/msg00778.html

  I dropped gdb gdb_5_3-branch.  There has been no activity on the branch
  since the release of gdb 5.3.  I will revive coverage if I see activity.
  (Personally, I would rather have no activity on the old branch and
  lots of activity in gdb HEAD).

. Baseline software

  . host i686-pc-linux-gnu

    . osversion red-hat-8.0

      make 3.79.1
      binutils 2.13.1
      gcc 3.2.1
      flex 2.5.4
      bison 1.35
      tcl 8.4.1
      expect 5.38.0
      dejagnu 1.4.3

      The baseline software is used to build and test all the other software.
      It is not part of the test matrix.

      Note that the baseline software includes binutils 2.13.1, not
      binutils 2.13.2.  When I test gdb I build all the test programs
      with several binutils, including 2.13.2 but not 2.13.1.  I'm planning
      to upgrade the baseline to binutils 2.13.2 as soon as I can do
      a comparison spin.

. Analysis

  . libiberty

    . results

      . target native

        . host i686-pc-linux-gnu

	  . osversion red-hat-8.0

	    No results available yet.

  . gdb

    The previous report was 2002-12-24:

      http://www.shout.net/~mec/sunday/2002-12-24/Analysis.txt

    . 5.3

      . 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
          Fluctuation in test result from unknown cause.

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

	  pr gdb/568: GDB confused by messily-exiting multi-threaded programs
	  http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=568

	  Jim Blandy thinks that this test may depend on a race condition:

	    http://sources.redhat.com/ml/gdb-testers/2002-q4/msg00010.html

      . gdb.threads/schedlock.exp: *

          This test script is useless in this release because of a
          signed-versus-unsigned bug.

	  Daniel Jacobowitz has an obvious fix, which has been applied
	  to gdb HEAD:

	    http://sources.redhat.com/ml/gdb-patches/2002-10/msg00454.html

    . HEAD

      . gdb.c++/annota2.exp: annotate quit
        gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily

	  Same analysis as gdb 5.3.

      . gdb.mi/mi-pthreads.exp: check_mi_thread_command_set: -thread-select 3
        gdb.mi/mi-pthreads.exp: check_mi_thread_command_set: -thread-select 4
        gdb.mi/mi-pthreads.exp: check_mi_thread_command_set: -thread-select 5
        gdb.mi/mi-pthreads.exp: check_mi_thread_command_set: -thread-select 6
        gdb.mi/mi1-pthreads.exp: check_mi_thread_command_set: -thread-select 4
        gdb.mi/mi1-pthreads.exp: check_mi_thread_command_set: -thread-select 5
        gdb.mi/mi1-pthreads.exp: check_mi_thread_command_set: -thread-select 6
	  FAIL -> null
	  null -> FAIL

	  I see bad changes and good changes from the previous run.
	  It doesn't feel any flakier than the previous run.  These
	  results need more investigation.

      . gdb.threads/schedlock.exp: *

	  I see bad changes.  I see good changes.  This test is still
	  in a state where it's better to analyze the absolute results
	  than to compare results from date to date.