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

  gcc HEAD changed its default C++ ABI from version 1 to version 2.
  Version 2 is an incremental bug fix from version 1 and has little
  impact on gdb.  The order of methods in 'ptype' is different with
  stabs+, and I have updated the test suite.  I did not find any gcc
  bugs or gdb bugs from the ABI change.

. Old Bugs Fixed

  None.

. New Bugs Detected

  . gdb HEAD 

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

. PR Count

  Query executed 2004-01-10 09:58:24 UTC

  1502 matches found
    22 analyzed
   685 closed
    29 feedback
   749 open
     3 paperwork
    14 suspended
  1502 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 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                            742 tests, 0 failures
      gcc HEAD, binutils HEAD                            742 tests, 0 failures
      gcc HEAD, binutils vendor                          742 tests, 0 failures
      gdb HEAD                                           742 tests, 0 failures
      gdb carlton_dictionary-branch                      726 tests, 0 failures

. Gdb Testing

  My tables are at

    http://www.shout.net/~mec/sunday/2003-01-09/index.html

  The previous tables are at

    http://www.shout.net/~mec/sunday/2003-12-24/index.html

  . Non-PASS Results

    gdb 6.0             358 non-PASS results
    gdb HEAD            410 non-PASS results

  . gdb 6.0

    . gdb.cp/annota2.exp: annotate-quit
        PASS -> KFAIL
      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.cp/classes.exp: ptype class *
      gdb.cp/derivation.exp: ptype *
      gdb.cp/local.exp: ptype *
      gdb.cp/method.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
      gdb.cp/local.exp: Local out of scope
        KFAIL -> FAIL

        These regressions happened with gcc HEAD -gstabs+.  gcc changed
        its default ABI version from 1 to 2.  This affects the order of
        fields in the ptype command: With ABI version 1, synthetic
        methods come before user methods; with ABI version 2, synthetic
        methods come after user methods.

        I updated the test scripts in gdb HEAD.  I did not see any
        evidence of gcc bugs or gdb bugs from the ABI change.

    . 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 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     2    24
          thread 1    23     3
          thread 2    25     1
          thread 3    25     1
          thread 4    26     0
          thread 5    26     0

  . gdb HEAD

    checkout date is '2004-01-09 22:05:53 UTC'
    previous date is '2003-12-24 07:13:44 UTC'

    . gdb.base/gdb1476.exp: Memory at address 0 is possibly executable
        blank -> UNTESTED
        blank -> UNRESOLVED

      Mark K wrote a new test script.

      The UNRESOLVED results happened with binutils HEAD; this is a
      cascade problem from the previous script, gdb1250.exp.

      The UNTESTED results are a deficiency in the test script.
      gdb prints "Cannot access memory at address 0x0", but the script
      expects "Error accessing memory address 0x0".  This happened with
      all versions of gcc, binutils, and debug formats.

      I filed a PR on the test script:

        http://sources.redhat.com/gdb/bugs/1504
        gdb1476.exp needs to recognize "Cannot access memory ..."

    . gdb.base/gdbvars.exp: Set value-history[1] using $1
        UNRESOLVED -> PASS

        This happened with binutils HEAD.  It's an artifact of a cascade
        problem with gdb1250.exp on binutils HEAD.  The new test script
        gdb1476.exp is catching the cascade problem now.  gdb is fine.

    . gdb.base/structs.exp: zed L<n> for return; return *
        PASS -> blank
        blank -> PASS

        Mark K improved the test names.

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

        Same analysis as gdb 6.0.

    . gdb.cp/bs15503.exp: *
    . gdb.cp/ctti.exp: *
        blank -> PASS

        Michael C refurbished two old hp test scripts and enabled them
        on all platforms.  All tests PASSed in all configurations.

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

        gdb prints a bad backtrace for a thread.
        This happened in all configurations tested.

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

    . 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    21
          thread 1    23     3
          thread 2    23     3
          thread 3    23     3
          thread 4    24     2
          thread 5    26     0

. Test Matrix

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  gdb        => 6.0, HEAD
  gcc        => 2.95.3, 3.2-7-rh, 3.3.2, gcc-3_3-branch, HEAD
  as         => 2.13.90.0.2-rh, 2.14, HEAD
  ld         => 2.13.90.0.2-rh, 2.14, HEAD
  glibc      => 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2
  count         52 = 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', 'as', 'ld', 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.
  as/ld are always matched.
  The vendor gcc is available only with vendor as/ld.
  The vendor gcc is available only with vendor binutils,
    thus the '(4*3+1*1)' term for gcc/as/ld 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.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

  No externally-visible changes.


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