This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
gdb 5.3 versus gdb gdb_6_0-branch 2003-07-18 19:01:19 UTC
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gdb at sources dot redhat dot com
- Cc: gdb-testers at sources dot redhat dot com
- Date: Fri, 1 Aug 2003 14:31:31 -0400
- Subject: gdb 5.3 versus gdb gdb_6_0-branch 2003-07-18 19:01:19 UTC
(I promised that I would publish this last week.)
Here is a comparison of gdb 5.3 versus gdb gdb_6_0-branch.
These are all the issues I know about which affect gdb 6.0.
The last report was 2003-03-27. Since the last report, the following
problems have been fixed:
. x86-64 regressions
. Java regression
. multi-register variables do not work with dwarf-2
. gcc HEAD -gstabs+
Michael C
. Andrew Cagney list
http://sources.redhat.com/ml/gdb/2003-07/msg00192.html
- m32r revival
- annotate 3 commit
- mi 2->3 switch (needed?)
. 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?
. backtrace regressions
The new frame code introduced several regressions in backtracing.
http://sources.redhat.com/gdb/bugs/1250
[regression] bad backtrace when function that calls 'abort' at end
http://sources.redhat.com/gdb/bugs/1253
[regression] bad backtrace for '<function called from gdb>'
http://sources.redhat.com/gdb/bugs/1255
[regression] bad backtrace for libc function 'sleep'
gdb/1250 has been fixed for dwarf-2 but is still broken for stabs+.
When I use gdb, I often put breakpoints on functions like 'abort'
and 'exit' to find out why a program is mysteriously exiting.
gdb/1255 is important for multi-threaded debugging. With a
multi-threaded program, most threads are usually suspended on
'sleep' or 'select' or a similar functoin. It hurts debugging if
the user cannot get backtraces for these threads.
. PRs
Just raw lists, no judgements.
2003-07-31 01:06:08 UTC, priority=high, 9 matches found
1303 audit doco invariant sections
1255 [regression] bad backtrace for libc function 'sleep'
1250 [regression] bad backtrace when function that calls 'abort' at end
1140 tcl/unix/configure broken
1138 Cannot compile gdb on Tru64Unix 5.1A
926 `(gdb) set backtrace-below-main' confusing
857 GDB contains intl/ droppings
708 unassigned Can't build 5.3 branch (and probably trunk).
378 ``GNU/Linux'' ``Linux kernel''
2003-07-31 01:07:00 UTC, severity=critical, 40 matches found
1256 [ia64] Can't call functions in inferior
1255 [regression] bad backtrace for libc function 'sleep'
1253 [regression] bad backtrace for '<function called from gdb>'
1251 GDB crash
1250 [regression] bad backtrace when function that calls 'abort' at end
1245 cp-support.c:332: internal-error: cp_entire_prefix_len
1232 solaris/g++
1226 GDB does not complete build for crossing debugging PPC on Solaris
1219 cannot access subprocess memory
1211 set
1189 Gdb internal in callstack displaying
1171 GDB 5.3 misreads the symbol table for very big executables
1154 gdb-5.3 + glibc-2.3.2 fail for my multithreaded program
1144 Same as 1042, but with example
1140 tcl/unix/configure broken
1139 gdb-5.2.92 crash - full debug available
1123 insight+dejagnu-weekly-20030304: does not build on sparc-sun-solaris2.8
1100 gdb 5.3 fails to build on m68k-sun-sunos4.1.1_U1
1084 set print object on does not work correctly in some cases
1060 g++ -static and STL strings
980 No threading support in Mandrake 9.0 (gdb 5.2.1 - 5.3.0)
955 build failure with GDB-5.3: sparc-nat.c structure redefinition errors with sparc64-linux, glibc-2.2.x
926 `(gdb) set backtrace-below-main' confusing
922 Breakpoints give crash, bad behavior w/ C++, gcc 3.2 on Solaris
903 GDB Solaris 2.8 SPARC
867 v5.2.1 fail to compile on AIX 5.1
851 gdb-internal-error: store_typed_address
820 GDB broken under gcc 3.2 - can't print any local variables or class members
767 alpha Unix Tru64
706 SIGBUS or SIGSEGV trying to set breakpoint in C++ program
678 gdb dies reading symbols on Compaq Tru64 5.1
676 Alpha OSF1, gcc, internal GDB error in mdebugread
627 Internal error when attaching to process
610 gdb crashes when listing source of g++-3.1-compiled binary
582 can't find linker symbol for virtual table when trying view class data
558 gdb crashes when I run the program the second time
540 Solaris C++ symbol table corrupted; ELF sections exceed SECT_OFF_MAX
250 gdb 5.0 chokes on "file" cmd for a ppc .elf created by gcc v2.95.2
11 gdb does not handle pic code correctly
7 cout << 1 doesn't work for c++
. gdb test suite
Here are details for all the test result regressions between gdb 5.3
and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC. The tables are from:
http://www.shout.net/~mec/sunday/2003-07-28/Compare-by-gdb.html
This is limited to native i686-pc-linux-gnu on one osversion
(red hat linux 8) with one glibc (2.2.93-5-rh, the system glibc).
I do cover gcc v2 and v3, several versions of binutils, and
debugging formats dwarf-2 and stabs+.
The count of non-PASS results, combining all configurations tested:
gdb 5.3: 348 non-PASS results out of 8401 tests.
gdb gdb_6_0-branch: 300 non-PASS results out of 9345 tests.
The only serious regressions are the backtrace bugs, described above.
All the other regressions are unimportant. You can skip reading all
the details below and you won't miss anything important.
Many of the regressions are tests which are new in the branch and
not present in gdb 5.3. To get a comparison, I ran most of the
tests with gdb 5.3 as well. These worked for everything except
gdb.mi/*.exp, which is version-locked to gdb. Most of the new tests
expose existing bugs in gdb, not regressions.
. gdb.base/constvars.exp: ptype crass
blank -> PASS
blank -> 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 gdb_6_0-branch 2003-07-28 19:01:19 UTC and dwarf-2,
gdb prints 'char * const ptr', which is correct. With stabs+,
gdb prints 'char *ptr', the same bad behavior as gdb 5.3.
This happens with both gcc v2 and gcc v3.
. gdb.base/constvars.exp: ptype crisp
blank -> PASS
blank -> XFAIL
blank -> XPASS
This is a new test.
This test does 'ptype' on a structure with a 'char * const *ptr'
member. gdb 5.3 and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC
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: 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
blank -> PASS
blank -> FAIL
These are new tests.
With gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC, these tests FAIL
with gcc 2.95.3 -gdwarf-2. These tests PASS with gcc 2.95.3
-gstabs+ and all gcc v3.
# gdb.log excerpt
# gcc 2.95.3, binutils 2.14, -gdwarf-2
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^M
(gdb) PASS: gdb.base/store.exp: set variable l = 4
print l
$41 = <value optimized out>^M
(gdb) FAIL: gdb.base/store.exp: up print new l - int
gdb 5.3 behaves better with these tests, so this is a regression.
It is not a very bad regression because gdb gdb_6_0-branch
2003-07-28 19:01:19 UTC just refuses to do something legitimate,
rather than printing illegal values.
. gdb.base/store.exp: up print old r - charest
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
blank -> PASS
blank -> FAIL
These are new tests.
With gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC, these tests FAIL
with gcc v3 -gdwarf-2. These tests PASS with gcc v3 -gstabs+ and
all gcc v2.
# gdb.log excerpt
# gcc 3.3, binutils 2.14, -gdwarf-2
print r
$34 = <value optimized out>
(gdb) FAIL: gdb.base/store.exp: up print old r - charest
gdb 5.3 behaves better with these tests, so this is a regression.
It is not a very bad regression because gdb gdb_6_0-branch
2003-07-28 19:01:19 UTC just refuses to do something legitimate,
rather than printing illegal values.
. gdb.base/store.exp: print old r - longest
gdb.base/store.exp: up print old r - longest
blank -> PASS
blank -> FAIL
These are new tests.
With gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC, these tests FAIL
with gcc HEAD -gdwarf-2. These tests PASS with all other gcc v2
and v3, dwarf-2 and stabs+.
# gdb.log excerpt
# gdb gdb_6_0-branch, gcc HEAD, binutils 2.14, -gdwarf-2
print r
Unhandled dwarf expression opcode
(gdb) FAIL: gdb.base/store.exp: print old r - longest
gdb 5.3 behaves worse with these tests: it prints a bogus value.
# gdb.log excerpt
# gdb 5.3, gcc HEAD, binutils 2.14, -gdwarf-2
print r
$18 = -4611696253334454274
(gdb) FAIL: gdb.base/store.exp: print old r - longest
So this is an improvement in gdb gdb_6_0-branch.
. gdb.base/watchpoint.exp: next after watch x
blank -> KFAIL
This is a new test for an existing bug in gdb.
http://sources.redhat.com/gdb/bugs/38
Watchpoint does not trigger when first set
Both gdb 5.3 and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC
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 2003-02-12 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
blank -> PASS
blank -> KFAIL
This is a new test for an existing bug in gdb.
gdb 5.3 and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC behave the
same:
PASS with gcc 3.3 and later, stabs+
KFAIL with gcc 3.3 and later, dwarf-2
KFAIL with gcc 3.2-7-rh, both dwarf-2 and stabs+
KFAIL with gcc 2.95.3, both dwarf-2 and stabs+
. gdb.c++/classes.exp: print (ClassWithEnum::PrivEnum) 42
XFAIL -> FAIL
gdb 5.3 and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC behave the
same. The test suite improved and marks this behavior as FAIL
rather than XFAIL.
# gdb.log excerpt
# gcc 3.3, binutils 2.14, -gdwarf-2
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
ptype pickiness. Needs more investigation. This is not important.
. gdb.c++/local.exp: Local out of scope
blank -> PASS
blank -> KFAIL
This is a new test.
http://sources.redhat.com/gdb/bugs/825
gdb gets scope of class local to a function wrong
gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC behaves the same or
better than gdb 5.3 in all configurations.
. 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
blank -> PASS
blank -> FAIL
These are new tests which reveal an existing bug in gdb.
The results from gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC
are the same or better than the results from gdb 5.3 in all
configurations.
. 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'
blank -> PASS
blank -> FAIL
These are new tests which reveal an existing bug in gdb.
gdb 5.3 FAILs in all configurations.
gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC results:
FAIL with gcc 2.95.3, dwarf-2
FAIL with gcc 2.95.3, stabs+
PASS with gcc v3, dwarf-2
FAIL with gcc v3, stabs+
. gdb.c++/namespace.exp: print cXOtherFile
gdb.c++/namespace.exp: print XOtherFile
blank -> PASS
blank -> FAIL
These are new tests which reveal an existing bug in gdb.
The results from gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC
are the same or better than the results from gdb 5.3 in all
configurations.
. gdb.c++/pr-1023.exp: break myClass::performBlocking
blank -> PASS
blank -> KFAIL
This is a new test.
gdb 5.3 and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC behave the
same:
PASS with gcc 2.95.3, dwarf-2
KFAIL with gcc 2.95.3, stabs+
PASS with gcc v3, dwarf-2
PASS with gcc v3, stabs+
This is a simple symbol lookup test. gdb 5.3 showed the same
behavior, so it is not a regression. It is a serious bug though.
. gdb.c++/rtti.exp: print *e1
gdb.c++/rtti.exp: print *e2
blank -> KFAIL
This is a new test.
gdb 5.3 and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC behave the
same: KFAIL on every configuration.
. gdb.c++/virtfunc.exp: print pEe->D::vg()
XFAIL -> FAIL
XFAIL -> KFAIL
gdb 5.3 and gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC behave the
same:
FAIL with gcc 2.95.3, dwarf-2
FAIL with gcc 2.95.3, stabs+
KFAIL with gcc v3, dwarf-2
KFAIL with gcc v3, stabs+
The test script now marks this behavior with FAIL and KFAIL,
rather than XFAIL.
# gdb.log excerpt
# gcc 2.95.3, binutils 2.14, -gdwarf-2
# 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 3.3, binutils 2.14, -gdwarf-2
# 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.mi/gdb701.exp: create fooPtr
blank -> FAIL
This is a new test.
gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC behaves like this:
FAIL with gcc 2.95.3, -gdwarf-2
PASS with gcc 2.95.3, -gstabs+
FAIL with gcc 3.2-7-rh, -gdwarf-2
PASS with gcc 3.2-7-rh, -gstabs+
PASS with gcc 3.3 and later, -gdwarf-2
PASS with gcc 3.3 and later, -gstabs+
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.mi/mi-syn-frame.exp: 407-stack-list-frames
blank -> FAIL
This is a new test.
With gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC, this test FAILed
in every configuration.
http://sources.redhat.com/gdb/bugs/1253
[regression] bad backtrace for '<function called from gdb>'
This is a regression from 5.3.
This is one of the backtrace bugs.
. gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
This test has bad results randomly in both 5.3 and gdb_6_0-branch
2003-07-28 19:01:19 UTC.
http://sources.redhat.com/gdb/bugs/568
GDB confused by messily-exiting multi-threaded programs
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/linux-dp.exp: philosopher is distinct: 6
gdb.threads/linux-dp.exp: philosopher is distinct: 7
PASS -> FAIL
With gdb 5.3, these tests PASS in all configurations.
With gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC, these tests FAIL
with gcc 2.95.3 and PASS with gcc v3.
These particular tests are looking at a backtrace. The backtrace
is deficient with both gdb 5.3 and gdb gdb_6_0-branch 2003-07-28
19:01:19 UTC, but the test script is adapted for the particular
breakage with gdb 5.3. So this is not a regression in gdb
behavior.
. gdb.threads/pthreads.exp: check backtrace from main thread
gdb.threads/pthreads.exp: apply backtrace command to all three threads
PASS -> FAIL
With gdb 5.3, these tests PASS in all configurations.
With gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC, these tests FAIL
in all configurations.
http://sources.redhat.com/gdb/bugs/1255
[regression] bad backtrace from libc function 'sleep'
This is a regression from gdb 5.3.
. 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
This test script was broken in gdb 5.3.
With gdb gdb_6_0-branch 2003-07-28 19:01:19 UTC, all tests PASSed
in all configurations except for the "thread N ran" tests. Here
are the counts per thread.
PASS FAIL
thread 0 9 25
thread 1 24 10
thread 2 30 4
thread 3 30 4
thread 4 32 2
thread 5 34 0