This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
sunday project, gdb, 2003-09-11
- 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: Fri, 12 Sep 2003 16:01:19 -0400
- Subject: sunday project, gdb, 2003-09-11
. Dedication
The 2003-09-11 report is dedicated to FDNY.
Wanna help out? Give blood. Anywhere in the world helps.
. Highlights of this report
gcc 5.3.91 and gcc gcc_6_0-branch are healthy.
gcc HEAD enabled function-at-a-time with -O2. Unfortunately, gdb has
very little coverage of -O2, so I have little test coverage for this.
I did find one gcc bug already with gdb.base/break.exp.
There is a mystery FAIL in gdb.cp/m-data.exp with gcc HEAD.
It feels like a disconnect between gcc HEAD and binutils 2.14.
Binutils HEAD works fine.
Michael C
. Old Bugs Fixed
. gcc HEAD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12204
[regression] gcc emits bogus .file when __inline__ called
Someone fixed this bug in gcc HEAD.
I don't know exactly what patch did the job.
. gdb gdb_6_0-branch
Someone, either Andrew C or Daniel J, fixed two bugs which
affected store.exp.
. New Bugs Detected
. gcc HEAD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12267
[3.4 regression] function-at-a-time generates stabs in bad order
gcc HEAD flipped the switch and does function-at-a-time
whenever -O2 is specified. This generates bad stabs for
"factorial" in the middle of the epilog of "main" in
gdb.base/break.exp.
. PR Count
Query executed 2003-09-12 19:53:30 UTC
1374 matches found
22 analyzed
615 closed
27 feedback
696 open
3 paperwork
11 suspended
1374 TOTAL
. Libiberty Testing
. target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
binutils HEAD 714 tests, 31 failures
gcc 2.95.3, binutils HEAD All 616 tests passed
gcc 3.3.1, 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 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-09-11/index.html
The previous tables are at
http://www.shout.net/~mec/sunday/2003-09-05/index.html
. Non-PASS Results
gdb 5.3 410 non-PASS results
gdb 5.3.91 406 non-PASS results
gdb gdb_6_0-branch 403 non-PASS results
gdb HEAD 436 non-PASS results
. 5.3
. gdb.base/break.exp: run until function breakpoint, optimized file
PASS -> FAIL
This is a regression with "gcc HEAD -gstabs+ -g2 -O2".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12267
[3.4 regression] function-at-a-time generates stabs in bad order
gcc HEAD flipped the switch and does function-at-a-time
whenever -O2 is specified. This generates bad stabs for
"factorial" in the middle of the epilog of "main" in
gdb.base/break.exp.
. 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 5.3.91
. gdb.base/break.exp: run until function breakpoint, optimized file
PASS -> FAIL
Same analysis as gdb 5.3.
. gdb.base/fileio.exp: *
FAIL -> PASS
Someone fixed a bug in gcc HEAD.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12204
[regression] gcc emits bogus .file when __inline__ called
. gdb.cp/annota3.exp: annotate-quit
Same analysis as gdb 5.3.
. gdb.cp/m-data.exp: continue to breakpoint: continue to shadow breakpoint
PASS -> FAIL
This test regressed with gcc HEAD -gstabs+ with binutils 2.14
and binutils 2.13.90.0.2-rh. This test continued to work fine
with gcc HEAD -gstabs+ with binutils HEAD.
Here are gdb.log excerpts:
# gcc HEAD, binutils 2.14, -gstabs+
(gdb) PASS: gdb.cp/m-data.exp: template object, derived enum
break C::marker^M
Breakpoint 3 at 0x8049b1d^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 3, 0x08049b1d in C::marker() (this=0xbffff78c)^M
(gdb) FAIL: gdb.cp/m-data.exp: continue to breakpoint: continue to shadow breakpoint
# gcc HEAD, binutils HEAD, -gstabs+
(gdb) PASS: gdb.cp/m-data.exp: template object, derived enum
break C::marker^M
Breakpoint 3 at 0x8049a9d: file /berman/migchain/source/gdb-5.3.91/gdb/testsuite
/gdb.cp/m-data.cc, line 49.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 3, 0x08049a9d in C::marker() (this=0xbffff78c) at /berman/migchain/source/gdb-5.3.91/gdb/testsuite/gdb.cp/m-data.cc:49^M
49 void marker () {}^M
(gdb) PASS: gdb.cp/m-data.exp: continue to breakpoint: continue to shadow breakpoint
The first configuration FAILed because gdb did not print file
and line number information for the breakpoint at C::marker.
This FAIL could use more attention, but I am out of attention.
. 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.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 4
gdb.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 5
gdb.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 6
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 6
blank -> PASS
PASS -> blank
Fluctuation with unknown cause. Probably harmless.
. gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
blank -> PASS
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
That is interesting! Maybe this is because I exited the
X window system before I ran these tests.
. gdb gdb_6_0-branch
checkout date is '2003-09-11 07:19:23 UTC'
previous date is '2003-09-05 17:37:31 UTC'
. gdb.base/break.exp: run until function breakpoint, optimized file
PASS -> FAIL
This is a regression with "gcc HEAD -gstabs+ -g2 -O2".
Same analysis as gdb 5.3.
. gdb.base/fileio.exp: *
FAIL -> PASS
Same analysis as gdb 5.3.91.
. gdb.base/store.exp: up print new l - int
gdb.base/store.exp: up print new l - long
gdb.base/store.exp: up print old l - int
gdb.base/store.exp: up print old l - long
FAIL -> PASS
This happened with gcc 2.95.3 -gdwarf-2.
Someone, either Andrew C or Daniel J, fixed a bug in gdb.
. gdb.base/store.exp: up print old r - charest
gdb.base/store.exp: up print old r - int
gdb.base/store.exp: up print old r - long
gdb.base/store.exp: up print old r - short
FAIL -> PASS
This happened with gcc 3.x -gdwarf-2.
Someone, either Andrew C or Daniel J, fixed a bug in gdb.
. gdb.cp/annota2.exp: annotate-quit
gdb.cp/annota3.exp: annotate-quit
Same analysis as gdb 5.3.
. gdb.cp/m-data.exp: continue to breakpoint: continue to shadow breakpoint
PASS -> FAIL
Same analysis as gdb 5.3.91.
. gdb.java/jmisc.exp: *
blank -> WARNING
blank -> UNTESTED
PASS -> blank
FAIL -> blank
This happened in just one configuration. It is probably just
a symptom of swapping in my test bed (only 128 megabytes of
memory).
. 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.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 4
gdb.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 5
gdb.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 6
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 3
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 4
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 5
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 6
PASS -> blank
blank -> PASS
Same analysis as gdb 5.3.91.
. gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
Same analysis as gdb 5.3.
. gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
blank -> PASS
Same analysis as gdb 5.3.91.
. 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 4 22
thread 1 21 5
thread 2 25 1
thread 3 25 1
thread 4 24 2
thread 5 26 0
. gdb HEAD
checkout date is '2003-09-11 07:16:02 UTC'
previous date is '2003-09-05 16:56:43 UTC'
. gdb.arch/i386-prologue.exp: saved registers in gdb1253
gdb.arch/i386-prologue.exp: saved registers in gdb1338
blank -> PASS
Mark K wrote some new tests.
. gdb.base/break.exp: run until function breakpoint, optimized file
PASS -> FAIL
Same analysis as gdb 5.3.
. gdb.base/fileio.exp: *
FAIL -> PASS
Same analysis as gdb 5.3.91.
. gdb.base/gdb1250.exp: *
blank -> PASS
ERROR -> blank
WARNING -> blank
UNRESOLVED -> blank
The test program had a function named 'gamma', which is a
reserved identifier now. gcc HEAD is okay; the test program was
wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12213
[3.4 regression] warning: conflicting types for builtin-function 'gamma'
Michael C fixed the test program to work with gcc HEAD.
. gdb.base/gdbvars.exp: Set value-history[1] using $1
UNRESOLVED -> PASS
This was a cascade failure from gdb.base/gdb1250.exp.
. gdb.base/store.exp: up print new l - int
gdb.base/store.exp: up print new l - long
gdb.base/store.exp: up print old l - int
gdb.base/store.exp: up print old l - long
FAIL -> PASS
Same analysis as gdb gdb_6_0-branch.
. gdb.base/store.exp: up print old r - charest
gdb.base/store.exp: up print old r - int
gdb.base/store.exp: up print old r - long
gdb.base/store.exp: up print old r - short
FAIL -> PASS
Same analysis as gdb gdb_6_0-branch.
. gdb.cp/annota2.exp: annotate-quit
gdb.cp/annota3.exp: annotate-quit
Same analysis as gdb 5.3.
. gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42
FAIL -> KFAIL
Michael C improved the test.
. gdb.cp/m-data.exp: continue to breakpoint: continue to shadow breakpoint
PASS -> FAIL
Same analysis as gdb 5.3.91.
. 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 6
gdb.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 4
gdb.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 5
gdb.mi1/mi-pthreads.exp: check mi_thread_command_set: -thread-select 6
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 4
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 5
gdb.mi2/mi-pthreads.exp: check mi_thread_command_set: -thread-select 6
blank -> PASS
PASS -> blank
Same analysis as gdb 5.3.91.
. gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
Same analysis as gdb 5.3.
. 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 22 4
thread 2 25 1
thread 3 24 2
thread 4 22 4
thread 5 26 0
. Test Matrix
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
gdb => 5.3, 5.3.91, gdb_6_0-branch, HEAD
gcc => 2.95.3, 3.2-7-rh, 3.3.1, 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 104 = 1 * 1 * 1 * 4 * (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
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.6.tar.gz
ftp://ftp.shout.net/pub/users/mec/migbat/migbat-0.6.tar.gz
. Test Bed Changes Since Last Report
None.