This is the mail archive of the gdb-testers@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]

Re: gdb 5.1.1 versus gdb gdb_5_2-branch%20020404 (native i686-pc-linux-gnu)


Summary: the 5.2 branch needs the fix for PR gdb/381.  All other
regressions are acceptable.

Now I drill down into the individual regressions.

The configurations are:

  target => qw(native)
  host   => qw(i686-pc-linux-gnu%rh-7.2)
  gdb    => qw(5.1.1 gdb_5_2-branch%20020404)

      gcc                        goption
      ---                        -------
  #0  2.95.3                    -gdwarf-2
  #1  2.95.3                    -gstabs+
  #2  2.96-rh                   -gdwarf-2
  #3  2.96-rh                   -gstabs+
  #4  3.0.4                     -gdwarf-2
  #5  3.0.4                     -gstabs+
  #6  gcc-3_1-branch%20020404   -gdwarf-2
  #7  gcc-3_1-branch%20020404   -gstabs+
  #8  gcc-HEAD%20020404         -gdwarf-2
  #9  gcc-HEAD%20020404         -gstabs+

Here is the regression section of the difference grid:

  gdb regressed

    gdb.base/ending-run.exp             -0 +1 ,2 ,3 ,4 ,5 ,6 ,7 ,8 ,9
    gdb.c++/classes.exp                 -0 +1 -2 +3 +4 +5 +6 +7 +8 +9
    gdb.c++/local.exp                   -0
    gdb.c++/method.exp                     +1       +4 +5 +6 -7 +8 -9
    gdb.c++/templates.exp               +0 +1 +2 +3 +4 +5 +6 -7 +8 -9
    gdb.mi/mi-disassemble.exp              +1                -7    -9
    gdb.mi/mi0-disassemble.exp             +1                -7    -9

The individual regressions are:



  . gdb.base/ending-run.exp: cont
    gcc 2.95.3 -gdwarf-2 : PASS -> FAIL
    [acceptable]

    Here is an excerpt from gdb.base/ending-run.c:

      7 #ifdef PROTOTYPES
      8 int callee (int x)
      9 #else
     10 int callee( x )
     11 int x;
     12 #endif
     13 {
     14     int y = x * x;
     15     return (y - 2);
     16 }
     17

    The test script puts breakpoints on line 13 and line 14 and expects
    them to be on different instructions.  Specifically, the test script
    continues from 13 and expects to land on 14.  In some configurations,
    gdb believes that line 13 and line 14 start on the same instruction,
    so the test FAILs in a subtle way (gdb actually breaks on the next
    call to "callee" and de-synchronizes).

    gdb is correctly printing "Note: breakpoint N also set at pc 0xFFFF"
    messages so users won't get hurt.

    This test worked in 5.1.1 because the test program was using
    setvbuf(), which did not actually work.  Looking past the test
    program changes, the behavior of gdb did not regress from 5.1.1 to
    gdb_5_2-branch%20020404.

    In gdb HEAD, lines 13 and 14 are on different instructions in all
    tested configurations, so the test results are all smiles.  The code
    which makes this happen causes other regressions though (pr gdb/460),
    so it would be dangerous to bring it into the branch.



  . gdb.c++/classes.exp: calling method for small class
    gcc 2.95.3 -gdwarf-2 : XFAIL -> FAIL
    [acceptable]

    gdb changed an output message in 2001-12.  The test script does not
    recognize the new message.  gdb's behavior has not regressed.

    The message has been fixed in gdb HEAD in gdb.c++/classes.exp.



  . gdb.c++/classes.exp: ptype class vB
      gcc 2.95.3  -gdwarf-2 : XFAIL -> FAIL
      gcc 2.65-rh -gdwarf-2 : XFAIL -> FAIL
    gdb.c++/classes.exp: ptype class vC
      gcc 2.95.3  -gdwarf-2 : XFAIL -> FAIL
      gcc 2.65-rh -gdwarf-2 : XFAIL -> FAIL
    gdb.c++/classes.exp: ptype class vD
      gcc 2.95.3  -gdwarf-2 : XFAIL -> FAIL
      gcc 2.65-rh -gdwarf-2 : XFAIL -> FAIL
    gdb.c++/classes.exp: ptype class vE
      gcc 2.95.3  -gdwarf-2 : XFAIL -> FAIL
      gcc 2.65-rh -gdwarf-2 : XFAIL -> FAIL
    [acceptable]

    gdb's output is kosher; gdb has no problem here.
    The test script needs work.  It's still broken in HEAD.



  . gdb.c++/local.exp: ptype InnerLocal
      gcc 2.95.3 -gdwarf-2 : PASS -> FAIL
    gdb.c++/local.exp: ptype Local
      gcc 2.95.3 -gdwarf-2 : XPASS -> XFAIL
    gdb.c++/local.exp: ptype NestedInnerLocal
      gcc 2.95.3 -gdwarf-2 : PASS -> FAIL
    [acceptable]

    Same as before.  gdb is cool, the test script is !cool.
    gdb HEAD is !cool.



  . gdb.c++/method.exp: print this (in foo)
      gcc gcc-3_1-branch%20020404 -gstabs+ : PASS -> FAIL
      gcc HEAD%20020404           -gstabs+ : PASS -> FAIL
    [acceptable]

    gdb emits a "const" that the testsuite does not understand.
    gdb is okay.  This is not a bug.  It's still present in HEAD.



  . gdb.c++/templates.exp: print Garply<Garply<char> >::garply
      gcc gcc-3_1-branch%20020404 -gstabs+ : PASS -> FAIL
      gcc HEAD%20020404           -gstabs+ : PASS -> FAIL
    [acceptable]

    More high speed "const" action.  gdb good, test script bad, test bed
    buggy.  This test showed me that I need to escape html meta characters
    in test names, like '<' and '>'.  HEAD is busted.



  . gdb.mi/disassemble.exp: data-disassemble file, line, number (zero lines) assembly mixed
      gcc gcc-3_1-branch%20020404 -gstabs+ : PASS -> FAIL
      gcc HEAD%20020404           -gstabs+ : PASS -> FAIL
    [GDB REGRESSION]

    This is the bug in pr gdb/381.  DanielJ has a nice fix in HEAD.
    I will test it for the 5.2 branch.


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