This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
gdb 5.3 versus gdb 2003-02-23-cvs
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gdb at sources dot redhat dot com
- Date: Mon, 24 Feb 2003 10:59:26 -0600
- Subject: gdb 5.3 versus gdb 2003-02-23-cvs
Here's a list of all the issues that I've heard about that affect the
next release of gdb, 5.4/6.0.
Michael C
. MI issues
Andrew Cagney says that this is the critical issue for gdb 5.4/6.0:
http://sources.redhat.com/ml/gdb-patches/2003-02/msg00575.html
Andrew C: can you comment on the current MI status?
. Build issues
See the PR list below.
. x86-64 regressions
Michal Ludvig reported that native x86_64-unknown-linux-gnu
regressed significantly from gdb 5.3 to gdb 2003-02-01-cvs. He has
been actively working on bringing this target back up to 5.3
quality. I don't know if he's finished yet.
Michal L: can you comment on this?
. jmisc2.exp regression
pr gdb/1039: regression: cannot set breakpoint on jmisc.main(java.lang.String[])
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1039
. gdb.trace/packetlen.exp: setup collect actions
This is a dwarf-2 regression. Daniel J has a patch.
http://sources.redhat.com/ml/gdb-patches/2003-02/msg00552.html
. PR's, priority=high or severity=critical
Just a raw list, no judgements. count=37.
gdb/763 breakpoints gdb 5.2 removes the conditional breakpoints
gdb/851 breakpoints gdb-internal-error: store_typed_address
gdb/378 build ``GNU/Linux'' ``Linux kernel''
gdb/527 build GDB 5.2 incompatibilities with GNU textutils 2.0.21 in POSIX mode
gdb/558 build gdb crashes when I run the program the second time
gdb/591 build bfd/config.bfd does not support i768 (aka Intel P4)
gdb/660 build GDB 5.2 or 5.2.1 do not build on linux libc5, gcc 2.95.3
gdb/708 build Can't build 5.3 branch (and probably trunk)
gdb/857 build GDB contains intl/ droppings
gdb/867 build v5.2.1 fail to compile on AIX 5.1
gdb/888 build Cannot compile event-top.c
gdb/955 build build failure with GDB 5.3: sparc-nat.c structure redefinitions with sparc64-linux, glibc-2.2.x
gdb/7 c++ cout << 1 doesn't work for c++
gdb/347 c++ class element acess
gdb/582 c++ can't find linker symbol for virtual table when trying view class data
gdb/610 c++ gdb crashes when listing source of g++-3.1-compiled binary
gdb/922 c++ Breakpoints give crash, bad behavior w/C++, gcc 3.2 on Solaris
gdb/1023 c++ setting a breakpoint on C++ member functions
gdb/1060 c++ g++ -static and STL strings
gdb/1084 c++ set print object on does not work correctly in some cases
gdb/926 cli `(gdb) set backtrace-below-main' confusing
gdb/1039 java regression: cannot set breakpoint on jmisc.main(java.lang.String[])
gdb/11 shlibs gdb does not handle pic code correctly
gdb/29 symtab gdb has fixed size MAX_SECTIONS
gdb/250 symtab gdb 5.0 chokes on "file" cmd for a ppc .elf created by gcc v2.95.2
gdb/540 symtab Solaris C++ symbol table corrupted; ELF sections exceed SECT_OFF_MAX
gdb/627 symtab Internal error when attaching to process
gdb/676 symtab Alpha OSF1, gcc, internal GDB error in mdebugread
gdb/678 symtab gdb dies reading symbols on Compaq Tru64 5.1
gdb/706 symtab SIGBUS or SIGSEGV trying to set breakpoint in C++ program
gdb/820 symtab GDB broken under gcc 3.2 - can't print any local variables or class members
gdb/903 symtab GDB Solaris 2.8 SPARC
gdb/767 tdep alpha Unix Tru64
gdb/854 tdep gdb HC11/HC12 broken due to regcache
gdb/1089 tdep gdb HC11/HC12 crashes after info frame command
gdb/980 threads No threading support in Mandrake 9.0 (gdb 5.2.1 - 5.3.0)
gdb/1057 threads pthread_create locks up GDB on IRIX platform
. gdb test suite regressions
The test suite found two issues above: the jmisc2.exp regressions
and the packetlen.exp dwarf-2 problem.
Details below for all the test result changes between gcc 5.3 and
gcc HEAD%20030223. The tables are directly from:
http://www.shout.net/~mec/sunday/2003-02-23/Compare-by-gdb.html
. gdb.base/constvars.exp: ptype crass
null -> PASS
null -> XFAIL
This is a new test.
This test does 'ptype' on a structure with a 'char * const ptr'
member. With gdb 5.3 and dwarf-2, gdb prints the structure member
as 'char * constptr' with the single word 'constptr' -- obviously
incorrect. With gdb 5.3 and stabs+, gdb prints the structure
member as 'char *ptr', dropping the const.
With gdb HEAD%20030223 and dwarf-2, gdb prints 'char * const ptr',
which is correct. With gdb HEAD%20030223 and stabs+, gdb prints
'char *ptr', the same bad behavior as gdb 5.3.
. gdb.base/constvars.exp: ptype crisp
null -> PASS
null -> XFAIL
This is a new test.
This test does 'ptype' on a structure with a 'char * const *ptr'
member. gdb 5.3 and gdb HEAD%20030223 have the same behavior,
modulo whitespace changes. They both respond correctly with gcc
2.95.3 dwarf-2, gcc 3.X dwarf-2, and gcc 3.X stabs+; and they both
respond incorrectly with gcc 2.95.3 stabs+: 'char **' instead of
'char * const *'.
. gdb.base/ending-run.exp: continue after exit
null -> UNSUPPORTED
This is a new test which is working properly.
Some configurations (I don't know which ones) can land in a DLD
function after leaving main(). These configurations run this
particular test. Other configurations return UNSUPPORTED for this
test.
gdb's behavior is fine. I find the UNSUPPORTED a bit gratuitous.
Perhaps the test script should do nothing rather than generate an
UNSUPPORTED.
. gdb.base/store.exp: new check struct 4
null -> FAIL
pr gdb/1090: gdb prints wrong value for 8-byte variable in two 4-byte registers
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1090
This is a new test. This test FAILed with gcc 2.95.3 -gdwarf-2.
This test writes into an eight-byte variable which is stored in
two registers, a 'multi-register variable'. Then it reads back
the multi-register variable. Both gdb 5.3 and gdb HEAD%20030223
have incorrect code that returns only the first register, but gdb
5.3 somehow manages to succeed in a use case similar to this test
(probably with a matched pair of bogus writes and reads). So this
is not actually a regression in gdb, just a new manifestation of a
serious bug that was present in 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.
This was in gdb 5.3 and previous gdb releases. There was a brief
time around 200302012 when the new interpreter loop fixed it, but
that code broke ^Z handling. The fix for ^Z brought this bug back
again.
. gdb.c++/local.exp: Local out of scope
null -> PASS
null -> KFAIL
pr gdb/825: gdb gets scope of class local to a function wrong
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=825
This is a new test. Both gdb 5.3 and gdb HEAD%20030223 have this bug.
With gdb HEAD%20030223, this test PASSed with gcc v3 dwarf-2 and
KFAILed with gcc v2 dwarf-2, gcc v2 stabs+, and gcc v3 stabs+.
. gdb.c++/pr-1023.exp: break myClass::performBlocking
null -> PASS
null -> KFAIL
This is a new test.
This is a simple symbol lookup test. With gdb HEAD%20030223,
it KFAILed with gcc 2.95.3 -gstabs+ and PASSed with gcc 2.95.3
-gdwarf-2 and all gcc v3. gdb 5.3 showed the same behavior,
so it is not a regression. It is a serious bug though.
. gdb.c++/virtfunc.exp: print pEe->D::vg()
XFAIL -> FAIL
XFAIL -> KFAIL
Needs investigation.
Probably gdb stayed the same and the test suite improved.
. gdb.java/jmisc2.exp: setting breakpoint at jmisc.main(java.lang.String[])
null -> FAIL
gdb.java/jmisc2.exp: p *args
gdb.java/jmisc2.exp: p args
PASS -> FAIL
pr gdb/1039: regression: cannot set breakpoint on jmisc.main(java.lang.String[])
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1039
This is a regression in gdb. The test script is unable to set a
breakpoint on the main function (this action does not ordinarily
PASS, hence the null -> FAIL transition). The other FAILs
cascade from there.
This happened with all gcc v3 (gcc v2 did not include gjc).
This broke between 2003-02-01 and 2003-02-05.
. gdb.mi/gdb701.exp: create fooPtr
null -> FAIL
This is a new test. This test FAILed with -gdwarf-2 with
gcc 2.95.3, gcc 3.2-7-rh, and gcc 3.2.2.
Daniel J says this is a gcc bug and that it has been fixed in
gcc HEAD, gcc gcc-3_3-branch, and gcc-3_2-branch.
http://sources.redhat.com/ml/gdb/2003-02/msg00259.html
My testbed confirms this.
. 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
This test has bad results randomly in both 5.3 and HEAD%20030215.
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 was broken in 5.3. It's improved in HEAD%20030223 but
it still is not useful to analyze.
. gdb.trace/packetlen.exp: setup collect actions
PASS -> FAIL
This is a regression from gdb 5.3 to gdb HEAD%20030223. It
happened with all versions of gcc with -gdwarf-2.
Daniel J has a patch to fix this:
http://sources.redhat.com/ml/gdb-patches/2003-02/msg00552.html