From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ApnEG2tYGWfeTxgAWB0awg (envelope-from ) for ; Wed, 23 Oct 2024 16:11:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 47B431E37C; Wed, 23 Oct 2024 16:11:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.7 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.0 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 37A721E37A for ; Wed, 23 Oct 2024 16:11:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 76AF03858C62 for ; Wed, 23 Oct 2024 20:11:21 +0000 (GMT) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by sourceware.org (Postfix) with ESMTPS id 6484C3858D21 for ; Wed, 23 Oct 2024 20:10:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6484C3858D21 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 6484C3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.221.43 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729714260; cv=none; b=gGrkWQAmHE0P1M2sZrjnCVWey8el6c31SVJtB1hyGP/EyBKPvY9zT0tU6NNFffAe6yqUIGAt984sQf5uykD65YrtXTdR+HwI64vqaO7Xc8ZfO+6Rw0q1PyEulB6flyeH7oTUO55axbcshw5o4M9bRHWApXCirQd7fw9b1P6osaI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729714260; c=relaxed/simple; bh=YteLSWjJmEW51gl4HzmRBD42+wR5RVD1LFsewlmJjT8=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=KGCBgh5ztirSpsqRttMb6ScGjMk2pYY4tjbXxvHZKfxNRBhTw+Hfi6M8VAISogSvgI1VFY5qz9uh5OQmZHzhCi7wASP1Ibm0tDmTSS2Svifj52TmuLgsuAKchkZES5Bv5PhIqu7NC4g0ZlZvDWcM4VETscOYAQaA3pAszNyYzkk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-37d55f0cf85so71924f8f.3 for ; Wed, 23 Oct 2024 13:10:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729714257; x=1730319057; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4QK1o55RepsjJPZFck5eWhAELguXhJHy4Tm4JDrMJPU=; b=ioUFdb/kVrUtI3nF9k9OEEUBKeIfTbcagFYIUgBguRKvW/M81ywEwWXenNOY4b2c56 3rLWQkmDS0LFB0LLfwhSq6L3PPDqLJ2vuII35CQ/2hT7rd4V46b3IQIhg23lHzCDEhmU 5MbQENN7PluOQi7DZtk3+3bmJQSOcIfkYO3zAa02mZcBZAQVsnwxhujEKnQUslTvqKqR XvvmGuDrLq/kk4fw2lkeWXmtDdM3hppfmHJA2S256Gl3wKRLB98J5vjCbudFirDMfKhf CIzH/iHztBAQ8+jpilXpRgk57YnBKwAzIZ9gCRNHTEDkidntTs91CxatGA1tg0w4FENO Ubug== X-Forwarded-Encrypted: i=1; AJvYcCXp6OtOg/fd8oDInUa1/kcCvUHJTGfFIXm17iDbVogP2fmslonpROrRtAyJjgNlLDg6CBKgRMVBocWkeQ==@sourceware.org X-Gm-Message-State: AOJu0YwfiPzMiTFUfbstOFFotmHS8xSIIvYPP4ADz+DFQEwfyP+xuQn4 AMSD/IkJA3UcpR3nj6V5fJ2NmlQLXoRBwvsBbUP1dEjrBmC15ye7CQGXfQ== X-Google-Smtp-Source: AGHT+IHCw4BR7GDNmrzMGoP8XS47d8Rk+eVezs2m0L0yaD4xeaI1CPwNIUbFX/7L7mB6DiriMBsscg== X-Received: by 2002:adf:ea92:0:b0:37d:4956:b0be with SMTP id ffacd0b85a97d-37efcf069b1mr2350346f8f.18.1729714256887; Wed, 23 Oct 2024 13:10:56 -0700 (PDT) Received: from ?IPV6:2001:8a0:f92f:e600:1b13:64f7:7b11:8950? ([2001:8a0:f92f:e600:1b13:64f7:7b11:8950]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37ee0a37e1asm9658171f8f.20.2024.10.23.13.10.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Oct 2024 13:10:56 -0700 (PDT) Message-ID: Date: Wed, 23 Oct 2024 21:10:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/4] Make linux checkpoints work with multiple inferiors To: Kevin Buettner , gdb-patches@sourceware.org References: <20240626020148.68109-1-kevinb@redhat.com> <20240626020148.68109-2-kevinb@redhat.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <20240626020148.68109-2-kevinb@redhat.com> 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 Hi Kevin! Trying v4 before looking at the code, I saw one behavior that surprised me. That is when you have two inferiors, and checkpoints in only one inferior. Like so: (gdb) info checkpoints No checkpoints. (gdb) checkpoint Checkpoint 1: fork returned pid 66326. (gdb) info checkpoints * 0 A process 66173 at 0x555555555258, file threads.c, line 53 1 process 66326 at 0x555555555258, file threads.c, line 53 (gdb) add-inferior [New inferior 2] Added inferior 2 on connection 1 (native) Now in the following command, I was expecting to see 1.0 and 1.1 as checkpoint numbers, since we now have two inferiors, but we only get the 0 and 1: (gdb) info checkpoints * 0 A process 66173 at 0x555555555258, file threads.c, line 53 1 process 66326 at 0x555555555258, file threads.c, line 53 If I switch to inferior 2, and then list checkpoints, I do get the fully-qualified checkpoint ids: (gdb) info inferiors Num Description Connection Executable * 1 process 66173 1 (native) /net/cascais.nfs/brno/pedro/gdb/tests/threads 2 1 (native) (gdb) inferior 2 [Switching to inferior 2 [] ()] (gdb) info checkpoints 1.0 A process 66173 at 0x55555258, file threads.c, line 53 1.1 process 66326 at 0x55555258, file threads.c, line 53 I was expecting to see the same output when inferior 1 is the one selected. Again, going back to inferior 1: (gdb) inferior 1 [Switching to inferior 1 [process 66173] (/net/cascais.nfs/brno/pedro/gdb/tests/threads)] [Switching to thread 1.1 (Thread 0x7ffff7f93740 (LWP 66173))] #0 main () at threads.c:53 53 int main() { (gdb) info checkpoints * 0 A process 66173 at 0x555555555258, file threads.c, line 53 1 process 66326 at 0x555555555258, file threads.c, line 53 (gdb) Now that I look at the code, I see that the predicate used to determine whether to show the inferior number is checking if there are multiple inferiors with checkpoints, so it seems intentional. But FYI, coming at this with a lot of context from previous discussion swapped out, I found it confusing. On the "R" state, thinking some more (since our last discussion), I wonder if we really need it. In "info threads", we show that the thread is running in the "frame" column, like: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7f8e740 (LWP 439463) "infloop" (running) ^^^^^^^^^ Maybe we should just reuse the frame-printing code from "info threads". I tried to reproduce the "R" state here locally, and saw that it's broken, for trying to fetch registers of a running thread: (gdb) start ... (gdb) checkpoint ... (gdb) info checkpoints * 0 A process 439463 at 0x7ffff7ce578a, file ../sysdeps/unix/sysv/linux/clock_nanosleep.c, line 78 1 process 439827 at 0x7ffff7ce578a, file ../sysdeps/unix/sysv/linux/clock_nanosleep.c, line 78 (gdb) c& Continuing. (gdb) info checkpoints * 0 AR process 439463 at Couldn't get registers: No such process. BTW, the documentation patch says that you can only see the "R" state in non-stop mode: +one which @value{GDBN} is currently debugging. @code{R} indicates a +running process; this status letter can only appear when @value{GDBN} +is running in non-stop mode. But that's not correct. You can also use the "c&" command in all-stop mode. I noticed this because I wanted to try what it say here: If neither @code{A} or @code{R} are present, +this indicates a checkpoint which can be switched to using the +@code{restart} command or deleted using the @code{delete checkpoint} +command. ... specifically, I wanted to try switching to a checkpoint in the "R" state, check that GDB behaves properly. Other than the issues above, this all LGTM. Some trivial typos pointed out below. Pedro Alves On 2024-06-26 02:55, Kevin Buettner wrote: > The functions 'find_fork_ptid' and 'find_fork_pid' used to return a > pointer to a fork_info struct. They now return a pair consisting of > the pointer to a fork_info struct in addition to a pointer to the > inferior containing that checkpoint. > > 'find_fork_id' returns a a pointer to a fork_info struct just as Typo, double "a a". > it did before, but it's now gained a new parameter, 'inf', which > is the inferior in which to look. > > info_checkpoints_command used to simply iterate over the list of > forks (checkpoints), printing each one out. It now needs to iterate > over all inferiors and, for those which have checkpoints, it needs > to iterate over the list of checkpoints in that inferior. As noted > earlier, the format of the output has been changed so that checkpoint > identifers incorporating an inferior number may be printed. identifers -> identifiers > > linux_fork_context, called by restart_command, now contains code to > switch inferiors when the fork being restarted is in an inferior which > is different from the current one. The scoped_switch_fork_info class > now also contains code for switching inferiors in both the constructor > and destructor. >