From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17651 invoked by alias); 25 Aug 2004 13:44:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17638 invoked from network); 25 Aug 2004 13:44:23 -0000 Received: from unknown (HELO smtp10.atl.mindspring.net) (207.69.200.246) by sourceware.org with SMTP; 25 Aug 2004 13:44:23 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1Bzy4V-0004Nn-00; Wed, 25 Aug 2004 09:44:15 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 1ADE84B102; Wed, 25 Aug 2004 09:44:21 -0400 (EDT) Date: Wed, 25 Aug 2004 13:44:00 -0000 From: Michael Chastain To: manjo@austin.ibm.com Subject: Re: [RFC] GDB testsuite patch. Cc: gdb@sources.redhat.com Message-ID: <412C97B4.nailUU1X1SDW@mindspring.com> References: <41251A45.nail58D215HD7@mindspring.com> <4125BB8B.nailJWP1FZGHJ@mindspring.com> In-Reply-To: User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00367.txt.bz2 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.