This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]