From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24340 invoked by alias); 9 Jun 2008 19:12:21 -0000 Received: (qmail 24331 invoked by uid 22791); 9 Jun 2008 19:12:20 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jun 2008 19:12:03 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m59JC1oj006262 for ; Mon, 9 Jun 2008 15:12:01 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m59JC0ji023026; Mon, 9 Jun 2008 15:12:00 -0400 Received: from opsy.redhat.com (vpn-10-41.bos.redhat.com [10.16.10.41]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m59JBxsh030152; Mon, 9 Jun 2008 15:12:00 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 2879337814F; Mon, 9 Jun 2008 13:11:59 -0600 (MDT) To: gdb-patches@sources.redhat.com Subject: Re: RFA: fix two field name completion bugs References: <20080609184545.GB1378@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Mon, 09 Jun 2008 19:26:00 -0000 In-Reply-To: <20080609184545.GB1378@caradoc.them.org> (Daniel Jacobowitz's message of "Mon\, 9 Jun 2008 14\:45\:45 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2008-06/txt/msg00171.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: >> +send_gdb "p values\[0\] . a\t" >> +sleep 3 >> +gdb_expect { Daniel> I know there's other tests in completion.exp that do this but are the Daniel> sleeps really necessary? Anywhere that we sleep, the testsuite Daniel> becomes timing sensitive - not to mention slow. I just copied and pasted this code. FWIW completion.exp seems ripe for refactoring into some procs ... but I don't plan to do that. I looked at cvs annotate but it did not tell me much. Many of the sleeps in this file date to the initial revision. I removed the new sleeps here, and it still worked. This doesn't tell us anything directly -- it could still fail on a slower machine. But if nobody complains after a while I suppose we can assume it was ok :) I can commit that version if you prefer. Just let me know. I've appended the new completion.exp patch. Tom Index: testsuite/gdb.base/completion.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/completion.exp,v retrieving revision 1.30 diff -u -r1.30 completion.exp --- testsuite/gdb.base/completion.exp 6 Jun 2008 20:58:08 -0000 1.30 +++ testsuite/gdb.base/completion.exp 9 Jun 2008 19:11:42 -0000 @@ -654,6 +654,36 @@ timeout { fail "(timeout) complete 'p values\[0\].a' 2" } } +send_gdb "p values\[0\] . a\t" +gdb_expect { + -re "^p values.0. . a_field $"\ + { send_gdb "\n" + gdb_expect { + -re "^.* = 0.*$gdb_prompt $"\ + { pass "complete 'p values\[0\] . a'"} + -re ".*$gdb_prompt $" { fail "complete 'p values\[0\] . a'"} + timeout {fail "(timeout) complete 'p values\[0\] . a'"} + } + } + -re ".*$gdb_prompt $" { fail "complete 'p values\[0\] . a'" } + timeout { fail "(timeout) complete 'p values\[0\] . a' 2" } + } + +send_gdb "p &values\[0\] -> a\t" +gdb_expect { + -re "^p &values.0. -> a_field $"\ + { send_gdb "\n" + gdb_expect { + -re "^.* = .*0x\[0-9a-fA-F\]*.*$gdb_prompt $"\ + { pass "complete 'p &values\[0\] -> a'"} + -re ".*$gdb_prompt $" { fail "complete 'p &values\[0\] -> a'"} + timeout {fail "(timeout) complete 'p &values\[0\] -> a'"} + } + } + -re ".*$gdb_prompt $" { fail "complete 'p &values\[0\] -> a'" } + timeout { fail "(timeout) complete 'p &values\[0\] -> a' 2" } + } + # The following tests used to simply try to complete `${objdir}/file', # and so on. The problem is that ${objdir} can be very long; the # completed filename may be more than eighty characters wide. When