From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id lg5gFeLJK2Zr7jwAWB0awg (envelope-from ) for ; Fri, 26 Apr 2024 11:36:02 -0400 Received: by simark.ca (Postfix, from userid 112) id 471C81E0C1; Fri, 26 Apr 2024 11:36:02 -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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2A1B71E092 for ; Fri, 26 Apr 2024 11:36:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 413CE384AB5C for ; Fri, 26 Apr 2024 15:35:59 +0000 (GMT) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by sourceware.org (Postfix) with ESMTPS id 8B4A43858C42 for ; Fri, 26 Apr 2024 15:35:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B4A43858C42 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 8B4A43858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.221.42 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714145742; cv=none; b=ToY8iEWPO+00tTSGsg1dqIzSZ93+27t/14s7aGI2NJooG0Az7FQI7vBQ62DdDxZ13ESQaBi7tvenJm5dPLAIlrXDdVLdWNcjBUTL09Kezi+Dnwv065scqfRXd4OeAlqxBmBLTqoeFXjWiIVMYs7wkdtasxZoEK1W8h8+LUfVKuI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714145742; c=relaxed/simple; bh=gSD79Q3pkLnNIniwNlRM/lPCBI1QSKeXAz0Yc0SNZ4E=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=r6wJG0kv13aULVQgGPm6UAPhSSVpJHW+Rf+KVhJc6DHz6RHo9OJ569dXdLYjDCr1zvIrOdm5tZEftkQsi65r0yJvJB2tyRfPPNXIwA8wwpD87E9zNYu55aRi76ym70eTL2KVJlrc83oFf6/Ag4tRyZiGFRFuhmPcKZRAOOTBsIs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-34b1e35155aso2439053f8f.3 for ; Fri, 26 Apr 2024 08:35:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714145739; x=1714750539; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=obJk2b6kzZTTv3YlfYOw5shpY6QrgeVSFkF7tWA9ExI=; b=Ja9pnkubI1ZHmuClQ6Ljou03Q+KMkHqQBtGPz/nBprq+KZbBCD28n4IKXDBUY4NHFS Bv/Aw2qZP/Os4o/WiPDaUw1rETpEoCuF6EU5f011EmLWJsADTw3VLQV8NNcJhTaJcDtP ajKvwzTuFFGJ/VCiniMTtIBvuJiG5dkZceRBq4NxQBTXOHkMqgQuZ5rdkq/IGclsFiW7 xFkPcjjtZPm8YjIhrcmuZ/2sUiBCx9O0Q3vh7AZ5tFSNARWvLZvak6qRhBMmHaLt2o/P EIEcp5bUxv4DjCyU9uqaXK6CwjH8skqxicJX7028Hn4hR0YJVF+RKOWmHXTZVmOB0KMS I1Cw== X-Gm-Message-State: AOJu0Ywj6xlyWSlCSL+J9lTCrAYp8GOeEZGMy/COBKVC0u1UhVsCGcQ3 SrAyJo21aZ+zVSanb9g/BLHOQlHqgHBONRk5UgtH+6kBQHK39wMK X-Google-Smtp-Source: AGHT+IFVR1rmx7sgWxxfcFJRggagEwx47q6pqWxNcn6rer0ZB+Sn0LGB0590SB13vGfs7S3eTUiBrQ== X-Received: by 2002:a5d:6c61:0:b0:34b:1053:3b93 with SMTP id r1-20020a5d6c61000000b0034b10533b93mr3498630wrz.21.1714145739020; Fri, 26 Apr 2024 08:35:39 -0700 (PDT) Received: from ?IPV6:2001:8a0:f93d:b900:eefb:5e83:838f:bb4c? ([2001:8a0:f93d:b900:eefb:5e83:838f:bb4c]) by smtp.gmail.com with ESMTPSA id u17-20020adfeb51000000b00347321735a6sm22624722wrn.66.2024.04.26.08.35.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Apr 2024 08:35:38 -0700 (PDT) Message-ID: Date: Fri, 26 Apr 2024 16:35:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 3/3] gdb/nat/linux: Fix attaching to process when it has zombie threads To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org References: <20240321231149.519549-1-thiago.bauermann@linaro.org> <20240321231149.519549-4-thiago.bauermann@linaro.org> <87msptgbey.fsf@linaro.org> <9680e3cf-b8ad-4329-a51c-2aafb98d9476@palves.net> <87jzksk4qw.fsf@linaro.org> From: Pedro Alves Content-Language: en-US In-Reply-To: <87jzksk4qw.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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.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 Hi! Going back to give some closure to this subthread... On 2024-04-20 06:00, Thiago Jung Bauermann wrote: > > Pedro Alves writes: >> The only way that I know of today that we can make the kernel pause all threads for >> us, is with a group-stop. I.e., pass a SIGSTOP to the inferior, and the kernel stops >> _all_ threads with SIGSTOP. >> >> I prototyped it today, and while far from perfect (would need to handle a corner >> scenarios like attaching and getting back something != SIGSTOP, and I still see >> some spurious SIGSTOPs), it kind of works ... > > This is amazing. Thank you for this exploration and the patch. > >> ... except for what I think is a deal breaker that I don't know how to work around: >> >> If you attach to a process that is running on a shell, you will see that the group-stop >> makes it go to the background. GDB resumes the process, but it won't go back to the >> foreground without an explicit "fg" in the shell... Like: >> >> $ ./test_program >> [1]+ Stopped ./test_program >> $ > > Couldn't this be a shell behaviour rather than a kernel one? I don't see > anything that I could associate with this effect mentioned in the ptrace > man page (though I could have easily missed it). If it is, then the fix > would be in the shell too. I don't see how a shell could behave differently. A shell will be waiting for its children with waitpid WUNTRACED, which makes it see the job stop and report it to the user. A subsequent PTRACE_CONTINUE just leaves the child running in the background. Ideally we would want something like group-stop that doesn't actually cause a job stop in the first place. Pedro Alves