From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6NxaJtLxRWKeEwAAWB0awg (envelope-from ) for ; Thu, 31 Mar 2022 14:24:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 9B2DC1F163; Thu, 31 Mar 2022 14:24:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 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 4208F1ED17 for ; Thu, 31 Mar 2022 14:24:18 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 05E823839816 for ; Thu, 31 Mar 2022 18:24:18 +0000 (GMT) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by sourceware.org (Postfix) with ESMTPS id DF8CD3838030 for ; Thu, 31 Mar 2022 18:22:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF8CD3838030 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-f48.google.com with SMTP id f6-20020a1c3806000000b0038e4a0fc5easo139020wma.3 for ; Thu, 31 Mar 2022 11:22:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=qEDwgC8m/ISqgApIucCG5SoZSadtTi0albXXPPalGqQ=; b=Ul5a5xufQBMEQxOK+XcQLDCszX2GNg52/H8p/0fGgXn0XJCuEQb+ROqhA1HcIcuPhC eWQCBNavKmWsYIATXWquibVyM1fK+waHUFQjqIMw9Lmov49Dx1lwfnQlxDw5ldMDNOeY 3Z4FF3Vb5yEin81vhDEOXffaCR49Qx1IRIUn/ZbfID9/Y8yRtb8/Mmpkj0BOOrTf6INf w4HwIX7FDxfgbxdM0reLqxW/ucUThFdtGwrrXBhABL3fNW1a/gED1dY/PypnBVQ49r7x DnVVRxeHglFeiflKudFIn1P/mfT5z8RcmxYB4tmBqBT9SA47ICvo6juhNyNDeKgYxt3r YZKw== X-Gm-Message-State: AOAM532KiKi+vZXK0U08sv1pakw6wZD6dseyCPSFq4le86N2sajrfjoM TzmySIxF90lBTxDc2omu3Qw= X-Google-Smtp-Source: ABdhPJy2zdFu3D6RrwYhh2KftjErSHtMpwEbMgAUTdSj1ntPy4eqrE6WBSZAh5wEff8zTRNYVHQrrQ== X-Received: by 2002:a05:600c:3ca7:b0:38e:50d2:27fe with SMTP id bg39-20020a05600c3ca700b0038e50d227femr1172091wmb.159.1648750974998; Thu, 31 Mar 2022 11:22:54 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id v18-20020adfc5d2000000b0020589b76704sm147458wrg.70.2022.03.31.11.22.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 11:22:54 -0700 (PDT) Message-ID: <7c2c3635-3b05-e3f8-05a3-c15bd6771a5c@palves.net> Date: Thu, 31 Mar 2022 19:22:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 8/8] gdb: resume ongoing step after handling fork or vfork Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20220117162742.524350-1-simon.marchi@polymtl.ca> <20220117162742.524350-9-simon.marchi@polymtl.ca> From: Pedro Alves In-Reply-To: <20220117162742.524350-9-simon.marchi@polymtl.ca> 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: , Cc: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-01-17 16:27, Simon Marchi via Gdb-patches wrote: > From: Simon Marchi > > The test introduced by this patch would fail in this configuration, with > the native-gdbserver or native-extended-gdbserver boards: > > FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=2: next to for loop > > The problem is that the step operation is forgotten when handling the > fork/vfork. With "debug infrun" and "debug remote", it looks like this > (some lines omitted for brevity). We do the next: > > [infrun] proceed: enter > [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT > [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154304.0] at 0x5555555553bf > [infrun] do_target_resume: resume_ptid=4154304.0.0, step=1, sig=GDB_SIGNAL_0 > [remote] Sending packet: $vCont;r5555555553bf,5555555553c4:p3f63c0.3f63c0;c:p3f63c0.-1#cd > [infrun] proceed: exit > > We then handle a fork event: > > [infrun] fetch_inferior_event: enter > [remote] wait: enter > [remote] Packet received: T05fork:p3f63ee.3f63ee;06:0100000000000000;07:b08e59f6ff7f0000;10:bf60e8f7ff7f0000;thread:p3f63c0.3f63c6;core:17; > [remote] wait: exit > [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = > [infrun] print_target_wait_results: 4154304.4154310.0 [Thread 4154304.4154310], > [infrun] print_target_wait_results: status->kind = FORKED, child_ptid = 4154350.4154350.0 > [infrun] handle_inferior_event: status->kind = FORKED, child_ptid = 4154350.4154350.0 > [remote] Sending packet: $D;3f63ee#4b > [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154310.0] at 0x7ffff7e860bf > [infrun] do_target_resume: resume_ptid=4154304.0.0, step=0, sig=GDB_SIGNAL_0 > [remote] Sending packet: $vCont;c:p3f63c0.-1#73 > [infrun] fetch_inferior_event: exit > > In the first snippet, we resume the stepping thread with the range-stepping (r) > vCont command. But after handling the fork (detaching the fork child), we > resumed the whole process freely. The stepping thread, which was paused by > GDBserver while reporting the fork event, was therefore resumed freely, instead > of confined to the addresses of the stepped line. Note that since this > is a "next", it could be that we have entered a function, installed a > step-resume breakpoint, and it's ok to continue freely the stepping > thread, but that's not the case here. The two snippets shown above were > next to each other in the logs. > > For the fork case, we can resume stepping right after handling the > event. > > However, for the vfork case, where we are waiting for the > external child process to exec or exit, we only resume the thread that > called vfork, and keep the others stopped (see patch "gdb: fix handling of > vfork by multi-threaded program" prior in this series). So we can't > resume the stepping thread right now. Instead, do it after handling the > vfork-done event. Also OK. Thanks for doing all this.