Re: [RFC] GDB testsuite patch.

[Michael Chastain <mec.gnu@mindspring.com>]

Good morning Manoj,

This design is okay but the implementation needs some more work.
Here's a whole bunch of comments.  Please re-work your patch and
re-submit it.

Don't let the length of this email intimidate you.  This is mostly
procedural stuff that everybody runs into when they start working on FSF
projects.

Michael

-- Anchor the tail of the pattern.

   Your pattern says:

      -re "Reading symbols from.*no debugging symbols found.* $"

   This works as long as gdb output arrives in one big packet.
   However, sometimes the gdb output gets broken up and arrives
   in several packets.  When that happens, the ".* $" at the end
   of your pattern will succeed prematurely before all of the
   packets arrive, leaving some unmatched characters in the stream.

   So you have to write:

      -re "Reading symbols from.*no debugging symbols found.*$gdb_prompt $"

   That forces the pattern to keep scanning gdb output until it
   gets to the final "(gdb) ".

-- ChangeLog entry.  When you submit a patch, please submit a ChangeLog
   entry to go with it.  In general, the right ChangeLog file is the
   ChangeLog file nearest to the file that you are patching.  In this
   case, it's gdb/testsuite/ChangeLog.

   And you format the ChangeLog paragraph as a little block of
   text in front of the "diff", rather than including
   "diff ChangeLog" with the diff.  That's the Gnu style;
   it makes it easier to merge patches.
   
   See the gdb-patches mailing list archive for examples.

-- Test with current gdb.  I noticed your test was with gdb 6.1.
   You should at least be testing with gdb 6.2; preferably with
   the CVS version of gdb.

-- Run the whole test suite.

   A change in lib/gdb.exp affects the execution of every test script.
   It's great to show that gdb.gdb/complaints.exp improved.  But you
   also have to check that other tests didn't get broken.

   The procedure is:
   
      check out the CVS version of gdb
      run the whole test suite
      save the gdb.sum and gdb.log files
      apply your patch
      run the whole test suite again
      diff the first gdb.sum against the new gdb.sum
      if there are differences, check out what changed in gdb.log

   Unfortunately, there are about six test scripts that are unstable
   and give different results from run to run.  So you have to use
   your judgement with these, which generally means "ignore them":

      gdb.cp/annota2.exp
      gdb.cp/annota3.exp
      gdb.threads/manythreads.exp
      gdb.threads/print-threads.exp
      gdb.threads/schedlock.exp
      gdb.threads/watchthreads.exp

   If you're not sure whether a change in gdb.sum results came
   from your patch or from run-to-run instability, you can
   check the gdb-testers@ archive and see if I've mentioned that
   particular test in my results.  Or you can ask me or ask one
   of the lists.  Or you can submit the patch anyways and say
   "I saw a regression in gdb.foo/bar.exp but I'm not sure if
   my patch caused it or not".

   Getting back to the "whole test suite" ... there is at least
   one test script, gdb.base/nodebug.exp, which explicitly tests
   how gdb works when the target program has no debugging symbols.
   Your patch might interfere with that.  So you have to run the
   whole test suite before-and-after, to find any interference
   like that.

-- Last, patch submissions for gdb go to the gdb-patches@ mailing
   list, not the gdb@ mailing list.