This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
sunday project, gdb, 2003-11-26
- 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: Fri, 28 Nov 2003 15:43:04 -0500 (EST)
- Subject: sunday project, gdb, 2003-11-26
. Highlights of This Spin
Ian L-T fixed some more bugs in the C++ demangler. One of the bug
fixes triggered a latent bug in gdb.
Binutils HEAD has a new optimization, ELF_LINK_POINTER_EQUALITY_NEEDED.
This makes gdb unable to set a breakpoint in a shared library.
The current tables are always at:
http://www.shout.net/~mec/sunday/current/index.html
Michael C
. Old Bugs Fixed
. libiberty
Ian L-T fixed 17 failures in the C++ demangler test suite,
introduced 0 new failures, and added 4 new tests which pass.
http://sources.redhat.com/gdb/bugs/19
gdb v3 demangler fails on hairyfunc5 hairyfunc6 hairyfunc7
Fixed by the new demangler.
. New Bugs Detected
. binutils HEAD
http://sources.redhat.com/gdb/bugs/1470
ELF_LINK_POINTER_EQUALITY_NEEDED breaks shlib-call.exp
binutils HEAD has a new optimization ELF_LINK_POINTER_EQUALITY_NEEDED.
This causes regressions in gdb.base/shlib-call.exp
. gdb HEAD
http://sources.redhat.com/gdb/bugs/1471
[regression] ptype prints "int operator int();" with new demangler, stabs+
gdb HEAD has a ptype bug with the new demangler.
This is a gdb bug, not a demangler bug.
. PR Count
Query executed 2003-11-27 15:20:09 UTC
1468 matches found
24 analyzed
662 closed
21 feedback
748 open
3 paperwork
10 suspended
1468 TOTAL
. Libiberty Testing
. target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
binutils HEAD 719 tests, 6 failures
gcc 2.95.3, binutils HEAD All 616 tests passed
gcc 3.3.2, binutils HEAD 649 tests, 0 failures
gcc gcc-3_3-branch, binutils 2.14 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 719 tests, 6 failures
gcc HEAD, binutils HEAD 719 tests, 6 failures
gcc HEAD, binutils vendor 719 tests, 6 failures
gdb HEAD 719 tests, 1 failures
gdb carlton_dictionary-branch 715 tests, 31 failures
gdb gdb_6_0-branch 649 tests, 0 failures
Ian L-T fixed some more bugs in the demangler.
You see several demanglers here because libiberty takes a while to
propagate into various trees, and because I checkout the gdb tree
several hours after the gcc tree (I checkout binutils, build
binutils, checkout gcc, build gcc, then checkout gdb. It takes me
about 12 hours to build all the gcc's). During that time, the
demangler got improved some more and the improvements propagated
into gdb HEAD libiberty.
In the gcc version of the demangler: 17 old failures were fixed, 5
new failures were introduced, and 4 new tests passed.
In the gdb version of the demangler, which is one day newer: 17 old
failures were fixed, 0 new failures were introduced, and 4 new tests
passed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11028
The standalone C++ demangler doesn't work on some symbols
I keep some libiberty logs at:
http://www.shout.net/~mec/sunday/libiberty/2003-11-25.log
http://www.shout.net/~mec/sunday/libiberty/2003-11-21.log
http://www.shout.net/~mec/sunday/libiberty/2003-06-30.log
. Gdb Testing
My tables are at
http://www.shout.net/~mec/sunday/2003-11-26/index.html
The previous tables are at
http://www.shout.net/~mec/sunday/2003-11-21/index.html
. Non-PASS Results
gdb 6.0 316 non-PASS results
gdb gdb_6_0-branch 319 non-PASS results
gdb HEAD 412 non-PASS results
. gdb 6.0
. gdb.base/shlib-call.exp: cont
gdb.base/shlib-call.exp: cont {2}
PASS -> blank
gdb.base/shlib-call.exp: cont {the program is no longer running}
gdb.base/shlib-call.exp: cont {the program is no longer running} {2}
blank -> FAIL
gdb.base/shlib-call.exp: re-run to bp in shared library (PR's 16495, 18213)
gdb.base/shlib-call.exp: re-run to bp in shared library
gdb.base/shlib-call.exp: set bp in shared library
PASS -> FAIL
This happened with binutils HEAD 2003-11-25 14:53:33 UTC,
with all versions of gcc and both -gdwarf-2 and -gstabs+.
I filed a PR and sent a note to the binutils group.
http://sources.redhat.com/gdb/bugs/1470
ELF_LINK_POINTER_EQUALITY_NEEDED breaks shlib-call.exp
Here are gdb.log excerpts:
# gdb 6.0, gcc 3.3.2, binutils HEAD 2003-11-20, -gdwarf-2
(gdb) break shr1
Breakpoint 1 at 0x80484b0
(gdb) PASS: gdb.base/shlib-call.exp: set bp in shared library
# gdb 6.0, gcc 3.3.2, binutils HEAD 2003-11-25 14:53:33 UTC
(gdb) break shr1
Function "shr1" not defined.
(gdb) FAIL: gdb.base/shlib-call.exp: set bp in shared library
The other FAILs are cascade failures from this.
. gdb.base/shreloc.exp: get_msym_addrs fn_[12] (0x8048564 0x8048584 0x4001377c 0x4001677c)
PASS -> blank
. gdb.base/shreloc.exp: get_msym_addrs fn_[12] (0x4001377c 0x4001677c)
blank -> PASS
This is an effect of the ELF_LINK_POINTER_EQUALITY_NEEDED
optimization. gdb reports the address of the minsyms for "fn_1"
and "fn_2". There are no more stubs in the main executable for
shared library functions that are not referencd through
pointers, so the output of this test reflects the lack of stubs.
. gdb.mi/mi*-pthreads.exp: check mi_thread_command_set: -thread-select [3456]
blank -> PASS
PASS -> blank
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/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 26
thread 1 26 0
thread 2 26 0
thread 3 26 0
thread 4 26 0
thread 5 26 0
. gdb gdb_6_0-branch
checkout date is '2003-11-26 07:44:27 UTC'
previous date is '2003-11-21 06:27:24 UTC'
. gdb.base/shlib-call.exp: cont
gdb.base/shlib-call.exp: cont {2}
PASS -> blank
gdb.base/shlib-call.exp: cont {the program is no longer running}
gdb.base/shlib-call.exp: cont {the program is no longer running} {2}
blank -> FAIL
gdb.base/shlib-call.exp: re-run to bp in shared library (PR's 16495, 18213)
gdb.base/shlib-call.exp: re-run to bp in shared library
gdb.base/shlib-call.exp: set bp in shared library
PASS -> FAIL
Same analysis as gdb 6.0.
. gdb.base/shreloc.exp: get_msym_addrs fn_[12] (0x8048564 0x8048584 0x4001377c 0x4001677c)
PASS -> blank
. gdb.base/shreloc.exp: get_msym_addrs fn_[12] (0x4001377c 0x4001677c)
blank -> PASS
Same analysis as gdb 6.0.
. gdb.cp/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.mi/mi*-pthreads.exp: check mi_thread_command_set: -thread-select [3456]
blank -> PASS
PASS -> blank
Same analysis as gdb 6.0.
. gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
PASS -> blank
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 4 22
thread 1 22 4
thread 2 25 1
thread 3 25 1
thread 4 26 0
thread 5 26 0
. gdb HEAD
checkout date is '2003-11-26 07:42:26 UTC'
previous date is '2003-11-21 06:25:07 UTC'
. gdb.arch/i386-unwind.exp: running to main in runto
FAIL -> blank
gdb.arch/i386-unwind.exp: continue past gdb1435
PASS -> blank
gdb.arch/i386-unwind.exp: run past gdb1435
blank -> PASS
Mark K improved the startup part of this script to avoid a FAIL.
. gdb.base/gdb1250.exp: setting breakpoint at abort
blank -> FAIL
gdb.base/gdb1250.exp: *
* -> *
gdb.base/gdbvars.exp: Set value-history[1] using $1
PASS -> unresolved
With binutils HEAD, gdb is unable to set a breakpoint on a
function in a shared library.
http://sources.redhat.com/gdb/bugs/1470
ELF_LINK_POINTER_EQUALITY_NEEDED breaks shlib-call.exp
gdb.log excerpt:
(gdb) break abort
Function "abort" not defined.
(gdb) FAIL: gdb.base/gdb1250.exp: setting breakpoint at abort
ERROR: couldn't run to breakpoint
The UNRESOLVED result in gdbvars.exp is just a cascade from the
ERROR in gdb1250.exp.
. gdb.base/shlib-call.exp: cont
gdb.base/shlib-call.exp: cont {2}
PASS -> blank
gdb.base/shlib-call.exp: cont {the program is no longer running}
gdb.base/shlib-call.exp: cont {the program is no longer running} {2}
blank -> FAIL
gdb.base/shlib-call.exp: re-run to bp in shared library (PR's 16495, 18213)
gdb.base/shlib-call.exp: re-run to bp in shared library
gdb.base/shlib-call.exp: set bp in shared library
PASS -> FAIL
Same analysis as gdb 6.0.
. gdb.base/shreloc.exp: get_msym_addrs fn_[12] (0x8048564 0x8048584 0x4001377c 0x4001677c)
PASS -> blank
. gdb.base/shreloc.exp: get_msym_addrs fn_[12] (0x4001377c 0x4001677c)
blank -> PASS
Same analysis as gdb 6.0.
. gdb.cp/annota2.exp: annotate-quit
gdb.cp/annota2.exp: annotate-quit
Same analysis as gdb gdb_6_0-branch.
. gdb.cp/class2.exp: *
PASS
gdb.cp/class2.exp: print * aap at marker return 0
PASS
KFAIL
Michael C wrote a new test script. All results were either PASS
or KFAIL.
. gdb.cp/classes.exp: ptype class Foo
PASS -> blank
gdb.cp/classes.exp: ptype class Foo (obsolescent gcc or gdb)
blank -> PASS
"ptype class Foo" prints an incorrect line "int operator int();".
This happened with gcc 3.3.2, gcc gcc-3_3-branch, and gcc HEAD,
with -gstabs+. This is a latent bug in gdb tickled by the new
demangler.
http://sources.redhat.com/gdb/bugs/1471
[regression] ptype prints "int operator int();" with new demangler, stabs+
. gdb.cp/cplusfuncs.exp: print &'hairyfunc5'
gdb.cp/cplusfuncs.exp: print &'hairyfunc6'
gdb.cp/cplusfuncs.exp: print &'hairyfunc7'
KFAIL -> PASS
Ian L-T fixed a bug in the C++ demangler. Woot!
http://sources.redhat.com/gdb/bugs/19
gdb v3 demangler fails on hairyfunc5 hairyfunc6 hairyfunc7
. gdb.cp/cplusfuncs.exp: print &'overload1arg(unsigned)'
PASS -> blank
gdb.cp/cplusfuncs.exp: print &'overload1arg(unsigned int)'
blank -> PASS
The new demangler returns 'unsigned int' instead of 'unsigned'.
No problem.
. gdb.cp/virtfunc.exp: print pEe->vd()
FAIL -> PASS
Another fluctuation in this unstable test. This might be
another manifestation of PR gdb/1465, but I haven't
investigated.
. gdb.objc/nondebug.exp: successfully compiled objc with posix threads test case
blank -> PASS
gdb.objc/nondebug.exp: break on non-debuggable method (timeout)
blank -> FAIL
Adam F write a new test script.
There is one major new test, but this tests hangs and times out
at an unexpected gdb prompt.
I submitted a patch to fix this:
http://sources.redhat.com/ml/gdb-patches/2003-11/msg00611.html
[rfa/testsuite/objc] nondebug.exp: add a kfail and clean-up
. gdb.objc/objcdecode.exp: successfully compiled objc with posix threads test case
. gdb.objc/objcdecode.exp: break on multiply defined method
blank -> PASS
gdb.objc/objcdecode.exp: continue after break on multiply defined symbol
gdb.objc/objcdecode.exp: continue after break on multiply defined symbol (timeout)
blank -> FAIL
Adam F wrote a new test script.
There are two major new tests. One of the tests always PASSes,
which is good, but it de-synchronizes the input stream, which is
bad. The second test sometimes gets de-railed and FAILs with
tiemout without even running, and sometimes does its job and
reports a FAIL.
I submitted a patch to fix this:
http://sources.redhat.com/ml/gdb-patches/2003-11/msg00612.html
[rfc/testsuite/objc] objcdecode.exp: fix and clean up
. 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 26
thread 1 26 0
thread 2 26 0
thread 3 26 0
thread 4 26 0
thread 5 26 0
. Test Matrix
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
gdb => 6.0, gdb_6_0-branch, HEAD
gcc => 2.95.3, 3.2-7-rh, 3.3.2, gcc-3_3-branch, HEAD
binutils => 2.13.90.0.2-rh, 2.14, HEAD
glibc => 2.2.93-5-rh
gformat => dwarf-2, stabs+
glevel => 2
count 78 = 1 * 1 * 1 * 3 * (4*3+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.
'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*3+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.2
flex 2.5.4
bison 1.875
tcl 8.4.4
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.7.tar.gz
ftp://ftp.shout.net/pub/users/mec/migbat/migbat-0.7.tar.gz
. Test Bed Changes Since Last Report
None.