This is the mail archive of the gcc-testresults@gcc.gnu.org mailing list for the GCC 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-08-02


. Highlights of this report

  gdb gdb_6_0-branch still suffers from 'backtrace through sleep'
  and other backtrace bugs.  Except for that, all the test suite results
  are at least as healthy as gdb 5.3.

  gcc gcc-3_3-branch continues to have healthy debug information:
  no changes since last report, no regressions from gcc 3.3.
  But I cover only native i686-pc-linux-gnu with dwarf-2 and stabs+.
  I am looking forward happily to gcc 3.3.1!

  There is a long-standing problem (not a regression) with line number
  information for very tiny functions.  I filed PR gcc/1313 about it.
  It is low priority, but when we get some cycles, it will help cure the
  regressions with gcc HEAD.  At this point I cannot even say if gdb or
  gcc needs to change.

  The new tests gdb.base/annota3.exp and gdb.c++/annota3.exp had some
  FAIL results, but nothing that indicates a new bug in gdb.

Michael C

. Old Bugs Fixed

  None.

. New Bugs Detected

  None.

. PR Count

  Query executed 2003-08-03T18:24:49Z
  1309 matches found
    19 analyzed
   584 closed
    21 feedback
   671 open
     3 paperwork
    11 suspended
  1309 TOTAL

. Libiberty Testing

  . target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
      binutils binutils-2_14-branch                      649 tests, 0 failures
      binutils HEAD                                      714 tests, 31 failures
      gcc 2.95.3, binutils binutils-2_14-branch          All 616 tests passed
      gcc 2.95.3, binutils HEAD                          All 616 tests passed
      gcc 3.3, binutils binutils-2_14-branch             649 tests, 0 failures
      gcc 3.3, binutils HEAD                             649 tests, 0 failures
      gcc gcc-3_3-branch, binutils 2.14                  649 tests, 0 failures
      gcc gcc-3_3-branch, binutils binutils-2_14-branch  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                            714 tests, 31 failures
      gcc HEAD, binutils binutils-2_14-branch            714 tests, 31 failures
      gcc HEAD, binutils HEAD                            714 tests, 31 failures
      gcc HEAD, binutils vendor                          714 tests, 31 failures
      gdb carlton_dictionary-branch                      714 tests, 31 failures
      gdb gdb_6_0-branch                                 649 tests, 0 failures
      gdb HEAD                                           714 tests, 31 failures

    These are long-standing demangler bugs.

      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 is available at

      http://gcc.gnu.org/ml/gcc/2003-07/msg00032.html

. Gdb Testing

  My tables are at

    http://www.shout.net/~mec/sunday/2003-08-02/index.html

  The previous tables are at

    http://www.shout.net/~mec/sunday/2003-07-28/index.html

  . Non-PASS Results

    gdb 5.3             347 non-PASS results
    gdb gdb_6_0-branch  305 non-PASS results
    gdb HEAD            339 non-PASS results

  . 5.3

    . gdb.c++/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.threads/killed.exp: GDB exits after multi-threaded program exits messily

        http://sources.redhat.com/gdb/bugs/568
        GDB confused by messily-exiting multi-threaded programs

        Jim B 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 J has an obvious fix, which has been applied to gdb HEAD:

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

  . gdb_6_0-branch

    checkout date is '2003-08-03 05:24:07 UTC'
    previous date is '2003-07-28 19:01:19 UTC'

    . gdb.base/annota3.exp: send SIGUSR1 (pattern 6)
      gdb.base/annota3.exp: backtrace @ signal handler (pattern 1)
        blank -> FAIL
    . gdb.base/annota3.exp: *
        blank -> PASS

        Andrew C wrote a new test script.

        The tests 'send SIGUSR1' and 'backtrace @ signal handler' FAILed
        with gcc HEAD, both -gdwarf-2 and -gstabs+.  These tests PASSed
        with all other versions of gcc.  These are manifestations of PR
        gdb/1313.

          http://sources.redhat.com/gdb/bugs/1313
          bad line numbers on very tiny functions

        The bug is related to the line number table for the signal
        handler, which is an empty function.  It is not related to
        signals or to annotations.  The bug also happens with gdb 5.3 so
        it is not a regression from 5.3.

    . gdb.c++/annota3.exp: annotate-quit (pattern 1)
        blank -> FAIL
      gdb.c++/annota3.exp: watch triggered on a.x
        blank -> KFAIL
      gdb.c++/annota3.exp: *
        blank -> PASS

        Andrew C wrote a new test script.

        I did not investigate these in detail.  Judging from the name
        of the test, 'annotate-quit' is probably a manifestation of
        PR gdb/544.
        
          http://sources.redhat.com/gdb/bugs/544
          gdb.c++/annota2.exp: annotate-quit test sometimes fails

        The KFAIL with 'watch triggered on a.x' is probably a
        manifestation of PR gdb/38.

          http://sources.redhat/com/gdb/bugs/38
          Watchpoint does not trigger when first set

    . 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
        blank -> PASS
        PASS -> blank

        Fluctuation with unknown cause.  Probably harmless.

    . gdb.threads/linux-dp.exp: philosopher is distinct: 6
      gdb.threads/linux-dp.exp: philosopher is distinct: 7
        FAIL -> PASS

        These tests are sensitive to a backtrace bug in gdb.  If a
        thread is waiting on 'select', then gdb prints a deficient
        backtrace, and the test FAILs.

          http://sources.redhat.com/gdb/bugs/1255
          [regression] bad backtrace for libc function 'sleep'

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

        Fluctuation with unknown cause.  Probably harmless.

    . gdb.threads/pthreads.exp: check backtrace from thread 2
        PASS -> FAIL

        A multi-threaded inferior program tickles a known bug in
        backtracing.  The bug is deterministic, but the times when it
        happens is not.

          pr gdb/1255: [regression] bad backtrace for libc function 'sleep'
          http://sources.redhat.com/gdb/bugs/1255

    . 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     6    28
          thread 1    25     9
          thread 2    32     2
          thread 3    33     1
          thread 4    32     2
          thread 5    34     0

  . gdb HEAD

    checkout date is '2003-08-03 05:21:09 UTC'
    previous date is '2003-07-28 18:58:27 UTC'

    . gdb.base/annota3.exp: annotate ignore count change (pattern 5)
        blank -> FAIL
      gdb.base/annota3.exp: send SIGUSR1 (pattern 6)
      gdb.base/annota3.exp: backtrace @ signal handler (pattern 1)
        blank -> FAIL
      gdb.base/annota3.exp: *
        blank -> PASS

        Andrew C wrote a new test script.

        The 'annotate ignore count change' test FAILed in 3
        configurations out of 34 tested.  I re-ran the test script, and
        this test FAILed in 3 configurations out of 34 tested -- but the
        set of FAILed configurations was different!

        The gdb.log transcript is byte-for-byte identical for the
        pertinent section, comparing one of the FAILed runs and one of
        the PASSed runs.

        Also, gdb.base/annota3.exp and gdb.base/annota3.c are identical
        in gdb gdb_6_0-branch and gdb HEAD, but this FAIL happened only
        in gdb HEAD.

        gdb is okay, and the test script is probably okay, but it looks
        like this test is tickling a tcl/expect/dejagnu bug.

        The 'send SIGUSR1' and 'backtrace @ signal handler' results have
        the same analysis as gdb gdb_6_0-branch.

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

        Same analysis as gdb 5.3.

    . gdb.c++/annota3.exp: annotate-quit (pattern 1)
        blank -> FAIL
      gdb.c++/annota3.exp: watch triggered on a.x
        blank -> KFAIL
      gdb.c++/annota3.exp: *
        blank -> PASS

        Same analysis as gdb gdb_6_0-branch.

    . gdb.threads/linux-dp.exp: philosopher is distinct: 3
      gdb.threads/linux-dp.exp: philosopher is distinct: 6
      gdb.threads/linux-dp.exp: philosopher is distinct: 7
        PASS -> FAIL

        Same analysis as gdb gdb_6_0-branch.

    . 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
        blank -> PASS
        PASS -> blank

        Same analysis as gdb gdb_6_0-branch.

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

        Same analysis as gdb 5.3.

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

        Same analysis as gdb gdb_6_0-branch.

    . 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    31
          thread 1    29     5
          thread 2    32     2
          thread 3    33     1
          thread 4    32     2
          thread 5    34     0

    . gdb.threads/tls.exp: *
        PASS
        FAIL
        KFAIL
        UNSUPPORTED

        Michael C made some incremental improvements to the test script
        for native red hat linux 8, which does not support thread local
        storage.  Now there are no more ERROR results.

. Test Matrix

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  gdb        => 5.3, gdb_6_0-branch, HEAD
  gcc        => 2.95.3, 3.2-7-rh, 3.3, gcc-3_3-branch, HEAD
  binutils   => 2.13.90.0.2-rh, 2.14, binutils-2_14-branch, HEAD
  glibc      => 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2
  count         102 = 1 * 1 * 1 * 3 * (4*4+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*4+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
    flex 2.5.4
    bison 1.875
    tcl 8.4.3
    expect 5.38.0
    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 Build and Test), and they are licensed under the
  GPL.

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

. Test Bed Changes Since Last Report

  I changed the location of the directory where I run the gdb tests.
  A few weeks ago I changed the name to have a $UUID in it
  (unique universal identifier), so that I could locate it in /tmp.
  The $UUID turned out to cause some noise in the result tables so I
  reverted to name with no $UUID in it, which means it can't live in
  /tmp anymore (the /tmp/...-$UIID option is still there, but it's
  disabled).


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