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]

sunday project, gdb, 2003-11-21


. Highlights of This Spin

  Ian L-T and Mark M fixed some bugs in the C++ demangler.

  The new i386-unwind.exp script revealed a problem with mixed
  C and assembly and dwarf-2.

  Andrew C wrote a greatly expanded structs.exp which KFAIL's some
  existing bugs in gdb.  The new structs.exp even crashes gdb on
  an ia64 target (which I don't cover).  Good testing!

  The current tables are always at:
    http://www.shout.net/~mec/sunday/current/index.html

Michael C

. Old Bugs Fixed

  . libiberty

    Ian L-T and Mark M fixed 13 failures in the C++ demangler test
    and introduced 0 new failures.

. New Bugs Detected

  None.

. PR Count

  Query executed 2003-11-23 05:39:57 UTC

  1462 matches found
    22 analyzed
   656 closed
    21 feedback
   750 open
     3 paperwork
    10 suspended
  1462 TOTAL

. Libiberty Testing

  . target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
      binutils HEAD                                      715 tests, 18 failures
      gcc 2.95.3, binutils HEAD                          All 616 tests passed
      gcc 3.3.2, binutils HEAD                           649 tests, 0 failures
      gcc gcc-3_3-branch, binutils 2.14                  649 tests, 0 failures
      gcc gcc-3_3-branch, binutils HEAD                  649 tests, 0 failures
      gcc gcc-3_3-branch, binutils vendor                649 tests, 0 failures
      gcc HEAD, binutils 2.14                            715 tests, 18 failures
      gcc HEAD, binutils HEAD                            715 tests, 18 failures
      gcc HEAD, binutils vendor                          715 tests, 18 failures
      gdb HEAD                                           715 tests, 18 failures
      gdb carlton_dictionary-branch                      715 tests, 31 failures
      gdb gdb_6_0-branch                                 649 tests, 0 failures

    These are long-standing demangler bugs.  Since the last spin,
    Ian L-T and Mark M fixed 13 old failures and introduced 0 new
    failures.  The new libiberty has propagated to most trees.

      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7986
      Problems with demangling (__cxa_demangle())

      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11028
      The standalone C++ demangler doesn't work on some symbols

    A libiberty log with 18 failures is at

      http://www.shout.net/~mec/sunday/libiberty/2003-11-21.log

    An older libiberty log with 31 failures is at

      http://www.shout.net/~mec/sunday/libiberty/2003-06-30.log

. Gdb Testing

  My tables are at

    http://www.shout.net/~mec/sunday/2003-11-21/index.html

  The previous tables are at

    http://www.shout.net/~mec/sunday/2003-11-15/index.html

  . Non-PASS Results

    gdb 6.0             311 non-PASS results
    gdb gdb_6_0-branch  313 non-PASS results
    gdb HEAD            407 non-PASS results

  . gdb 6.0

    . gdb.cp/annota2.exp: annotate-quit

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

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

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

        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 thread_function breakpoint, 5 (slow with kill breakpoint)
        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     0    26
          thread 1    26     0
          thread 2    26     0
          thread 3    26     0
          thread 4    26     0
          thread 5    26     0

  . gdb gdb_6_0-branch

    checkout date is '2003-11-21 06:27:24 UTC'
    previous date is '2003-11-15 04:48:42 UTC'

    . gdb.cp/annota2.exp: annotate-quit

        Same analysis as gdb 6.0.

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

        Same analysis as gdb 6.0.

    . gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
        blank -> 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     2    24
          thread 1    25     1
          thread 2    26     0
          thread 3    26     0
          thread 4    25     1
          thread 5    26     0

  . gdb HEAD

    checkout date is '2003-11-21 06:25:07 UTC'
    previous date is '2003-11-15 04:45:41 UTC'

    . gdb.arch/i386-unwind.exp: running to main in runto
        blank -> PASS
        blank -> FAIL
      gdb.arch/i386-unwind.exp: continue past gdb1435
      gdb.arch/i386-unwind.exp: backtrace past gdb1435
        blank -> PASS

        Mark K wrote a new test script for a backtrace bug.  The actual
        backtrace test PASSed in all configurations, but the script
        revealed an unrelated bug with 'break' in mixed C/assembly
        programs.

          http://sources.redhat.com/gdb/bugs/1462
          breakpoint bad address, mixed c/asm, gcc dwarf-2

        The test 'running to main in runto' FAILed in all dwarf-2
        configurations.  I don't know if this is a bug in the test
        script, a bug in gcc, or a bug in gdb.

        I also saw this bug with gdb 6.0 and gdb 5.3 so this is not a
        regression in gdb.

    . gdb.base/maint.exp: internal-error resync
        blank -> PASS

        Andrew C added a test.  The new test PASSed in all configurations.

    . gdb.base/structs.exp: *
        blank -> PASS
        blank -> KPASS
        blank -> KFAIL
        PASS -> blank

        Andrew C rewrote structs.exp with about 500 more tests covering
        many more varieties of struct argument and struct return.  Very
        nice!

        All of the new results were PASS, KPASS, or KFAIL on native
        i686-pc-linux-gnu.  There were 46 tests with KPASS or KFAIL in
        at least one configuration tested.

        I also ran the new version of structs.exp with gdb 6.0.  About
        60 of the new tests improved from gdb 6.0 to gdb HEAD.  No tests
        regressed from gdb 6.0 to gdb HEAD.

        structs.exp behaves differently when I run it alone
        (RUNTESTFLAGS=structs.exp) as opposed to running the whole test
        suite.  This happens with gcc 3.3.2 and gcc gcc-3_3-branch,
        with dwarf-2.  I filed a PR.

          http://sources.redhat.com/gdb/bugs/1463
          structs.exp gives different results when run standalone

        This is a trivial bug in the test script.  I have a patch in
        the works.

    . gdb.threads/print-threads.exp: Hit kill breakpoint, 10 (slow with kill breakpoint)
        blank -> 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     2    24
          thread 1    24     2
          thread 2    26     0
          thread 3    26     0
          thread 4    25     1
          thread 5    26     0

. Test Matrix

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  gdb        => 6.0, gdb_6_0-branch, HEAD
  gcc        => 2.95.3, 3.2-7-rh, 3.3.2, gcc-3_3-branch, HEAD
  binutils   => 2.13.90.0.2-rh, 2.14, HEAD
  glibc      => 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2
  count         78 = 1 * 1 * 1 * 3 * (4*3+1*1) * 1 * 2 * 1

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

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

  'gdb', 'gcc', 'binutils', and 'glibc' are version 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.
  The vendor gcc is available only with vendor binutils,
    thus the '(4*3+1*1)' term for gcc/binutils combinations.

. 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.4
    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.7.tar.gz
    ftp://ftp.shout.net/pub/users/mec/migbat/migbat-0.7.tar.gz

. Test Bed Changes Since Last Report

  None.


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