gdb 5.3 versus gdb HEAD%200302015

[Michael Elizabeth Chastain <mec at shout dot net>]

Here's a list of all the issues that I've heard about that affect the
next release of gdb, 5.4/6.0.  Many of these need more investigation,
but I think I have enough info here to take up some bandwidth.

Michael C

. MI issues

    Andrew C attempted to obsolete annotation level 2 and got a lot of
    push-back from gdb front end writers who say that MI is not good
    enough for them to switch at all.  I don't know what our goal is for
    MI in the next release, so i can't say how much of this work needs
    to be done by the next release.

. build issues

    Andrew C says that there are several high priority PR's about build
    issues.

. gcc 3.3 and gcc 3.4 emit bad C++ stabs

    pr gdb/1026: ...
    http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1026

    pr gcc/9NNN: ...
    http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&cmd=view&pr=9NNN

    Daniel J says this is a bug in gcc and I agree.  I isolated the
    patch that caused the problem.  It looks easy to fix; so easy that I
    wrote a fix.  I reached out to gcc people on 2003-02-16 and am
    waiting for a reply.

. 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.

. 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.mi/gdb701.exp: create fooPtr

    Needs investigation.

. gdb test suite regressions

    The test suite found three issues above: the gcc C++ bad stabs,
    the jmisc2.exp regressions, and gdb701.exp FAILs.

    Details below for all the test result changes between gcc 5.3 and
    gcc HEAD%20030215.  The tables are directly from:

      http://www.shout.net/~mec/sunday/2003-02-15/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%20030215 and dwarf-2, gdb prints 'char * const ptr',
      which is correct.  With gdb HEAD%20030215 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%20030215 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.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++/casts.exp: cast base class pointer to derived class pointer
    gdb.c++/casts.exp: cast base class pointer to derived class pointer
      null -> FAIL
	stabs+ with gcc gcc-3_3-branch, gcc HEAD

      This is a high-priority bug.  It might be in either gdb or gcc.
      gcc changed its stabs+ output, and gdb does not handle the new
      output.  pr gdb/1026.

  . gdb.c++/classes.exp: ptype struct default_public_struct
      UNRESOLVED -> XFAIL

      This is an artifact of a cascade problem in with anon-union.exp,
      the previous test script.  The prime problem is a gcc internal
      compiler error with anon-union.c (pr gcc/9039).  gdb HEAD%20030215
      stifles the cascade although the prime problem continues.

  . 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%20030215 have this bug.
      With gdb HEAD%20030215, 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-574.exp: PR gdb/574
      null -> FAIL
      stabs+ with gcc gcc-3_3-branch, gcc HEAD

  . 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%20030215,
      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 occurred some time between 2003-02-01 and 2003-02-05.

  . gdb.mi/gdb701.exp: create fooPtr
      null -> FAIL
      dwarf-2 with gcc 2.95.3, 3.2-7-rh, 3.2.1, 3.2.2-20030203, gcc-3_2-branch

      New test.
      PR gdb/701 was lost from gnats.
      The PR has been recovered now -- so needs more investigation.
      Unable to tell if the bug was in 5.3 and in what configurations.

  . gdb.mi/gdb792.exp: list children of class C
      null -> FAIL
      stabs+ with gcc gcc-3_3-branch, gcc HEAD

  . 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%20030205 but
      it still is not useful to analyze.