This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
sunday project, gdb, 2003-02-23
- 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: Sun, 23 Feb 2003 15:53:34 -0600
- Subject: sunday project, gdb, 2003-02-23
Highlights of this report:
. There are two new regressions in gdb this week.
FAIL: gdb.base/store.exp: new check struct 4
FAIL: gdb.trace/packetlen.exp: setup collect actions
. I restored coverage of gcc gcc-3_2-branch, because I see activity on
the branch. I see no regressions in the gdb test suite from gcc 3.2.2
to gcc gcc-3_2-branch%20030222
. Michael C fixed a stabs+ c++ bug in gcc gcc-3_3-branch and gcc HEAD.
This was pr gdb/1026 and pr gcc/9717.
pr gdb/1026: regression in casts.exp from gcc 3.2.1 to gcc gcc-3_3-branch%20030128
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1026
pr gcc/9717: regression: g++ -gstabs+ emits unwanted stabs for base class
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&cmd=view&pr=9717
There are still some stabs+ regressions from gcc 3.2.2 to
gcc gcc-3_3-branch%20030222. I will look at these soon.
My tables are here:
http://www.shout.net/~mec/sunday/2003-02-23/index.html
Michael C
. Old Bugs Fixed
pr gdb/1026: regression in casts.exp from gcc 3.2.1 to gcc gcc-3_3-branch%20030128
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1026
Michael C, with a little help from Daniel J, analyzed this in gcc
and then went on to fix it. This bug was shallow in concept but
caused about 70 FAILs in c++ tests with gcc gcc-3_3-banch or gcc
HEAD with -gstabs+.
. New Bugs Detected
gdb.base/store.exp: new check struct 4
PASS -> FAIL
This is a regression with gdb HEAD with gcc 2.95.3 -gdwarf-2.
No analysis yet.
gdb.trace/packetlen.exp: setup collect actions
PASS -> FAIL
This is a regression in gdb HEAD with -gdwarf-2.
Daniel J has a patch for this and I have tested the patch.
http://sources.redhat.com/ml/gdb-patches/2003-02/msg00552.html
. PR count
Query executed 2003-02-23T16:44:23Z
1087 matches found
15 analyzed
447 closed
12 feedback
604 open
1 paperwork
8 suspended
. Libiberty Testing
. target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
binutils HEAD 649 tests, 0 failures
gcc 2.95.3, binutils HEAD All 616 tests passed
gcc 3.2.2, binutils HEAD All 648 tests passed
gcc gcc-3_2-branch, binutils 2.13.2.1 All 648 tests passed
gcc gcc-3_2-branch, binutils HEAD All 648 tests passed
gcc gcc-3_2-branch, binutils vendor All 648 tests passed
gcc gcc-3_3-branch, binutils 2.13.2.1 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.13.2.1 649 tests, 0 failures
gcc HEAD, binutils HEAD 649 tests, 0 failures
gcc HEAD, binutils vendor 649 tests, 0 failures
gdb HEAD 649 tests, 0 failures
. Gdb Testing
My tables are at:
http://www.shout.net/~mec/sunday/2003-02-23/index.html
The previous report was 2003-02-15:
http://www.shout.net/~mec/sunday/2003-02-15/Analysis.txt
. Counts
gdb 5.3: 0 test aborts, 325 non-PASS results
gdb HEAD: 0 test aborts, 273 non-PASS results
A non-PASS result is any result except PASS. This includes ERROR,
WARNING, NOTE, FAIL, KPASS, KFAIL, XPASS, XFAIL, UNRESOLVED,
UNTESTED, UNSUPPORTED, and unknown results.
. 5.3
. gdb.c++/annota2.exp: annotate-quit
pr gdb/544: gdb.c++/annota2.exp: annotate-quit test sometimes fails
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=544
Fluctuation in test result probably due to a signal handling
race in the command loop.
. gdb.c++/classes.exp: *
gdb.c++/derivation.exp: *
gdb.c++/inherit.exp: *
gdb.c++/virtfunc.exp: *
FAIL -> PASS
pr gdb/1026: regression in casts.exp from gcc 3.2.1 to gcc gcc-3_3-branch%20030128
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1026
Michael C fixed a bug in gcc. The bug affected C++ stabs
information in gcc gcc-3_3-branch and gcc HEAD.
. gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
pr gdb/568: GDB confused by messily-exiting multi-threaded programs
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=568
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-branch
checkout date is '2003-02-23 07:08:03 UTC'
The most recent ChangeLog entry is dated 2003-02-04.
I do not cover this branch as I think it is unlikely that we will
make another release from it.
. HEAD
checkout date is '2003-02-23 07:06:10 UTC'
. gdb.base/store.exp: new check struct 4
PASS -> FAIL
This happens with gcc 2.95.3 -gdwarf-2.
This worked fine on 2003-02-15:
# target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0,
# gdb=HEAD%200302015, gcc=2.95.3, binutils=2.13.2.1, glibc=2.2.93-5-rh,
# gformat=dwarf-2, glevel=2
set variable u = s_4^M
(gdb) PASS: gdb.base/store.exp: set variable u = s_4
print u^M
$38 = {s = {1, 2, 3, 4}}^M
(gdb) PASS: gdb.base/store.exp: new check struct 4
And now it is broken:
# target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0,
# gdb=HEAD%200302023, gcc=2.95.3, binutils=2.13.2.1, glibc=2.2.93-5-rh,
# gformat=dwarf-2, glevel=2
set variable u = s_4^M
(gdb) PASS: gdb.base/store.exp: set variable u = s_4
print u^M
$38 = {s = {1, 2, 0, 0}}^M
(gdb) FAIL: gdb.base/store.exp: new check struct 4
I will investigate this.
. gdb.c++/annota2.exp: annotate-quit
Same analysis as 5.3.
. gdb.c++/casts.exp: *
gdb.c++/classes.exp: *
gdb.c++/derivation.exp: *
gdb.c++/inherit.exp: *
gdb.c++/pr-574.exp: *
gdb.c++/virtfunc.exp: *
gdb.mi/gdb792.exp: list children of class C
FAIL -> PASS
pr gdb/1026.
Same analysis as 5.3.
. gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
Same analysis as 5.3.
. gdb.threads/schedlock.exp: *
Age cannot wither, nor custom stale, their infinite variety.
This test is still in a state where it's better to analyze the
absolute results than to compare results from date to date.
. gdb.trace/packetlen.exp: setup collect actions
PASS -> FAIL
This is a regression in gdb HEAD. It happens with -gdwarf-2 with
both gcc v2 and gcc v3, even with stable gcc's such as 2.95.3
and 3.2.2.
gdb.log excerpt:
(gdb) trace gdb_c_test
Tracepoint 1 at 0x804846b: file /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.trace/actions.c, line 55.
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
> collect parm[0], parm[1], parm[2], parm[3]
> collect parm[4], parm[5], parm[6], parm[7]
> collect p, local_reg, local_static, local_static_sizeof
Cannot find value of botched symbol `p'.
(gdb) FAIL: gdb.trace/packetlen.exp: setup collect actions
Daniel J has a patch for this:
http://sources.redhat.com/ml/gdb-patches/2003-02/msg00552.html
. Test Matrix
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
gdb => 5.3, HEAD%20030223
gcc => 2.95.3, 3.2-7-rh, 3.2.2, gcc-3_2-branch%20030222, gcc-3_3-branch%20030222, HEAD%20030222
binutils => 2.13.90.0.2-rh, 2.13.2.1, HEAD%20030222
libc => 2.2.93-5-rh
gformat => dwarf-2, stabs+
count 64 = 1 * 1 * 1 * 2 * (5*3+1*1) * 1 * 2
'target' and 'host' are gnu configuration triples.
'osversion' is the host operating system name, which is additional
information beyond 'host'.
'gdb', 'gcc', 'binutils', and 'libc' 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.
'count' is the total number of configurations tested.
The vendor gcc is available only with vendor binutils,
thus the '(5*3+1*1)' term for gcc/binutils combinations.
. Baseline software
. host=i686-pc-linux-gnu, osversion=red-hat-8.0
make 3.79.1
binutils 2.13.2.1
gcc 3.2.2
flex 2.5.4
bison 1.875
tcl 8.4.1
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 they are licensed under the GPL.
ftp://ftp.shout.net/pub/users/mec/migchain/migchain-0.3.tar.gz
. Test Bed Changes Since Last Report
I re-added target gcc-3_2-branch.
I added a new attribute 'glevel' with a value of '2' (for example,
-gstabs+ -g2). When I can allocate more processor cycles to gdb
testing, I will cover both '-g2' and '-g3'. The hard part was
counting up enough backslashes to get "-g$gformat -g$glevel" through
several layers of scripting. My perl script has six backslashes!
"runtest ... -g$gformat\\\\\\ -g$glevel ..."
The report writer used to truncate test names. I couldn't think of a
good reason to truncate these names so I stopped truncating them.
The pseudo-version 'vendor' no longer appears; all tools versions are
resolved to actual versions, such as 'gcc 3.2-7-rh' for my vendor gcc.
I renamed the 'libc' attribute to 'glibc'.