From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69986 invoked by alias); 18 Mar 2015 09:45:23 -0000 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 Received: (qmail 69976 invoked by uid 89); 18 Mar 2015 09:45:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Mar 2015 09:45:21 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2I9jITh009456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Mar 2015 05:45:18 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2I9jGIG014515; Wed, 18 Mar 2015 05:45:17 -0400 Message-ID: <5509492C.5000604@redhat.com> Date: Wed, 18 Mar 2015 09:45:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Joel Brobecker , Pierre-Marie de Rodat CC: GDB Patches Subject: Re: [PATCH] Share the "multi_line" helper among all Ada testcases References: <54FEDB92.9060808@adacore.com> <20150317200809.GD7494@adacore.com> In-Reply-To: <20150317200809.GD7494@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00538.txt.bz2 On 03/17/2015 08:08 PM, Joel Brobecker wrote: > At the time I introduced this function, I thought it should even > be in gdb.exp, but others did not agree with its usefulness, which > explains why I ended up duplicating it everywhere. Do you have a pointer? I'm curious to see the alternatives proposed. If there's something better, I'd argue for instead converting the Ada tests to use it. All I found was this though: https://sourceware.org/ml/gdb-patches/2008-01/msg00824.html which didn't sound like an objection, only a pointer to existing functions that may or not cover your use case. Note gdb_expect_list does not work for this though, as that has an implicit ".*" between elements of the expected list. Meanwhile, we grew many tests that do [join [list ... "\r\n"]], like this: # start by listing all functions gdb_test "record function-call-history /ci 1, +20" [join [list \ "1\tmain\tinst 1,1" \ "2\t fun4\tinst 2,4" \ "3\t fun1\tinst 5,8" \ "4\t fun4\tinst 9,9" \ "5\t fun2\tinst 10,12" \ "6\t fun1\tinst 13,16" \ "7\t fun2\tinst 17,18" \ "8\t fun4\tinst 19,19" \ "9\t fun3\tinst 20,22" \ "10\t fun1\tinst 23,26" \ "11\t fun3\tinst 27,27" \ "12\t fun2\tinst 28,30" \ "13\t fun1\tinst 31,34" \ "14\t fun2\tinst 35,36" \ "15\t fun3\tinst 37,38" \ "16\t fun4\tinst 39,40" \ ] "\r\n"] Your multi_line looks like almost the same, except that it's a tiny bit more lax: proc multi_line { args } { return [join $args "\[\r\n\]*"] } That will accept _no_ newline between list elements, and multiple newlines too. How about making multi_line join with strict "\r\n" too? Then if you need to match one empty line, you can do: [multi_line "line1" \ "" "line3"] and if you need multiple, you can always do: [multi_line "line1" \ "\[\r\n\]*" "lineNN"] > Let's do the following: Let's give people a week to comment on > this, and if there are no objection, let's put it in ada.exp. > If others agree that this should be in gdb.exp, then let's do that > instead, and then add some documentation in our "testcase cookbook" > wiki page about this routine. Thanks, Pedro Alves