This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
gdb 5.3 versus gdb HEAD%20030325
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gdb at sources dot redhat dot com
- Date: Thu, 27 Mar 2003 17:30:33 -0600
- Subject: gdb 5.3 versus gdb HEAD%20030325
It's time for another comparison of "5.3 versus HEAD". These are all
the issues I know about which 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
Andrew C mentioned that there were several high-priority build PR's.
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.
Michal L and Andrew C are working on this. Any status?
. Java regression
The test suite has only rudimentary coverage for Java, and the results
have regressed from 5.3. 'break jmisc.main' does not work for Java
programs.
David C has a patch for this. I will pursue this.
. multi-register variables do not work with dwarf-2
This is critical for m68hc11, which has a lot of multi-register
variables due to its small 16-bit registers. pr gdb/1107.
We've brought this to Daniel J's attention.
. gcc HEAD -gstabs+
gcc HEAD -gstabs+ is not usable with gdb 5.3 or gdb HEAD%20030325.
A c++ program has its source filename listed as '<internal>'
rather than the actual filename.
pr gcc/10055: [3.4 regression] gcc emits "<internal>" as source filename with -gstabs+
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&cmd=view&pr=10055
I have dropped coverage of gcc HEAD -gstabs+ until this bug is
fixed.
. PR's, priority=high or severity=critical
Just a raw list, no judgements. count=41.
NEW:
gdb/851 breakpoints gdb-internal-error: store_typed_address
gdb/1098 breakpoints lin-lwp.c:1106: gdb-internal-error: lin_lwp_wait: Assertion `WIFSTOPPED (status) && WSTOPSIG(status) == SIGSTOP' failed.
gdb/1144 breakpoints Same as 1042, but with example.
gdb/378 build ``GNU/Linux'' ``Linux kernel''
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/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 redefinition errors with sparc64-linux, glibc-2.2.x
gdb/1100 build gdb 5.3 fails to build on m68k-sun-sunos4.1.1_U1
gdb/1123 build insight+dejagnu-weekly-20030304: does not build on sparc-sun-solaris2.8
gdb/1138 build Cannot compile gdb on Tru64 Unix 5.1A
gdb/1140 build tcl/unix/configure broken
gdb/7 c++ cout << 1 doesn't work for c++
gdb/347 c++ class element access
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/1060 c++ g++ -static and STL strings
gdb/1084 c++ set print object on does not work correctly in some cases
gdb/1141 c++ cannot print local variables in (some) constructor functions
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 gb does not handle pic code correctly
gdb/1139 shlibs gdb-5.2.92 crash - full debug available
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/1107 symtab dwarf-2 multi-register variables, gdb prints random values
gdb/1149 symtab fix for pr java/1039
gdb/767 tdep alpha Unix Tru64
gdb/980 threads No threading support in Mandrake 9.0 (gdb 5.2.1 - 5.3.0)
gdb/1154 threads gdb-5.3 + glibc-2.3.2 fail for my multithreaded program
. gdb test suite regressions
Here are details for all the test result regressions between gcc 5.3
and gcc HEAD%20030325. The tables are directly from:
http://www.shout.net/~mec/sunday/2003-03-25/Compare-by-gdb.html
The issues that I consider serious enough for release-making
consideration are enumerated above.
. 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%20030325 and dwarf-2, gdb prints 'char * const ptr',
which is correct. With gdb HEAD%20030325 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%20030325 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%20030325
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.base/watchpoint.exp: next after watch x
null -> KFAIL
This is a new test for an existing bug in gdb.
pr gdb/38: ...
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=38
Both gdb 5.3 and gdb HEAD%20030325 have this bug.
. 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++/classes.exp: print ('ClassWithEnum::PrivEnum') 42
null -> KFAIL
Needs investigation.
. gdb.c++/classes.exp: print (ClassWithEnum::PrevEnum) 42
XFAIL -> FAIL
gdb has the same behavior in 5.3 and HEAD%2003025. The test suite
improved and marks this behavior as FAIL rather than XFAIL.
# gdb.log excerpt
print (ClassWithEnum::PrivEnum) 42^M
A syntax error in expression, near `42'.^M
(gdb) FAIL: gdb.c++/classes.exp: print (ClassWithEnum::PrivEnum) 42
. gdb.c++/classes.exp: ptype obj_with_enum
XFAIL -> FAIL
More ptype pickiness. Needs more investigation. This is not
important.
. 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%20030325 have this bug.
With gdb HEAD%20030325, 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%20030325,
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
gdb behaves the same in 5.3 and HEAD%20030325 (broken in both
cases). The test script now marks this behavior with FAIL and
KFAIL.
# gdb.log excerpt
# gcc v2 -- gdb prints the wrong value, should be 102
print pEe->D::vg()
$12 = 202
(gdb) FAIL: gdb.c++/virtfunc.exp: print pEe->D::vg()
# gdb.log excerpt
# gcc v3 -- gdb does not print any value
print pEe->D::vg()
Attempt to take address of value not located in memory.
(gdb) KFAIL: gdb.c++/virtfunc.exp: print pEe->D::vg() (PRMS: gdb/1064)
. 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.
Java debugging is already bit-rotting so a bit more bit rot
is okay for this release.
. 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.