From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id p44NFQ2pa2M5rBUAWB0awg (envelope-from ) for ; Wed, 09 Nov 2022 08:20:13 -0500 Received: by simark.ca (Postfix, from userid 112) id 42CB01E124; Wed, 9 Nov 2022 08:20:13 -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=epi0Gqf6; 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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 D64831E11E for ; Wed, 9 Nov 2022 08:20:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1977A3858D20 for ; Wed, 9 Nov 2022 13:20:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1977A3858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668000011; bh=5G26+hsx4q0WFdFc+cfksYr5SUOui3kqAVtQWzH5f1I=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=epi0Gqf6NjBPR/aJ7y/GpMcGoFwj40Vp8O8PabeTmkaES2B5tP8X9tHzTq4bt0V5b ohP+moRsCAli0a9Yw5aKwC1dQc8LcoHFK+BSYUUXyndZqpBobVAj+YAPzyNvZJ7rre GW2FefV1gk0C8axjs5RWMs8zR5ttoQZfFiZiURDU= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id EF2C93858D33 for ; Wed, 9 Nov 2022 13:19:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF2C93858D33 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 3E8D31E11E; Wed, 9 Nov 2022 08:19:52 -0500 (EST) Message-ID: <30ac3679-d16d-3706-a026-d17ba962f096@simark.ca> Date: Wed, 9 Nov 2022 08:19:51 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] gdb: make "start" breakpoint inferior-specific Content-Language: en-US To: Andrew Burgess Cc: Simon Marchi , gdb-patches@sourceware.org References: <20220804174035.2441960-1-simon.marchi@efficios.com> <87ler3cr4x.fsf@redhat.com> <8735asb7cj.fsf@redhat.com> In-Reply-To: <8735asb7cj.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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" On 11/9/22 08:11, Andrew Burgess wrote: > Simon Marchi writes: > >>> >>> In general I'm happy enough with the actual GDB change you propose here, >>> but like Bruno, I also wondered if it would be better to add inferior >>> specific breakpoints as an actual thing, rather than relying on the >>> condition logic like you do here? >>> >>> I wasn't sure how you'd feel about this idea, so I didn't spend too >>> long, but below is a VERY rough proof of concept patch, that appies on >>> top of yours, that adds inferior specific breakpoints. You temporary >>> breakpoint now becomes: >>> >>> tbreak -qualified main inferior 1 >>> >>> But this functionality would also be available to a user if they wanted >>> it, which might be nice. >> >> I think it's a good idea, but I would prefer if that wasn't a >> prerequesite for this patch, since adding this feature can become >> somewhat of a rabbit hole. Functionally, a condition will essentially >> behave the same, I think it's robust, and I would like to get rid of the >> flakiness in the testsuite sooner than later :). > > That's fine - I assume you would be happy if you code was updated to > make use of inferior specific breakpoints if such a feature appeared in > the future? (re-adding gdb-patches, not sure where it got removed, maybe I messed up my initial reply) Absolutely, I would be fine. What matters is that the user-visible behavior works. Simon