gdb 5.3 versus gdb HEAD%200302015

gdb 5.3 versus gdb HEAD%200302015

[Michael Elizabeth Chastain]

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.

Re: gdb 5.3 versus gdb HEAD%200302015

[Daniel Jacobowitz]

On Sun, Feb 16, 2003 at 09:32:34PM -0600, Michael Elizabeth Chastain wrote:
> . gdb.mi/gdb701.exp: create fooPtr
> 
>     Needs investigation.

Ooh ooh.  I got this one.  The test is new in HEAD (wasn't in 5.3);
it's a GCC bug; it will be fixed in 3.3, 3.4, and 3.2.3 if any.  I
checked the patch in the day after 3.2.2.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 5.3 versus gdb HEAD%200302015

[David Carlton]

On Sun, 16 Feb 2003 21:32:34 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

>   . gdb.c++/virtfunc.exp: print pEe->D::vg()
>       XFAIL -> FAIL
>       XFAIL -> KFAIL

>       Needs investigation.
      
>       Probably gdb stayed the same and the test suite improved.

I'm curious: what shows up in gdb.log when you get FAIL here?  I just
KFAILed the output I saw; I have no reason to believe that there
aren't other valid outputs that would manifest the same bug, however.
Certainly you should feel free to add more KFAIL branches to that test
if you wish; just send them all to the same PR.

David Carlton
carlton@math.stanford.edu

Re: gdb 5.3 versus gdb HEAD%200302015

[Michal Ludvig]

Michael Elizabeth Chastain wrote:
> . 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.

It's better, but still not as good as 5.3. There is a problem with 
functions called from the (gdb) command line that make GDB crash. 
Because it's happening in Andrew's patch, I've sent him some more info 
so that he could look where was the problem.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

Re: gdb 5.3 versus gdb HEAD%200302015

[Michael Elizabeth Chastain]

drow> Ooh ooh.  I got this one.  The test is new in HEAD (wasn't in 5.3);
drow> it's a GCC bug; it will be fixed in 3.3, 3.4, and 3.2.3 if any.  I
drow> checked the patch in the day after 3.2.2.

Beautiful, I'll just slip a URL to this message into my tracking
document.  That takes care of the 5.4/6.0 angle.

My results are:

  PASS for all stabs+
  PASS for dwarf-2, gcc gcc-3_3-branch and gcc HEAD
  FAIL for dwarf-2, gcc 2.95.3 and gcc 3.2-7-rh and gcc 3.2.2

Which matches your report.

I dropped coverage of gcc gcc-3_2-branch, but I might bring it back,
because I see that people are still checking into that branch.

The real question: is there a gcc PR for this.  If there is a gcc PR,
then I can add an XFAIL arm to the test with the gcc PR number.

Michael C

Re: gdb 5.3 versus gdb HEAD%200302015

[Daniel Jacobowitz]

On Mon, Feb 17, 2003 at 10:32:30AM -0600, Michael Elizabeth Chastain wrote:
> drow> Ooh ooh.  I got this one.  The test is new in HEAD (wasn't in 5.3);
> drow> it's a GCC bug; it will be fixed in 3.3, 3.4, and 3.2.3 if any.  I
> drow> checked the patch in the day after 3.2.2.
> 
> Beautiful, I'll just slip a URL to this message into my tracking
> document.  That takes care of the 5.4/6.0 angle.
> 
> My results are:
> 
>   PASS for all stabs+
>   PASS for dwarf-2, gcc gcc-3_3-branch and gcc HEAD
>   FAIL for dwarf-2, gcc 2.95.3 and gcc 3.2-7-rh and gcc 3.2.2
> 
> Which matches your report.
> 
> I dropped coverage of gcc gcc-3_2-branch, but I might bring it back,
> because I see that people are still checking into that branch.
> 
> The real question: is there a gcc PR for this.  If there is a gcc PR,
> then I can add an XFAIL arm to the test with the gcc PR number.

Nope, there was no PR, just a patch when I noticed it.  Besides, didn't
we want to only use PRs in the GDB database?  This would be an
external/closed.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 5.3 versus gdb HEAD%200302015

[Michael Elizabeth Chastain]

> Nope, there was no PR, just a patch when I noticed it.  Besides, didn't
> we want to only use PRs in the GDB database?  This would be an
> external/closed.

Works for me.  Heck, I think I argued for that position anyways!

Unfortunately gdb_mi_test does not have a multi-armed form so
I have to use a blunt setup_kfail.

I'll go file an external/closed PR for this and then point the
test case at it.

Michael C

Re: gdb 5.3 versus gdb HEAD%200302015

[Daniel Jacobowitz]

On Mon, Feb 17, 2003 at 10:44:03AM -0600, Michael Elizabeth Chastain wrote:
> > Nope, there was no PR, just a patch when I noticed it.  Besides, didn't
> > we want to only use PRs in the GDB database?  This would be an
> > external/closed.
> 
> Works for me.  Heck, I think I argued for that position anyways!
> 
> Unfortunately gdb_mi_test does not have a multi-armed form so
> I have to use a blunt setup_kfail.
> 
> I'll go file an external/closed PR for this and then point the
> test case at it.

If you use a setup_kfail, won't it start showing up as a KPASS for all
of us with fixed GCCs?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 5.3 versus gdb HEAD%200302015

[Michael Elizabeth Chastain]

> If you use a setup_kfail, won't it start showing up as a KPASS for all
> of us with fixed GCCs?

Argh.  You are right.  I'll have to go with send_gdb/gdb_expect.
I've never done that in an MI context before.  Time to study the
mi_support.exp.

(I have an afternoon date so this is my last message until this evening).

Michael C

Re: gdb 5.3 versus gdb HEAD%200302015

[Michael Elizabeth Chastain]

> I'm curious: what shows up in gdb.log when you get FAIL here?

  print pEe->D::vg()^M
  $12 = 202^M
  (gdb) FAIL: gdb.c++/virtfunc.exp: print pEe->D::vg()

This happens with gcc 2.95.3, both dwarf-2 and stabs+.

It's a different bug than the bug you PR'd.  With gcc v3,
I get "Attempt to take address of value not located in memory."
With gcc v2, I get the wrong answer (the right answer is 102).
It looks like gdb is ignoring the 'D::' qualifier and calling
E::vg instead of D::vg.

> Certainly you should feel free to add more KFAIL branches to that test
> if you wish; just send them all to the same PR.

In this case I think it should be a different KFAIL arm
pointing to a different PR.

I will do this tonight unless you beat me to it.

Michael C

Re: gdb 5.3 versus gdb HEAD%200302015

[David Carlton]

On Mon, 17 Feb 2003 11:08:34 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

>> I'm curious: what shows up in gdb.log when you get FAIL here?
>   print pEe->D::vg()^M
>   $12 = 202^M
>   (gdb) FAIL: gdb.c++/virtfunc.exp: print pEe->D::vg()

> This happens with gcc 2.95.3, both dwarf-2 and stabs+.

> It's a different bug than the bug you PR'd.  With gcc v3,
> I get "Attempt to take address of value not located in memory."
> With gcc v2, I get the wrong answer (the right answer is 102).
> It looks like gdb is ignoring the 'D::' qualifier and calling
> E::vg instead of D::vg.

Interesting: it does indeed look like a different bug.  So:

>> Certainly you should feel free to add more KFAIL branches to that test
>> if you wish; just send them all to the same PR.

> In this case I think it should be a different KFAIL arm
> pointing to a different PR.

I guess that makes sense.

David Carlton
carlton@math.stanford.edu