This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
sunday project, gdb, 2003-08-02
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gcc-testresults at gcc dot gnu dot org, gdb-testers at sources dot redhat dot com
- Date: Mon, 4 Aug 2003 19:30:33 -0400
- Subject: 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).