From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99802 invoked by alias); 25 Mar 2019 19:43:41 -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 99786 invoked by uid 89); 25 Mar 2019 19:43:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KHOP_DYNAMIC,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 19:43:39 +0000 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2PJdCEO022441 for ; Mon, 25 Mar 2019 15:43:37 -0400 Received: from e15.ny.us.ibm.com (e15.ny.us.ibm.com [129.33.205.205]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rf3v3uys9-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 25 Mar 2019 15:43:37 -0400 Received: from localhost by e15.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 25 Mar 2019 19:43:36 -0000 Received: from b01cxnp23032.gho.pok.ibm.com (9.57.198.27) by e15.ny.us.ibm.com (146.89.104.202) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 25 Mar 2019 19:43:34 -0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x2PJhXlx17301522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Mar 2019 19:43:33 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C0644AE05C; Mon, 25 Mar 2019 19:43:33 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 92870AE05F; Mon, 25 Mar 2019 19:43:33 +0000 (GMT) Received: from pedro.localdomain (unknown [9.85.176.173]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 25 Mar 2019 19:43:33 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id 2D7AD3C04AA; Mon, 25 Mar 2019 16:43:18 -0300 (-03) From: Pedro Franco de Carvalho To: Pedro Alves , Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [PATCH] Fix testsuite hangs when gdb_test_multiple body errors out (Re: GDB 8.2.90 available for testing) In-Reply-To: References: <20190227055112.4A5E782D7B@joel.gnat.com> <8736ny7f8u.fsf@linux.vnet.ibm.com> <4d855905-32ce-ba4b-72f5-037f1796b37e@redhat.com> <87wokqd4gj.fsf@linux.vnet.ibm.com> Date: Mon, 25 Mar 2019 19:43:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 19032519-0068-0000-0000-000003AAE630 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010813; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000282; SDB=6.01179587; UDB=6.00617242; IPR=6.00960298; MB=3.00026152; MTD=3.00000008; XFM=3.00000015; UTC=2019-03-25 19:43:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19032519-0069-0000-0000-000047EF01B1 Message-Id: <8736napwo9.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00564.txt.bz2 Pedro Alves writes: > On 03/22/2019 08:44 PM, Pedro Franco de Carvalho wrote: >> Pedro Alves writes: >> >> Hello, >> >>> I spent a while trying to fix this, and I came up with the patch below. >>> >>> WDYT? >> >> Makes sense to me. >> >>> So this commit solves this by appending an "eof" with an empty >>> spawn_id list, so that it won't ever match. >> >> This is a clever solution, but just to be sure, can we actually rely on >> this behavior when the list is empty? This did work when I tested it, >> but could some Expect version conceivably do something else like >> returning an error when parsing a body with a "-i" that uses an empty >> list? > > I'd think not, but I can't predict the future so I can't be sure, > of course. > > I looked at expect's source code a little and (in my untrained eyes) > it didn't seem like there would be a reason for it not to work, > since -i's argument is just read as a list. I think a reasonable use > case would be to allow an empty variable as spawn id, so that > some patterns would be disabled depending on the variable being > empty or not (e.g., "-i $my_spawn_id_if_any"). > > When I thought of this trick, I was going to use an indirect > spawn id: > > The -i flag may also name a global variable in which case the variable > is read for a list of spawn ids. The variable is reread whenever it changes. > This provides a way of changing the I/O source while the command is in > execution. Spawn ids provided this way are called "indirect" spawn ids. > > and having that global variable be an empty list. That came to mind > since I had experience with using indirect spawn ids in another case > when I needed an empty spawn id list: > > # Use an indirect spawn id list, and remove the inferior spawn id > # from the expected output as soon as it matches, in case > # $inferior_pattern happens to be a prefix of the resulting full > # gdb pattern below (e.g., "\r\n"). > global gdb_test_stdio_spawn_id_list > set gdb_test_stdio_spawn_id_list "$inferior_spawn_id" > > And then I realized the to-the-point '-i ""' would work just as well. > > I think that if this stops working, likely either empty variable or > indirect spawn id pointing at an empty list would still keep working, > so we would likely be able to switch to one of those. Ok! Makes sense to me, thanks for the explanation. > Maybe meanwhile, we could ask on the dejagnu list what's the purpose > of this picking one of eof/timeout/default as an error block, see if > that could be removed. I'd guess that dejagnu would change faster > than expect here, or maybe I should say, less slowly. :-) I can do that if you want, and let them know about the comment tokens affecting the error block selection too. > > Thanks, > Pedro Alves Thanks for fixing this! -- Pedro Franco de Carvalho