gdb 6.0 versus gdb HEAD

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

Here's a comparison of gdb 6.0 versus gdb HEAD 2004-01-09 22:05:53 UTC.
This is with my usual native i686-pc-linux-gnu test bed.

I used to do this by comparing

  gdb 6.0 + test suite 6.0
  gdb HEAD + test suite HEAD

That is the "compare by gdb" table in my regular reports.  There are a
lot of differences in that table which are caused by differences in the
test suite, not differences in gdb.  And the test suite quality is
inversely correlated with gdb quality: a good test is something that
makes gdb look bad, like gdb1056.exp, or gdb.cp/bs15503.exp on x86_64.

So this table is:

  gdb 6.0 + test suite HEAD
  gdb HEAD + test suite HEAD

These tables still have a little fluff, such as:

  gdb.cp/maint.exp: help maint cp
    FAIL -> PASS

If the fluff gets too noisy then I can enhance test suite HEAD
to handle gdb 6.0 better.  But for now the fluff is really light,
about 5% to 10% of the total output.

Okay.  Here are the actual regressions in the test results.

  . gdb.cp/annota2.exp: annotate-quit
      PASS -> KFAIL

      Fluctuation in test result probably due to a signal handling
      race in the command loop.  This is a bug in gdb, but not a
      regression from gdb 6.0.

      http://sources.redhat.com/gdb/bugs/544
      gdb.c++/annota2.exp: annotate-quit test sometimes fails

  . gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42
      PASS -> KFAIL

      This happened with gcc 3.3.2, gcc gcc-3_3-branch, gcc HEAD with
      -gstabs+.  This is a bug in gdb or gcc.  This is a regression from
      gdb 6.0.

      http://sources.redhat.com/gdb/bugs/826
      variables in C++ namespaces have to be enclosed in quotes

      gdb 6.0 prints: $26 = yellow
      gdb HEAD prints: A syntax error in expression, near `42'.

    . gdb.threads/print-threads.exp: Hit kill breakpoint, 10 (slow with kill breakpoint)
        blank -> PASS

        Fluctuation with unknown cause.  Probably harmless.

  . gdb.threads/pthreads.exp: apply backtrace command to all three threads
      PASS -> FAIL

      This is a bug in gdb.
      This is a regression from gdb 6.0.
      This happened with all configurations tested.

      http://sources.redhat.com/gdb/bugs/1505
      [regression] gdb prints a bad backtrace for a thread

  . 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

      All tests PASSed in all configurations except for the
      "thread N ran" tests.  I don't know whether this is a bug in gdb.
      This is not a regression from gdb 6.0.

My test matrix is my usual:

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  gdb        => 6.0, HEAD
  gcc        => 2.95.3, 3.2-7-rh, 3.3.2, gcc-3_3-branch, HEAD
  as         => 2.13.90.0.2-rh, 2.14, HEAD
  ld         => 2.13.90.0.2-rh, 2.14, HEAD
  glibc      => 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2
  count         52 = 1 * 1 * 1 * 3 * (4*3+1*1) * 1 * 2 * 1