From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39516 invoked by alias); 2 Oct 2019 17:17:08 -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 39504 invoked by uid 89); 2 Oct 2019 17:17:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1424, eyes 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 ESMTP; Wed, 02 Oct 2019 17:17:06 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B0DB3003715; Wed, 2 Oct 2019 17:17:05 +0000 (UTC) Received: from theo.uglyboxes.com (ovpn-116-199.phx2.redhat.com [10.3.116.199]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 66BBF1001B08; Wed, 2 Oct 2019 17:17:05 +0000 (UTC) Subject: Re: [PATCH] gdb/testsuite: Add gdb_test_multiple_name variable To: Andrew Burgess Cc: gdb-patches References: <20191001172850.29867-1-andrew.burgess@embecosm.com> <83e83e2a-c0f8-5721-ad76-8b842aaad390@redhat.com> <20191002130351.GC4962@embecosm.com> From: Keith Seitz Message-ID: <5118a993-d41a-0a2b-6dba-fbcff509dc7c@redhat.com> Date: Wed, 02 Oct 2019 17:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191002130351.GC4962@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00071.txt.bz2 On 10/2/19 6:03 AM, Andrew Burgess wrote: > * Keith Seitz [2019-10-01 10:41:40 -0700]: > >> Your patch looks good to me (but I am not a maintainer), but I wanted to >> ask if you considered using a stack to more robustly solve the nesting >> problem? It might be unnecessary today -- even overkill -- but I >> would think it is much easier on the eyes. > > Is your suggestion that we maintain a separate global test name stack > and push/pop the latest test name to the stack? I am not making any suggestions, no. Given > $gdb_test_multiple_name will only ever contain the inner most test message I was just curious whether you considered using a stack, whether you had any thoughts on whether we might ever want to know more than just the innermost test name. As I wrote in my original message, my intent was more to raise awareness that this /could/ be a solution to the problem -- not to recommend/require/demand any changes. > On the question of robustness, I'd be interested to know if you've > spotted a possible bug. My intention is that the TCL program stack > should serve to backup any existing value of gdb_test_multiple_name, > so there should never be a case where we have the wrong test name in > place. Nope, nothing pops to mind that this patch as-is shouldn't immediately serve. I apologize if I was unclear. Keith