This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
sunday project, gdb, 2003-06-21
- 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: Tue, 24 Jun 2003 13:11:02 -0400
- Subject: sunday project, gdb, 2003-06-21
It's back!
http://www.shout.net/~mec/sunday/2003-06-21/index.html
Highlights of this test run:
. Binutils is beautiful
. Gcc has gotchas
. Gdb fixed two old bugs:
java break-main-run
multiple-register variables
. Gdb introduced one new bug:
backtrace broken in several circumstances (new i386 frame)
Michael C
. Old Bugs Fixed
. gdb HEAD
Someone fixed PR gdb/1090, where gdb prints bogus data for
register values which are in more than one register. This was an
important bug for the release.
David C fixed java! jmisc1.exp and jmisc2.exp now pass the
"break main; run" tests.
. New Bugs Detected
. gcc 3.3
gcc 3.3 has several regressions versus gcc 3.2.3 in c++ with
-gstabs+.
gdb.c++/classes.exp gdb HEAD, -gstabs+
gdb.c++/inherit.exp gdb 5.3+HEAD, -gstabs+
gdb.c++/local.exp gdb 5.3+HEAD, -gstabs+
I will analyze these later.
. gcc HEAD
gcc HEAD has many new regressions since 2003-04-09. I have to dig
into gcc and file a bunch of bug reports. I plan to start with gcc
3.3 versus gcc HEAD and report them on that basis.
. gdb HEAD
gdb HEAD has problems with backtraces in several cases. I filed a
separate PR for each case, but they all come from the new i386 frame
code. These are all regressions versus gdb 5.3.
pr gdb/1250: [regression] bad backtrace when function that calls 'abort' at end
http://sources.redhat.com/gdb/bugs/1250
pr gdb/1253: [regression] bad backtrace for '<function called from gdb>'
http://sources.redhat/com/gdb/bugs/1253
pr gdb/1255: [regression] bad backtrace for libc function 'sleep'
http://sources.redhat.com/gdb/bugs/1255
. PR Count
Query executed 2003-06-24T16:59:31Z
1255 matches found
18 analyzed
572 closed
21 feedback
630 open
3 paperwork
11 suspended
1255 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 649 tests, 0 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.2.2, binutils binutils-2_14-branch All 648 tests passed
gcc 3.2.2, binutils HEAD All 648 tests passed
gcc 3.2.3, binutils binutils-2_14-branch All 648 tests passed
gcc 3.2.3, binutils HEAD All 648 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.13.2.1 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.13.2.1 649 tests, 0 failures
gcc HEAD, binutils 2.14 649 tests, 0 failures
gcc HEAD, binutils binutils-2_14-branch 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-06-21/index.html
The previous report was 2003-04-09:
http://www.shout.net/~mec/sunday/2003-04-09/Analysis.txt
. Non-PASS Results
gdb 5.3: 0 test aborts, 409 non-PASS results
gdb HEAD: 0 test aborts, 455 non-PASS results
. 5.3
. gdb.*/*.exp: *
Many regressions in gcc HEAD from 2003-04-08 to 2003-06-20, in
both -gdwarf-2 and -gstabs+. There are 80-90 lines of
regressions. I will analyze these later.
. gdb.c++/annota2.exp: annotate-quit
pr gdb/544: gdb.c++/annota2.exp: annotate-quit test sometimes fails
http://sources.redhat.com/gdb/bugs/544
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
pr gdb/568: GDB confused by messily-exiting multi-threaded programs
http://sources.redhat.com/gdb/bugs/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
. HEAD
checkout date is '2003-06-21 17:58:52 UTC'
. gdb.*/*.exp: *
Many regressions in gcc HEAD from 2003-04-08 to 2003-06-20, in
both -gdwarf-2 and -gstabs+. I can't distinguish the changes in
gcc HEAD from the changes in gdb HEAD, so I am just washing my
hands of gcc HEAD changes in this report.
. gdb.asm/asm-source.exp: disassem &globalvar &globalvar+1
gdb.asm/asm-source.exp: disassem &staticvar &staticvar+1
gdb.asm/asm-source.exp: x/i &globalvar
gdb.asm/asm-source.exp: x/i &staticvar
null -> PASS
Andrew C wrote some new tests.
. gdb.base/charset.exp: *
null -> PASS
PASS -> null
Elena Z updated the test script.
. gdb.base/completion.exp: complete 'info func mar'
PASS -> null
gdb.base/completion.exp: complete 'info func marke'
null -> PASS
Elena Z improved the test script. If I recall correctly, some
targets have a system library function that starts with 'mar',
so the test needed to become more specific.
. gdb.base/corefile.exp: *
WARNING -> null
null -> PASS
null -> XPASS
Jim B fixed the test script so that it works on targets where
core files are named 'core.PID'. This includes my target,
native red hat linux 8.
. gdb.base/corefile.exp: backtrace in corefile.exp
null -> FAIL
Backtrace fails when the last instruction in a function is a
CALL to another function, because the return address is not
within the scope of the function.
This happened with gcc v3 with both -gdwarf-2 and -gstabs+. gcc
v2 is okay. gdb 5.3 works fine, so this is a regression bug in
gdb.
pr gdb/1250: [regression] bad backtrace when function that calls 'abort' at end
http://sources.redhat.com/gdb/bugs/1250
. gdb.base/corefile.exp: print func2::coremaker_local
null -> FAIL
This happened with gcc v3 with -gstabs+. gcc v3 with -gdwarf-2
are okay. All gcc v2 are okay.
This is another manifestation of pr gdb/1250.
func2::coremaker_local is an auto array, so it gets hurt when
gdb messes up the stack frame.
pr gdb/1250: [regression] bad backtrace when function that calls 'abort' at end
http://sources.redhat.com/gdb/bugs/1250
. gdb.base/fileio.exp: *
null -> PASS
Corinna V wrote a new test script.
. gdb.base/gdb1090.exp: print s24
KFAIL -> PASS
Someone fixed pr gdb/1090, which was about register values which
are stored in multiple registers.
. gdb.base/maint.exp: help maint print dummy-frames
gdb.base/maint.exp: maint print dummy-frames
null -> PASS
Andrew C wrote some new tests.
. gdb.base/readline.exp: *
null -> PASS
Mark K wrote some new tests.
. gdb.base/selftest.exp: next over dirsize initialization
PASS -> null
gdb.base/selftest.exp: next over lim_at_start initialization
gdb.base/selftest.exp: next over lim_at_start initialization
null -> PASS
Richard H modified the tests.
. gdb.base/selftest.exp: step into xmalloc call
PASS -> FAIL
This happened with all configurations tested: gcc v2 and v3,
-gdwarf-2 and -gstabs+. It worked with gdb HEAD%20030409.
This is a bug in selftest.exp. It steps through captured_main
until it reaches the line that initializes 'dirarg' with a call
to 'xmalloc' and then returns, or until 26 lines have been
executed, whichever comes first. Yuck! A recent change in
captured_main pushed the line count one beyond 26, causing this
FAIL.
I submitted a patch to fix this:
http://sources.redhat.com/ml/gdb-patches/2003-06/msg00720.html
. gdb.base/shreloc.exp: *
null -> PASS
Raoul G wrote a new test script.
. gdb.base/store.exp: *
PASS -> null
null -> PASS
Andrew C updated the test script.
. gdb.base/store.exp: new check struct 4
FAIL -> PASS
This is probably a gdb bug fix (specifically, the fix for
variables that live in two or more registers), but it might just
be a test script change. I'm not going to analyze it.
. gdb.base/store.exp: up print old l - int
gdb.base/store.exp: up print new l - int
gdb.base/store.exp: up print old l - long
gdb.base/store.exp: up print new l - long
null -> FAIL
These are new tests. The FAILs happened with gcc 2.95.3
-gdwarf-2. These tests worked fine with gcc 2.95.3 -gstabs+,
and with all gcc v3.
Log excerpt:
# gcc 2.95.3 -gdwarf-2
(gdb) PASS: gdb.base/store.exp: continue to add_int
up
#1 0x0804856d in wack_int (u=-1, v=-2) at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/store.c:84
84 l = add_int (l, r);
(gdb) PASS: gdb.base/store.exp: up int
print l
$39 = <value optimized out>
(gdb) FAIL: gdb.base/store.exp: up print old l - int
print r
$40 = -2
(gdb) PASS: gdb.base/store.exp: up print old r - int
set variable l = 4
Cannot access memory at address 0x0
(gdb) PASS: gdb.base/store.exp: set variable l = 4
print l
$41 = <value optimized out>
(gdb) FAIL: gdb.base/store.exp: up print new l - int
The body of wack_int is:
int
wack_int (register int u, register int v)
{
register int l = u, r = v;
l = add_int (l, r);
return l;
}
gdb behaved decently. The test script needs to be improved.
. gdb.base/store.exp: up print old r - char
gdb.base/store.exp: up print old r - short
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 - float
null -> FAIL
These are new tests. The FAILs happened with gcc v3 -gdwarf-2.
These tests worked fine with gcc v3 -gstabs+ and with all gcc
v2.
Log excerpt:
# gcc 3.3 -gdwarf-2
(gdb) PASS: gdb.base/store.exp: continue to add_int
up
#1 0x08048441 in wack_int (u=-2, v=-1) at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/store.c:84
84 l = add_int (l, r);
(gdb) PASS: gdb.base/store.exp: up int
print l
$39 = -1
(gdb) PASS: gdb.base/store.exp: up print old l - int
print r
$40 = <value optimized out>
(gdb) FAIL: gdb.base/store.exp: up print old r - int
set variable l = 4
(gdb) PASS: gdb.base/store.exp: set variable l = 4
print l
$41 = 4
(gdb) PASS: gdb.base/store.exp: up print new l - int
The body of wack_int is:
int
wack_int (register int u, register int v)
{
register int l = u, r = v;
l = add_int (l, r);
return l;
}
gdb behaved decently. The test script needs to be improved.
. gdb.c++/annota2.exp: annotate-quit
Same analysis as 5.3.
. gdb.c++/maint.exp: *
null -> PASS
David C wrote a new test script.
. gdb.c++/namespace.exp: print c
gdb.c++/namespace.exp: print cc
gdb.c++/namespace.exp: print 'C::cc'
gdb.c++/namespace.exp: print cd
gdb.c++/namespace.exp: print 'E::cde'
gdb.c++/namespace.exp: print shadow
gdb.c++/namespace.exp: print cOtherFile
null -> FAIL
David C wrote some new tests. These tests PASSed with all gcc
v2 and with gcc v3 -gdwarf-2. They FAILed with gcc v3 -gstabs+.
These are C++ namespace lookup tests. gdb 5.3 fails in the same
way as gdb HEAD%20030621, so these are not regressions. They
are just new tests that reveal existing bugs in gdb.
. gdb.c++/namespace.exp: print cX
gdb.c++/namespace.exp: print 'F::cXf'
gdb.c++/namespace.exp: print X
gdb.c++/namespace.exp: print 'G::Xg'
null -> FAIL
David C wrote some new tests. These tests PASSed with gcc v2
-gdwarf2. They FAILed with all gcc v2 and with gcc v3 -gstabs+.
These are C++ namespace lookup tests. gdb 5.3 fails in the same
way as gdb HEAD%20030621, so these are not regressions. They
are just new tests that reveal existing bugs in gdb.
. gdb.c++/namespace.exp: print cXOtherFile
gdb.c++/namespace.exp: print XOtherFile
null -> FAIL
David C wrote some new tests. These tests PASSed with all gcc
v2 and with gcc v3 -gdwarf-2. They FAILed with gcc v3 -gstabs+.
These are C++ namespace lookup tests. gdb 5.3 fails in the same
way as gdb HEAD%20030621, so these are not regressions. They
are just new tests that reveal existing bugs in gdb.
. gdb.c++/rtti.exp: *
null -> PASS
null -> FAIL
null -> KFAIL
David C wrote a new test script. The test script produced the
same results with gdb 5.3 and gdb HEAD%20030621, so these are
just new tests that reveal existing bugs in gdb.
. gdb.java/jmisc1.exp: *
gdb.java/jmisc2.exp: *
FAIL -> PASS
FAIL -> null
David C fixed gdb.
. gdb.mi/mi-syn-frame.exp: 407-stack-list-frames
PASS -> FAIL
This test regressed from PASS to FAIL in all configurations
tested: gcc v2 and v3, -gdwarf-2 and -gstabs+.
This is a regression in gdb versus gdb 5.3.
pr gdb/1253: [regression] bad backtrace for '<function called from gdb>'
http://sources.redhat/com/gdb/bugs/1253
. gdb.mi/mi1-symbol.exp: *
null -> PASS
Thierry S wrote a new test script.
. gdb.objc/basicclass.exp: *
null -> PASS
gdb.objc/basicclass.exp: *
null -> ERROR
null -> WARNING
null -> FAIL
null -> UNRESOLVED
null -> UNSUPPORTED
Adam F wrote a new test script.
The test script is all PASS on all the compilers that I build
from source.
I got a lot of grief when I used the vendor compiler because I
hadn't installed the vendor packages for Objective C. I
installed a couple of RPM's and it works fine now.
. 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: 6
gdb.threads/linux-dp.exp: philosopher is distinct: 7
PASS -> FAIL
These tests FAILed with gcc 2.95.3, both -gdwarf-2 and -gstabs+,
in five configurations. They PASSed with gcc 2.95.3 -gstabs+ in
one configuration. This is a thread test so that it is a bit
nondeterministic.
These tests always PASSed with gcc v3, both -gdwarf-2 and
-gstabs+.
This test script implements "dining philosophers". These
particular tests switch to each philosopher thread and look at a
backtrace. In the instances where they FAIL, the backtrace
looks like this:
# gcc 2.95.3 -gdwarf-2
(gdb) PASS: gdb.threads/linux-dp.exp: selected thread: 6
where^M
#0 0x420d3b2e in select () from /lib/i686/libc.so.6^M
(gdb) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 6
The test FAILed because the backtrace is deficient.
With gdb 5.3, the deficient backtrace looks like this:
# gcc 2.95.3 -gdwarf-2
(gdb) PASS: gdb.threads/linux-dp.exp: selected thread: 6
where^M
#0 0x420d3b2e in select () from /lib/i686/libc.so.6^M
#1 0x00000000 in ?? ()^M
(gdb) PASS: gdb.threads/linux-dp.exp: philosopher is distinct: 6
The test script knows about the "\\?\\?" frame and considers
that a pass! That is why gdb 5.3 and gdb HEAD%20030409 PASSed
and gdb HEAD%20030416 FAILed.
There is a comment in the test script:
## Sometimes we can't get a backtrace. I'm going to call
## this a pass, since we do verify that at least one
## thread was interesting, so we can get more consistent
## test suite totals. But in my heart, I think it should
## be an xfail.
So gdb's behavior is not too bad. It handles the threads
properly. There is some bug that causes it to have problems
with the backtrace from select(), but that bug has not gotten
any worse. And the bug does not happen with gcc v3. So I am
going to hold off on filing a PR for this.
. gdb.threads/pthreads.exp: check backtrace from main thread
gdb.threads/pthreads.exp: apply backtrace command to all three threads
PASS -> FAIL
These tests FAILed in all configurations tested, gcc v2 and v3,
-gdwarf-2 and -gstabs+. These tests PASSed with gdb 5.3 and gdb
HEAD%20030416.
This is more backtrace damage. 'check backtrace' is damaged at
'sleep', and 'apply backtrace' is damaged at
'pthread_start_thread'.
pr gdb/1255: [regression] bad backtrace from libc function 'sleep'
http://sources.redhat.com/gdb/bugs/1255
. gdb.threads/pthreads.exp: check backtrace from thread 2
PASS -> FAIL
#45
This test FAILed in just one configuration: gcc gcc-3_3-branch,
binutils HEAD, -gstabs+. It's another instance of pr gdb/1255.
pr gdb/1255: [regression] bad backtrace from libc function 'sleep'
http://sources.redhat.com/gdb/bugs/1255
. gdb.threads/schedlock.exp: *
* -> *
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 3 ran (didn't run)
gdb.threads/schedlock.exp: thread 4 ran (didn't run)
* -> FAIL
The results of schedlock.exp are useful now. It's useless to
compare these results to the previous test run, but the absolute
results in the non-PASS table are useful.
The non-PASS results from schedlock.exp are listed above. All
other tests PASSed in all configurations tested.
The counts are:
thread 0 56 FAILs in 62 test runs
thread 1 4 FAILs in 62 test runs
thread 3 2 FAILs in 62 test runs
thread 4 2 FAILs in 62 test runs
. Test Matrix
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
gdb => 5.3, HEAD%20030621
gcc => 2.95.3, 3.2-7-rh, 3.2.2, 3.2.3, 3.3, gcc-3_3-branch%20030620, HEAD%20030620
binutils => 2.13.90.0.2-rh, 2.13.2.1, 2.14, binutils-2_14-branch%20030620, HEAD%20030620
glibc => 2.2.93-5-rh
gformat => dwarf-2, stabs+
glevel => 2
count 124 = 1 * 1 * 1 * 2 * (6*5+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 '(6*5+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.4.tar.gz
. Test Bed Changes Since Last Report
I released migchain 0.4. The baseline software versions are still the
same as last report; I will upgrade them soon. The baseline needs
upgrades to binutils, gcc, and tcl.
On the target side, I added binutils 2.14, binutils
binutils-2_14-branch, gcc 3.2.3, and gcc 3.3. I dropped gcc
gcc-3_2-branch. Gabriel Dos Reis, the gcc 3.2.3 release manager,
said that 3.2.3 is the last 3.2.X release.
I started the test run before gdb 6 branched, so I didn't cover the
gdb 6 branch this time.
Binutils is beautiful:
2.13.2.1 -> 2.14 no regressions
2.14 -> binutils-2_14-branch no regressions
2.14 -> HEAD no regressions
Gcc has gotchas:
3.2.2 -> 3.2.3 no regressions
3.2.3 -> 3.3 several regressions
several regressions in c++ with -gstabs+
3.3 -> gcc-3_3-branch no regressions
3.3 -> HEAD many regressions
50-100 regression lines, all over
I will look at the gcc regressions later.