From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QlM5K0YRv2ObcRQAWB0awg (envelope-from ) for ; Wed, 11 Jan 2023 14:43:02 -0500 Received: by simark.ca (Postfix, from userid 112) id A3BDB1E128; Wed, 11 Jan 2023 14:43:02 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=tANKPRcY; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 506161E0D3 for ; Wed, 11 Jan 2023 14:43:02 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E073538582A1 for ; Wed, 11 Jan 2023 19:43:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E073538582A1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1673466180; bh=goMh3WWZUOMVyrsfeJ/h6/jRYMw0PhrcvPWZKNHlUAY=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=tANKPRcYfqgaiLj6BgiibnVqatbsATOF1fQUa8aUiou87PyTxjefRoWrRHAkdz9qo C6Jex2EsY6y1w1z5unbcPJRjhxnnupXhcaNvZ5sa5IVuFA9p1cQvxexxC01fMqw511 BHFnREvgh51l27IHEkyIhZPL+E6wIz/7ewfSVoGc= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 0A7623858C83 for ; Wed, 11 Jan 2023 19:42:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A7623858C83 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 30BJgYIf029247 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jan 2023 14:42:38 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 30BJgYIf029247 Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DD1A71E0D3; Wed, 11 Jan 2023 14:42:33 -0500 (EST) Message-ID: <9280ed47-aa5d-9857-da46-f825b7be2ae2@polymtl.ca> Date: Wed, 11 Jan 2023 14:42:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] gdb: use gdb_test_multiple in gdb_breakpoint Content-Language: en-US To: Pedro Alves , Tom de Vries , gdb-patches@sourceware.org References: <20230103192216.108444-1-simon.marchi@polymtl.ca> <315f1d7a-a948-5512-fd89-a40d7a25e937@polymtl.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 11 Jan 2023 19:42:34 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > As mentioned, this is more of a generic concern of all procedures exposed > by lib/gdb.exp. gdb_breakpoint was just one among many. Seems better to look > at the overall design/direction rather than just one case in isolation. > > Let's take runto. It calls gdb_breakpoint (which used to use gdb_expect before your change), > and then gdb_run_cmd, and then gdb_expect directly. gdb_run_cmd itself uses gdb_expect. > gdb_run_cmd may use gdb_reload, which calls gdb_load, which uses gdb_load_cmd, which uses > gdb_expect. > > So changing any of these gdb_expect to gdb_test_multiple would result in intermediate PASSes > starting to be emitted. Depending on refactoring, etc, you'd get different internal PASSes. > Depending on different target, you'd get wildly different internal PASSes, etc. You'd get > a lot more mismatching PASS/FAIL cases when one of the internal gdb_test_multiple's failed. > Etc. That doesn't seem like the ideal approach to me. I don't see that as a big problem. In fact I like having fine-grained PASSes or FAILs for the various intermediate steps of the test. I think it's fine to get different PASSes on different targets, it represents what's actually being done. When debugging a test, I look at the first FAIL/UNRESOLVED. In the example you gave, if the gdb_load_cmd fails, I'd appreciate having a FAIL for that, close to the source of the problem, rather than starting from a later point and having to backtrack. Plus, the fact that I encountered a few times cases like: # Return early if do_something fails if { ![do_something] } { return } ... where do_something would not log anything. So I broke do_something, but didn't notice because nothing logged a failure. However, I can see that having different PASSes in each test can be annoying if you are diffing test results from two target boards. That will add noise in the diff. When mixing these two concerns, I guess that we arrive to the "don't tell me when it works, but tell me when it fails" that gdb_breakpoint and others have. Maybe it's good after all. Simon