From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id w2gPMNRFrWQr6R0AWB0awg (envelope-from ) for ; Tue, 11 Jul 2023 08:06:44 -0400 Received: by simark.ca (Postfix, from userid 112) id B9C991E0BD; Tue, 11 Jul 2023 08:06:44 -0400 (EDT) Received: from server2.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 99EDD1E00F for ; Tue, 11 Jul 2023 08:06:42 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 26F5238582BD for ; Tue, 11 Jul 2023 12:06:42 +0000 (GMT) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by sourceware.org (Postfix) with ESMTPS id 9846F3858D20 for ; Tue, 11 Jul 2023 12:06:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9846F3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-3fbea147034so56781525e9.0 for ; Tue, 11 Jul 2023 05:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689077189; x=1691669189; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=al6qb6ry4RhJ0nLrv/FLkZhKgkkINkPKpdo+LZHfteo=; b=dWnPrAjFm6C3Sx9yF/4ljkfip7KvceyxYA+Ec3obxWUB5aAC2/WiH336bJzCr+NPv6 SE1oNY1vN1YRMef682A5q17Blk5B8XxLoOsbooqgpk8EJdTm6o3olpV/H0EVcsxXEwRY eh7oQfP70WmzSFb/djW412w5l0GIfzpP0HYyCDthAQi+fOk0EPwafcHFdMaFMwE5015l QzXN1E+RMIvMdnKfUUGbwgEZvV49qF8hPgpmSGdkssCiUkSHl5PCrgitBGbrsbygkw/m Ldpi+wCK/JLmomRanMTuYfLfX7v67GIAYRaryFy2y+iCuiiSDNob+Vql/BbjERctRPFD uRkQ== X-Gm-Message-State: ABy/qLY+TkO5h0lCoXErGednIqni5ZD2rlSLpTAPakGiis/avhC4NNd0 w55DWi0W1ohm47rqaHS7jRI= X-Google-Smtp-Source: APBJJlHgsmyVsow4VdD452MiehnVn32nChe+ITOtQBnOpZQlu6GQAIY/7Qpmb2yNFhCovGdU7w+Wtg== X-Received: by 2002:a7b:cbd1:0:b0:3fb:d1c1:9b79 with SMTP id n17-20020a7bcbd1000000b003fbd1c19b79mr13373934wmi.30.1689077189276; Tue, 11 Jul 2023 05:06:29 -0700 (PDT) Received: from ?IPV6:2001:8a0:f91d:bc00:6538:516e:5056:f36a? ([2001:8a0:f91d:bc00:6538:516e:5056:f36a]) by smtp.gmail.com with ESMTPSA id v16-20020a5d6790000000b003112ab916cdsm2103280wru.73.2023.07.11.05.06.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Jul 2023 05:06:28 -0700 (PDT) Message-ID: <4118312a-d86d-57d6-6a4b-8f0eb0f38300@palves.net> Date: Tue, 11 Jul 2023 13:06:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCHv5 05/11] gdb: don't always print breakpoint location after failed condition check Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <6fd4aa13-6003-2563-5841-e80d5a55d59e@palves.net> <796e9bc1-6272-3528-93b9-f1463e6b8156@palves.net> <87mt07ju8x.fsf@redhat.com> From: Pedro Alves In-Reply-To: <87mt07ju8x.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2023-07-07 22:18, Andrew Burgess wrote: > Pedro Alves writes: > >> On 2023-07-07 16:20, Pedro Alves wrote: >>> I'd think the second *stopped shouldn't even be there at all, following the >>> logic used to remove the stop from the CLI. >>> >>> Maybe we should try moving or copying this "don't report this stop" logic to >>> fetch_inferior_event, to avoid calling the second normal_stop at all. >>> I gave it a quick try, but what I tried without thinking much about it >>> just hung GDB. I didn't dig too much as I want to move on to review the rest >>> of your series. >> >> Here's the totally broken naive patch I tried. >> >> From e1fde974fa58351de9f6dc0661162d77fc8be078 Mon Sep 17 00:00:00 2001 >> From: Pedro Alves >> Date: Fri, 7 Jul 2023 16:10:29 +0100 >> Subject: [PATCH] mi >> >> Change-Id: Ie49a36dc67b9584c40daabfffae1f87f6dd98c5c >> --- >> gdb/infrun.c | 11 +++++++---- >> 1 file changed, 7 insertions(+), 4 deletions(-) >> >> diff --git a/gdb/infrun.c b/gdb/infrun.c >> index 3dd24fccf6e..ab1fd13abe0 100644 >> --- a/gdb/infrun.c >> +++ b/gdb/infrun.c >> @@ -4395,6 +4395,8 @@ fetch_inferior_event () >> auto defer_delete_threads >> = make_scope_exit (delete_just_stopped_threads_infrun_breakpoints); >> >> + stop_context saved_context; >> + >> /* Now figure out what to do with the result of the result. */ >> handle_inferior_event (&ecs); >> >> @@ -4415,16 +4417,17 @@ fetch_inferior_event () >> } >> else >> { >> - bool should_notify_stop = true; >> bool proceeded = false; >> >> stop_all_threads_if_all_stop_mode (); >> >> clean_up_just_stopped_threads_fsms (&ecs); >> >> - if (thr != nullptr && thr->thread_fsm () != nullptr) >> - should_notify_stop >> - = thr->thread_fsm ()->should_notify_stop (); >> + bool should_notify_stop >> + = (!saved_context.changed () >> + && thr != nullptr >> + && thr->thread_fsm () != nullptr >> + && thr->thread_fsm ()->should_notify_stop ()); > > So, I got this working, as in, not locking up GDB. The problem was that > thr->thread_fsm() is often nullptr, so we end up never calling > normal_stop. > > However, I don't think this is going to work out. There's a couple of > problems. > > First, at the point fetch_inferior_event is called, there is no thread > selected, so the ptid and thread captured in saved_context are always > null_ptid and nullptr respectively. By the time we call > saved_context.changed() we do have a thread selected, so the context > appears to have always changed. Yeah. > However, I figured I could work around this be replacing the full > stop_context with a simple 'int stop_id = get_stop_id ();', I figured > this might be enough, this will tell me if GDB has notified the user of > a stop somewhere within the handle_inferior_event code. > > This works fine in the sense that I do now correctly spot that the user > has been notified of a stop and don't call normal_stop again... > > ... but as a consequence, GDB now doesn't realise that is has stopped, > and doesn't display a prompt back to the user. > > I'm going to have to leave this for the weekend now, but will continue > looking at this next week. I've included my WIP hack below. > > Would be interested on whether you see any problems with just using > get_stop_id() to determine if the user has already seen a stop or not? I don't see a problem offhand.