From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Qd/CBHe4PmqMgRkAWB0awg (envelope-from ) for ; Fri, 26 Jun 2026 13:35:51 -0400 Received: by simark.ca (Postfix, from userid 112) id 0FB7E1E098; Fri, 26 Jun 2026 13:35:51 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id AF0DC1E024 for ; Fri, 26 Jun 2026 13:35:50 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 69B064BA2E36 for ; Fri, 26 Jun 2026 17:35:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69B064BA2E36 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by sourceware.org (Postfix) with ESMTPS id AB6454BA2E10 for ; Fri, 26 Jun 2026 17:35:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB6454BA2E10 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AB6454BA2E10 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.44 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782495324; cv=none; b=fmEZvuulNdfw6JgmWs/gk62al//LXXdGYx2GEixQtOYaaG0MohgHmwbrlqC5Mf0ffsG0z3KOG3ijBfRzZBHf51o2g/9/hdGg+r7oD5F56VrPjbWSpBT3Ub922OQ980/suAtK98RgFPzeCpoCbRMQWUCDEioViCN67WBuvYe725c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782495324; c=relaxed/simple; bh=aq8gcc1yLsRwiOsvX2rkX8qfjikbN/9B9GT5ivJFnQ0=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=w+tmnWwWi0qooHzRTHlyx+HK41a3VgZY8xFIMrXvWV5kt6KtrIvwYxpmtBmSYcBU73VN4RVKZpl6Lq6hXTnfhRjW+6ZuO+dduPEAVFG66r1aaANduEdnWM8JDg67dKIbagXyl25W1xuN4qjoV5nE73DQVSlzc8Fio2rtZBKvQDo= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AB6454BA2E10 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4922244f7c7so11183475e9.0 for ; Fri, 26 Jun 2026 10:35:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782495323; x=1783100123; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iA2Nnbb9DBJ37nKoyCvxY7+RPQkGhAEiLlDO8hW2vuE=; b=YvVRbfpAO5wztH56067hlYZJrIfTszICc1Io7+MKrfRD2ZCwB6duZxmxk6sBng25zm lOYrKZSzy0wUZ/hP8fEnRI/xBerA5S+Z+O2A/e9jN5Ag56kH6Um96IBydaLf4Ez8cLgv sXuGtj+PApvMc36sT5xxF5Z+yMP9u6KxrnX/qcmHFgzL3RqVHI0oBge2tanXBa1kX4la z68qyH/mhpmk1qNa4SLzJyqATdVpNgLDh52iGunr/RrSJgRFVSUzlzw+Qyl0Ft25YMFL 7lI+YyfXnHSMQlBAx1xAEo31gdHd2ehHkoSKJJx0yZU09WHP0iLINGKPkKUh3ZuSt7tI 7H8A== X-Forwarded-Encrypted: i=1; AFNElJ/ZCCT43zSP/N5d3f/Zxl0QpHwL+srMG8nDTeU4MlYjR5L5CG7Q0N3RZI7DUDUSnQZWm0eH4S2YKvfuTw==@sourceware.org X-Gm-Message-State: AOJu0Yy3gqbMNgK7GXhTThNZeM6l1Rz91xw/qRTmZYapq8cWINcTtjPs 9q8vzAblAKD17dAsE5zLQ1pZlJb1wWkXvy8rKpTCZ+FjFDCJME1rM0j48IYf7g== X-Gm-Gg: AfdE7clTniobOt6mbmztwJpw2swBF68mghn5CWmafbJjqjzZXhyRwuXzqXt9qbL0yxD nPTamgieUqcI0dw3dFg7RDyBidX8m6kIWKCgrEDC1UDC5PbLWX2UpHKVOvX9374p14tFBDMZbDb 1zThXqz7sdV64dIkUNtKe9QejxoM4eK3fMMbulWxRhRcCs+ZgBF+9O+Xh5LBhhpC5+CzjzXmxwC u46hJW/Av607nfD8TpX0vPBOUCBHV67BR2r9scR/GW59yqnb4rY10+t7fKzNU/eO9yC3PgAH/vG eD7hYTFqZ15kkE9WXVpztze6TdbbGuWmVyAZAPp7m5GE59C7lFZFaZfq/szSB6RfeXu0LvJ564i p4MafQ7K7sNosarWkoEcLYrOAd4pAkMCjZmDKGpwzt5F+tWRZoCAPFibZzrPfYo/vRZ6Gh/fD0U ci4G/75XK82IAmlXRaHt49ozrY2VtBMC52znZ/irj5R2imOV7q1H5tlnQ= X-Received: by 2002:a05:600c:4ecb:b0:490:d354:bcef with SMTP id 5b1f17b1804b1-4926688efe7mr110481555e9.33.1782495323107; Fri, 26 Jun 2026 10:35:23 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:2600:ad19:f1d5:63d9:ab7d? ([2001:8a0:fae3:2600:ad19:f1d5:63d9:ab7d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49268fc0f32sm94788675e9.3.2026.06.26.10.35.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jun 2026 10:35:22 -0700 (PDT) Message-ID: Date: Fri, 26 Jun 2026 18:35:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdbserver/linux-low: carry over stop_expected flag after exec (avoid spurious SIGSTOPs) To: simon.marchi@polymtl.ca, gdb-patches@sourceware.org References: <20260626143242.4033142-1-simon.marchi@polymtl.ca> From: Pedro Alves Content-Language: en-US In-Reply-To: <20260626143242.4033142-1-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.30 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 On 2026-06-26 15:32, simon.marchi@polymtl.ca wrote: > What about GDB > ============== > > I tried to check if the same bug could happen with GDB's linux-nat > target, and if the same fix was needed. linux-nat takes a different > approach when handling PTRACE_EVENT_EXEC. It wipes all lwp_infos except > the leader: > > for (lwp_info &other_lp : all_lwps_safe ()) > if (&other_lp != lp && other_lp.ptid.pid () == lp->ptid.pid ()) > exit_lwp (&other_lp); > > Here, LP is an lwp_info obtained using the event ptid of the > PTRACE_EVENT_EXEC, therefore the leader's lwp_info (even if the exec was > done by a non-leader). > > If the exec is done by the leader, as is the case with > gdb.base/vfork-follow-parent.exp, we are ok. Because GDB doesn't delete > and re-create the lwp_info, the equivalent of GDBserver's > `lwp_info::stop_expected`, `lwp_info::signalled`, survives the exec. > > If the exec is done by a non-leader, then we could be in trouble. If > the leader's signalled flag is not set, but the exec'ing non-leader's > flag is set, then we'll lose it. I suppose we could fix GDB to use > PTRACE_GETEVENTMSG to get the exec'ing thread former id, look up the > lwp_info for that id, and preserve that lwp_info. Yeah, it'd be good to fix GDB too. This sort of bug is hard to track down, and we already know we have it. > + unsigned long execing_tid = event_ptid.lwp (); > + if (ptrace (PTRACE_GETEVENTMSG, event_ptid.lwp (), (PTRACE_TYPE_ARG3) 0, > + &execing_tid) != 0) > + execing_tid = event_ptid.lwp (); This gave me pause -- this is setting execing_tid to the event lwp if ptrace fails. But execing_tid is already initialized to the event lwp. I think it'd be clearer not to initialize it, like: unsigned long execing_tid; if (ptrace (PTRACE_GETEVENTMSG, event_ptid.lwp (), (PTRACE_TYPE_ARG3) 0, &execing_tid) != 0) execing_tid = event_ptid.lwp (); Otherwise: Approved-By: Pedro Alves Thanks, Pedro Alves