This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
gdb 6.0 versus gdb HEAD
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: gdb-testers at sources dot redhat dot com
- Date: Sat, 10 Jan 2004 18:41:22 -0500 (EST)
- Subject: gdb 6.0 versus gdb HEAD
Here's a comparison of gdb 6.0 versus gdb HEAD 2004-01-09 22:05:53 UTC.
This is with my usual native i686-pc-linux-gnu test bed.
I used to do this by comparing
gdb 6.0 + test suite 6.0
gdb HEAD + test suite HEAD
That is the "compare by gdb" table in my regular reports. There are a
lot of differences in that table which are caused by differences in the
test suite, not differences in gdb. And the test suite quality is
inversely correlated with gdb quality: a good test is something that
makes gdb look bad, like gdb1056.exp, or gdb.cp/bs15503.exp on x86_64.
So this table is:
gdb 6.0 + test suite HEAD
gdb HEAD + test suite HEAD
These tables still have a little fluff, such as:
gdb.cp/maint.exp: help maint cp
FAIL -> PASS
If the fluff gets too noisy then I can enhance test suite HEAD
to handle gdb 6.0 better. But for now the fluff is really light,
about 5% to 10% of the total output.
Okay. Here are the actual regressions in the test results.
. gdb.cp/annota2.exp: annotate-quit
PASS -> KFAIL
Fluctuation in test result probably due to a signal handling
race in the command loop. This is a bug in gdb, but not a
regression from gdb 6.0.
http://sources.redhat.com/gdb/bugs/544
gdb.c++/annota2.exp: annotate-quit test sometimes fails
. gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42
PASS -> KFAIL
This happened with gcc 3.3.2, gcc gcc-3_3-branch, gcc HEAD with
-gstabs+. This is a bug in gdb or gcc. This is a regression from
gdb 6.0.
http://sources.redhat.com/gdb/bugs/826
variables in C++ namespaces have to be enclosed in quotes
gdb 6.0 prints: $26 = yellow
gdb HEAD prints: A syntax error in expression, near `42'.
. gdb.threads/print-threads.exp: Hit kill breakpoint, 10 (slow with kill breakpoint)
blank -> PASS
Fluctuation with unknown cause. Probably harmless.
. gdb.threads/pthreads.exp: apply backtrace command to all three threads
PASS -> FAIL
This is a bug in gdb.
This is a regression from gdb 6.0.
This happened with all configurations tested.
http://sources.redhat.com/gdb/bugs/1505
[regression] gdb prints a bad backtrace for a thread
. 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. I don't know whether this is a bug in gdb.
This is not a regression from gdb 6.0.
My test matrix is my usual:
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
gdb => 6.0, HEAD
gcc => 2.95.3, 3.2-7-rh, 3.3.2, gcc-3_3-branch, HEAD
as => 2.13.90.0.2-rh, 2.14, HEAD
ld => 2.13.90.0.2-rh, 2.14, HEAD
glibc => 2.2.93-5-rh
gformat => dwarf-2, stabs+
glevel => 2
count 52 = 1 * 1 * 1 * 3 * (4*3+1*1) * 1 * 2 * 1