From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 0730538930D7 for ; Wed, 17 Jun 2020 14:19:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0730538930D7 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-285-7QuMNXPEMOKJUFB17aGl-w-1; Wed, 17 Jun 2020 10:19:15 -0400 X-MC-Unique: 7QuMNXPEMOKJUFB17aGl-w-1 Received: by mail-wr1-f72.google.com with SMTP id r5so1244143wrt.9 for ; Wed, 17 Jun 2020 07:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VkLgjufwEZGLTopfHQZUDVmA5Tk+dajfa06Rbk2zaeY=; b=cNtBIablBuiOYT+Xm5qhFkITLsPoDQBH3jeuYK7NlVCJubUBmxxJJBKdragy7eaihs 68IxtPWRavAQ18SQuWkq2LQThrQP0/3PAzYlTMtQyeO8jDU/w/r9dYA4kx+Gt9nM0kdB o1LDI+tE82/EXMW0OztuWE8UbZyBbm1IoRp8UHv4HltyMVicKdrhUNLtztW5VbY6NI5R HCECNJzX5n9K/h8ZYIbr3k2HJqvmEJRm7HEmliSGyqQFaOSKE3DBkcgNaYgRc4z7bbUb 1rXUvOQyUJIjeTsnE1SiZci6DPzffCsPDsShjFzJWdPy+vOE+3V2byb165dpJdpUU9Ms QElg== X-Gm-Message-State: AOAM5303NtnTWP7OdLujDTpO685yJteuaxZX7nljrxxEsS53KTgST+dR 2MEqX6ipbO7S65vU7KW1VkMlsR3THPQ1XK4pMb1ktAdW74N2RPiGR5YH9rkzvTAmkskV98S4SEz savJBdo5DCLF65WT3FuAIDQ== X-Received: by 2002:adf:ea8b:: with SMTP id s11mr8901975wrm.168.1592403553821; Wed, 17 Jun 2020 07:19:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMRf5DVH2pXKNzRgkG4kkvosW8IR16XRWoX6F3j7n60qlcGnGs+/CLg1APvKBDz40VzJdLkg== X-Received: by 2002:adf:ea8b:: with SMTP id s11mr8901959wrm.168.1592403553630; Wed, 17 Jun 2020 07:19:13 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id z8sm33189187wru.33.2020.06.17.07.19.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jun 2020 07:19:12 -0700 (PDT) Subject: Re: [PATCH][gdb/testsuite] Don't abort testrun for invalid command in test-case To: Tom de Vries , gdb-patches@sourceware.org References: <20200611143522.GA19667@delia> <7d7ce523-b58c-a77d-15be-8091feb6389a@redhat.com> <18e36963-4f04-f871-33fb-89a5d1683bbd@suse.de> <31b0b6f2-4930-f339-0245-3a328d0d2548@redhat.com> <80251b07-73db-1ca0-7ab6-67285cb6b1d7@suse.de> From: Pedro Alves Message-ID: <605f6d30-4e18-cebc-517c-5a070e477823@redhat.com> Date: Wed, 17 Jun 2020 15:19:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <80251b07-73db-1ca0-7ab6-67285cb6b1d7@suse.de> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 14:19:18 -0000 On 6/17/20 3:14 PM, Tom de Vries wrote: > On 6/16/20 2:47 PM, Pedro Alves wrote: >> On 6/11/20 11:55 PM, Tom de Vries wrote: >> >>> Hmm, what is the distinction between gdb_init and default_gdb_init? >>> >>> All the other uses in gdb.exp of pattern foo/default_foo have an >>> implementation: >>> ... >>> proc foo {} { >>> [default_foo] >>> } >>> ... >>> but gdb_init is much more than that. Why is that different? >>> >> >> I don't know. I guess it shouldn't. I guess people (including me) added to >> gdb_init over time without realizing they were breaking the pattern. Maybe nobody >> notices it because whatever is overriding gdb_init renames the original one and >> then calls it. > > Hmm, thanks for the explanation. I feel we need to improve this > situation somehow, but I'm not sure yet how. Move stuff in gdb_init to default_gdb_init, and add a comment to these functions to not add stuff in there? That seems like the obvious. I'm not sure why we have that pattern in the first place though, given that you can rename/override functions in tcl anyhow. This all predates me. Thanks, Pedro Alves