From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120491 invoked by alias); 25 Mar 2019 13:21:40 -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 120482 invoked by uid 89); 25 Mar 2019 13:21:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=trick, franco, Franco, is X-HELO: mail-wm1-f67.google.com Received: from mail-wm1-f67.google.com (HELO mail-wm1-f67.google.com) (209.85.128.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 13:21:38 +0000 Received: by mail-wm1-f67.google.com with SMTP id y197so9073363wmd.0 for ; Mon, 25 Mar 2019 06:21:38 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id o17sm17278138wrw.73.2019.03.25.06.21.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 06:21:35 -0700 (PDT) Subject: Re: [PATCH] Fix testsuite hangs when gdb_test_multiple body errors out (Re: GDB 8.2.90 available for testing) To: Pedro Franco de Carvalho , Joel Brobecker , gdb-patches@sourceware.org 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> From: Pedro Alves Message-ID: Date: Mon, 25 Mar 2019 13:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87wokqd4gj.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00534.txt.bz2 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. 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. :-) Thanks, Pedro Alves