This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
gdb, native i686-pc-linux-gnu
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: gcc-testresults at gcc dot gnu dot org, gdb-testers at sources dot redhat dot com
- Date: Thu, 29 Jan 2004 18:31:09 -0500 (EST)
- Subject: gdb, native i686-pc-linux-gnu
. Highlights of This Spin
There are no significant differences between the results for gcc 3.3.2
and gcc gcc-3_3-branch 2004-01-27 09:26:38 UTC on native
i686-pc-linux-gnu, dwarf-2 and stabs+. Bring on gcc 3.3.3 any time!
gcc gcc-3_4-branch and gcc HEAD have regressions versus gcc 3.3.2.
These tests had regressive results with gdb HEAD suite HEAD:
gdb.base/break.exp: run until function breakpoint, optimized file
gdb.base/scope.exp: print localval, outer scope
gdb.base/store.exp: print old r - longest
gdb.base/store.exp: up print old r - longest
gdb.cp/anon-union.exp: print *
gdb.cp/classes.exp: print obj_with_enum (2)
gdb.cp/classes.exp: print obj_with_enum.priv_enum
gdb.cp/classes.exp: ptype obj_with_enum
gdb.cp/classes.exp: ptype obj_with_enum.priv_enum
gdb.cp/rtti.exp: print *obj
gdb.java/jmisc1.exp: *
gdb.java/jmisc2.exp: *
gdb.mi/mi-until.exp: until after current function
gdb.mi/mi-var-block.exp: create local variable foo
gdb.mi/mi-var-block.exp: delete var foo
gdb.mi/mi1-until.exp: until after current function
gdb.mi/mi1-var-block.exp: create local variable foo
gdb.mi/mi1-var-block.exp: delete var foo
gdb.mi/mi2-until.exp: until after current function
gdb.mi/mi2-var-block.exp: create local variable foo
gdb.mi/mi2-var-block.exp: delete var foo
I need to analyze these regressions and file more PR's or change the
test suite.
This will be the last report for most configurations with the vendor
version of binutils, binutils 2.13.90.0.2-rh. There haven't been any
significant result differences between binutils 2.13.90.0.2-rh and
binutils 2.14 for a long time, and I need to reduce the spin time.
The current tables are always at
http://www.shout.net/~mec/sunday/current/index.html
. Old Bugs Fixed
None.
. New Bugs Detected
None.
. PR Count
Query executed 2004-01-29 23:15:52 UTC
1536 matches found
23 analyzed
700 closed
28 feedback
769 open
3 paperwork
13 suspended
1536 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 gcc-3_3-branch 649 tests, 0 failures
gcc gcc-3_4-branch 742 tests, 0 failures
gcc HEAD 742 tests, 0 failures
gdb HEAD 742 tests, 0 failures
gdb carlton_dictionary-branch 742 tests, 0 failures
gdb drow-cplus-branch 742 tests, 0 failures
For gcc tests, the test results are with binutils 2.14.
The binutils version should not make a difference.
. Gdb Testing
My tables are at
http://www.shout.net/~mec/sunday/2004-01-28/index.html
The previous tables are at
http://www.shout.net/~mec/sunday/2004-01-23/index.html
. Non-Pass Results
gdb 6.0
suite 6.0 350 non-PASS results
suite HEAD 499 non-PASS results
gdb HEAD
suite HEAD 432 non-PASS results
gdb carlton_dictionary-branch
suite carlton_dictionary-branch 429 non-PASS results
suite HEAD 421 non-PASS results
gdb drow-cplus-branch
suite drow-cplus-branch 652 non-PASS results
suite HEAD 675 non-PASS results
I run each version of gdb with two test suites: the test suite that
comes with that version of gdb and the test suite that comes with
gdb HEAD.
. gdb 6.0
. suite 6.0
. gdb.cp/annota2.exp: annotate-quit
KFAIL -> PASS
. gdb.cp/annota2.exp: annotate-quit
FAIL -> PASS
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.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 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/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 32
thread 1 31 1
thread 2 31 1
thread 3 32 0
thread 4 32 0
thread 5 32 0
. suite HEAD
. gdb.base/freebpcmd.exp: run program with breakpoint commands
KFAIL -> PASS
KFAIL -> KFAIL
This is a non-deterministic memory corruption bug in gdb 6.0.
It has been fixed in gdb HEAD.
http://sources.redhat.com/gdb/bugs/1489
GDB crashes executing breakpoint commands that continue the inferior
. gdb.cp/annota2.exp: annotate-quit
KFAIL -> PASS
gdb.cp/annota3.exp: annotate-quit
FAIL -> PASS
Same analysis as gdb 6.0 suite 6.0.
. gdb.cp/local.exp: ptype l
blank -> PASS
blank -> KFAIL
gdb.cp/local.exp: ptype Local
PASS -> KFAIL
Michael C improved the test script.
http://sources.redhat.com/gdb/bugs/483
gdb.c++/local.exp: ptype Local
http://sources.redhat.com/gdb/bugs/1516
[regression] local classes, gcc 2.95.3, dwarf-2
. gdb.java/jmisc.exp: *
gdb.java/jmisc1.exp: *
* -> *
Something from the previous spin (the first spin) was
anomalous and has improved. This happened in just one
configuration, gcc HEAD binutils 2.14 -gstabs+. I did not
investigate this. It may have been a test bed glitch.
. gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
PASS -> blank
blank -> PASS
Same analysis as gdb 6.0 suite 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 30
thread 1 31 1
thread 2 32 0
thread 3 31 1
thread 4 31 1
thread 5 32 0
. gdb HEAD
. suite HEAD
. gdb.cp/annota2.exp: annotate-quit
KFAIL -> PASS
gdb.cp/annota3.exp: annotate-quit
FAIL -> PASS
Same analysis as gdb 6.0 suite 6.0.
. gdb.cp/local.exp: ptype l
blank -> KFAIL
blank -> PASS
gdb.cp/local.exp: ptype Local
PASS -> KFAIL
Same analysis as gdb 6.0 suite HEAD.
. 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 29
thread 1 29 3
thread 2 32 0
thread 3 31 1
thread 4 30 2
thread 5 32 0
. gdb carlton_dictionary-branch
. suite carlton_dictionary-branch
There were many changes caused by an import of from gdb HEAD. I
did not analyze the test result changes in depth, but nothing
screamed out at me on a superficial inspection.
. suite HEAD
Same analysis as gdb carlton_dictionary_branch suite HEAD, but
with not as many changes. I will list only the regressions in the
test results.
. gdb.threads/pthreads.exp: apply backtrace command to all three threads
PASS -> FAIL
This is a backtrace bug from HEAD, not a c_d-b specific bug.
http://sources.redhat.com/gdb/bugs/1505
[regression] gdb prints a bad backtrace for a thread
. gdb drow-cplus-branch
. suite drow-cplus-branch
No significant improvements or regressions from the previous spin.
. suite HEAD
No significant improvements or regressions from the previous spin.
. Test Matrix
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
dejagnu => dejagnu 1.4.3
expect => expect 5.39
tcl => tcl 8.4.5
suite => 6.0, HEAD, carlton_dictionary-branch, drow-cplus-branch
gdb => 6.0, HEAD, carlton_dictionary-branch, drow-cplus-branch
cc => gcc 2.95.3, gcc 3.2-7-rh, gcc 3.3.2, gcc gcc-3_3-branch, gcc gcc-3_4-branch, gcc HEAD
as => binutils 2.13.90.0.2-rh, binutils 2.14, binutils HEAD
ld => binutils 2.13.90.0.2-rh, binutils 2.14, binutils HEAD
libc => glibc 2.2.93-5-rh
gformat => dwarf-2, stabs+
glevel => 2
count 136
'target' and 'host' are gnu configuration triples.
'osversion' is the host operating system name, which is additional
information beyond 'host'.
'tcl', 'expect', and 'dejagnu' are host packages to run tests.
'suite' is the version name of the gdb test suite.
'gdb' is a version name.
'cc', 'as', 'ld', and 'libc' are package 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.
I test gdb carlton_dictionary_branch and gdb drow-cplus-branch only
with as/ld from binutils 2.14, not with vendor as/ld or binutils HEAD
as/ld. This means I do not test c_d-b and d-c-b with vendor gcc.
I test each version gdb with its own gdb-test-suite and also with
gdb-test-suite HEAD.
. Package Versions
. This Spin
binutils HEAD 2004-01-27 09:05:46 UTC
gcc HEAD 2004-01-27 09:18:37 UTC
gcc gcc-3_3-branch 2004-01-27 09:26:38 UTC
gcc gcc-3_4-branch 2004-01-27 09:34:08 UTC
gdb HEAD 2004-01-28 05:33:45 UTC (approximate)
gdb carlton_dictionary-branch 2004-01-28 05:34:40 UTC
gdb drow-cplus-branch 2004-01-28 05:38:59 UTC
The date on gdb HEAD is approximate because of a script glitch on my
part. I accidentally did a cvs checkout with no "-D" option and did
not notice it until later. The files were checked out between
05:33:45 and 05:37:40 by my system clock, which would be within a
few seconds of an NTP server at that time.
. Last Spin
binutils HEAD 2004-01-22 23:13:58 UTC
gcc HEAD 2004-01-23 03:08:37 UTC
gcc gcc-3_3-branch 2004-01-23 03:15:28 UTC
gcc gcc-3_4-branch 2004-01-23 03:21:08 UTC
gdb HEAD 2004-01-24 03:11:40 UTC
gdb carlton_dictionary-branch 2004-01-24 03:13:52 UTC
gdb drow-cplus-branch 2004-01-24 03:15:58 UTC
. 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
I tweaked the order of 'gdb' and 'suite' in the tables.