From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13964 invoked by alias); 20 May 2010 21:49:28 -0000 Received: (qmail 13952 invoked by uid 22791); 20 May 2010 21:49:27 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 May 2010 21:49:22 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id B9972C013; Thu, 20 May 2010 14:49:20 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost3.vmware.com (Postfix) with ESMTP id B1C9ACD903; Thu, 20 May 2010 14:49:20 -0700 (PDT) Message-ID: <4BF5AE60.1080500@vmware.com> Date: Thu, 20 May 2010 21:57:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: Re: [resubmit] gdb.base, r*.exp thru w*.exp References: <4BF59BBB.8020603@vmware.com> <20100520211446.GA8299@host0.dyn.jankratochvil.net> <4BF5ABAD.8030403@vmware.com> <20100520214614.GA11229@host0.dyn.jankratochvil.net> In-Reply-To: <20100520214614.GA11229@host0.dyn.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00455.txt.bz2 Jan Kratochvil wrote: > On Thu, 20 May 2010 23:37:49 +0200, Michael Snyder wrote: >> Jan Kratochvil wrote: >>> On Thu, 20 May 2010 22:29:47 +0200, Michael Snyder wrote: >>>> + -re ".*in main after func1.*$gdb_prompt $" { >>> Sorry for not a complete review but for this case there should be: >>> >>> -re ".*in main after func1.*\r\n$gdb_prompt $" { >>> >>> or lib/gdb.exp proc gdb_test is using: >>> >>> -re ".*in main after func1.*[\r\n]+$gdb_prompt $" { >>> >>> as just "$gdb_prompt $" is needlessly weak in practical cases causing false >>> positives. >> Thanks for the review -- but I don't follow you. >> >> What is it about this particular case that you think requires >> disambiguating? Or are you saying this in general? > > It was said in general. > > There could be for example output > > (gdb) return > Make func1 return now? (y or n) y > #0 main () at ./gdb.base/return.c:31 > 31 printf("in debugger (gdb) after func1\n"); > (gdb) > > and if expect would read(2) just the part > > (gdb) return > Make func1 return now? (y or n) y > #0 main () at ./gdb.base/return.c:31 > 31 printf("in debugger (gdb) > > before the next part of input arrives it can have a false termination of > waiting on the prompt. > > That can happens for example for "info set" where the output contains text: > prompt: Gdb's prompt is "(gdb) ". > > (In this specific testcase there is no "(gdb) " contained in the output so it > cannot have a false positive. But examining all the testcases would be > difficult. Also I understand even "\r\n(gdb) " can have a false positive on > some random output.) Well, this is a very common and ancient idiom that is used everywhere throughout the test suite. You have to assume that we don't care about anything between the ".*" and the "$gdb_prompt $". If we do, the test is wrong, but if it consumes more output than it was meant to, the following tests will fail.