From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1673466159; bh=goMh3WWZUOMVyrsfeJ/h6/jRYMw0PhrcvPWZKNHlUAY=; h=Date:Subject:To:References:From:In-Reply-To:From; b=iGoHApGkF5U+9ObuUqSi74AY7pYd6cybnqd/j8ccIU6xwXamh2Xt51RAy1CWVP3hQ 5LmZN8FnR8zZB4ffnZUR2Blas3gICCaazAKwItXvxsyYRXDoNhQakArGMsfnwSwXkD GjKGbEFE/JccVR2UmR7SyavCedwTQGy1s1byDuq4= 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> From: Simon Marchi 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-Spam-Status: No, score=-3032.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > 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