This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
sunday project, gdb, 2003-07-08
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gcc-testresults at sources dot redhat dot com, gdb-testers at sources dot redhat dot com
- Date: Wed, 9 Jul 2003 12:23:33 -0400
- Subject: sunday project, gdb, 2003-07-08
Highlights of this report
. As of 2003-07-07, there are no debug info regressions from gcc 3.3 to
gcc-3_3-branch on native i686-pc-linux-gnu with -gdwarf-2 and -gstabs+.
Bring on gcc 3.3.1!
. g++ HEAD -gstabs+ works again.
Michael C
. Old Bugs Fixed
. gcc HEAD
Michael C fixed PR gcc/10055.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10055
[3.4 regression] gcc emits "<internal>" as source filename with -gstabs+
. New Bugs Detected
None.
. PR Count
Query executed 2003-07-09T16:16:19Z
1275 matches found
17 analyzed
578 closed
21 feedback
645 open
3 paperwork
11 suspended
1275 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-07-08/index.html
The previous report was 2003-07-03:
http://www.shout.net/~mec/sunday/2003-07-03/Analysis.txt
. Non-PASS Results
gdb 5.3: 0 test aborts, 358 non-PASS results
gdb gdb_6_0-branch: 0 test aborts, 301 non-PASS results
gdb HEAD: 0 test aborts, 303 non-PASS results
. 5.3
. gdb.c++/annota2.exp: *
gdb.c++/anon-union.exp: *
gdb.c++/classes.exp: *
gdb.c++/m-data.exp: *
gdb.c++/m-static.exp: *
gdb.c++/method.exp: *
gdb.c++/namespace.exp: *
gdb.c++/overload.exp: *
gdb.c++/ovldbreak.exp: *
gdb.c++/templates.exp: *
gdb.c++/try_catch.exp: *
FAIL -> PASS
FAIL -> null
XFAIL -> null
null -> PASS
Michael C fixed PR gcc/10055. This fixed about 60 FAILs with
g++ HEAD -gstabs+.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10055
[3.4 regression] gcc emits "<internal>" as source filename with -gstabs+
. 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.trace/actions.exp: *
Something freaky happened in one configuration:
# gdb.log
# gdb 5.3, gcc gcc-3_3-branch, binutils vendor, -gstabs+
Running /berman/migchain/source/gdb-5.3/gdb/testsuite/gdb.trace/actions.exp ...
WARNING: Couldn't set the height to 0
WARNING: Couldn't set the width to 0.
Executing on host: gcc /berman/migchain/source/gdb-5.3/gdb/testsuite/gdb.trace/actions.c -w -gstabs+ -g2 -lm -o /tmp/Migbat-83acf46f-25c8-4547-af48-9ad9dd00b5a6/test/gdb.trace/actions (timeout = 300)
WARNING: remote_expect statement without a default case?!
ERROR: couldn't load /tmp/Migbat-83acf46f-25c8-4547-af48-9ad9dd00b5a6/test/gdb.trace/actions into gdb (end of file).
ERROR: Couldn't send list actions.c:1 to GDB.
UNRESOLVED: gdb.trace/actions.exp:
FAIL: gdb.trace/actions.exp: Could not find gdb_recursion_test function testcase
/berman/migchain/source/gdb-5.3/gdb/testsuite/gdb.trace/actions.exp completed in 1 seconds
proc default_gdb_start didn't call remote_spawn properly, but it
did manage to emit its characteristic WARNINGs about "Couldn't
set the height to 0" and "Couldn't set the width to 0". Note
that the test completed in 1 second so it wasn't actually taking
any timeouts.
This looks like one of those nasty TCL syntax gotchas where the
TCL interpreter quietly skips over some chunks of code and
executes others. I am going to throw this on the "unexplained
mysteries" pile.
. gdb_6_0-branch
checkout date is '2003-07-08 12:57:04 UTC'
previous date was '2003-07-03 16:16:42 UTC'
. gdb.base/selftest.exp: next over lim_at_start initialization
gdb.base/selftest.exp: step over corearg initialization
gdb.base/selftest.exp: step over initial brace
PASS -> null
gdb.base/selftest.exp: step over execarg initialization
null -> PASS
This is a harmless change induced by a change in my test bed.
selftest.exp uses the gdb executable itself as a target program.
Unlike most other test scripts, this script does not depend on
the target compiler; it depends on the host C compiler. I
upgraded the host compiler from gcc 3.2.3 to gcc 3.3 and that
causes this fluctuation. Also, neither selftest.exp nor main.c
have changed since the last test run.
. gdb.c++/annota2.exp: *
gdb.c++/anon-union.exp: *
gdb.c++/casts.exp: *
gdb.c++/classes.exp: *
gdb.c++/m-data.exp: *
gdb.c++/m-static.exp: *
gdb.c++/method.exp: *
gdb.c++/namespace.exp: *
gdb.c++/overload.exp: *
gdb.c++/ovldbreak.exp: *
gdb.c++/pr-1023.exp: *
gdb.c++/pr-1210.exp: *
gdb.c++/pr-574.exp: *
gdb.c++/printmethod.exp: *
gdb.c++/psmang.exp: *
gdb.c++/rtti.exp: *
gdb.c++/templates.exp: *
gdb.c++/try_catch.exp: *
FAIL -> PASS
FAIL -> null
XFAIL -> null
null -> PASS
null -> KFAIL
Same analysis as 5.3. This fixed about 120 fails with g++ HEAD
-gstabs+.
. gdb.c++/annota2.exp: annotate-quit
Same analysis as 5.3.
. 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
null -> PASS
PASS -> null
Fluctuation with unknown cause. Probably harmless.
. gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
Same analysis as 5.3.
. 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
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, 11 (slow with kill breakpoint)
gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
null -> PASS
PASS -> null
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 11 23
thread 1 20 14
thread 2 29 5
thread 3 31 3
thread 4 33 1
thread 5 34 0
. gdb HEAD
checkout date is '2003-07-08 12:54:38 UTC'
previous date was '2003-07-03 16:12:56 UTC'
. gdb.base/selftest.exp: next over lim_at_start initialization
gdb.base/selftest.exp: step over corearg initialization
gdb.base/selftest.exp: step over initial brace
PASS -> null
gdb.base/selftest.exp: step over execarg initialization
null -> PASS
Same analysis as gdb_6_0-branch.
. gdb.c++/annota2.exp: *
gdb.c++/anon-union.exp: *
gdb.c++/casts.exp: *
gdb.c++/classes.exp: *
gdb.c++/m-data.exp: *
gdb.c++/m-static.exp: *
gdb.c++/method.exp: *
gdb.c++/namespace.exp: *
gdb.c++/overload.exp: *
gdb.c++/ovldbreak.exp: *
gdb.c++/pr-1023.exp: *
gdb.c++/pr-1210.exp: *
gdb.c++/pr-574.exp: *
gdb.c++/printmethod.exp: *
gdb.c++/psmang.exp: *
gdb.c++/rtti.exp: *
gdb.c++/templates.exp: *
gdb.c++/try_catch.exp: *
FAIL -> PASS
FAIL -> null
XFAIL -> null
null -> PASS
null -> KFAIL
Same analysis as 5.3. This fixed about 120 fails with g++ HEAD
-gstabs+.
. gdb.c++/annota2.exp: annotate-quit
Same analysis as 5.3.
. 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
null -> PASS
PASS -> null
Same analysis as gdb_6_0-branch.
. gdb.threads/linux-dp.exp: philosopher is distinct: 3
gdb.threads/linux-dp.exp: philosopher is distinct: 4
gdb.threads/linux-dp.exp: philosopher is distinct: 6
gdb.threads/linux-dp.exp: philosopher is distinct: 7
FAIL -> PASS
PASS -> FAIL
Same analysis as gdb_6_0-branch.
. gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
PASS -> null
null -> PASS
Same analysis as gdb_6_0-branch.
. 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 11 23
thread 1 26 8
thread 2 30 4
thread 3 29 5
thread 4 32 2
thread 5 34 0
. Test Matrix
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
gdb => 5.3, gdb_6_0-branch%20030708, HEAD%20030708
gcc => 2.95.3, 3.2-7-rh, 3.3, gcc-3_3-branch%20030707, HEAD%20030707
binutils => 2.13.90.0.2-rh, 2.14, binutils-2_14-branch%20030707, HEAD%20030707
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.
cvs versions (head and branch) show the checkout date after a '%' delimiter.
'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 upgraded host gcc from gcc 3.2.3 to gcc 3.3.