From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id L36NAurzImetMSAAWB0awg (envelope-from ) for ; Wed, 30 Oct 2024 23:05:14 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=BQp0bWLt; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D92E81E5A1; Wed, 30 Oct 2024 23:05:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 C88D91E37A for ; Wed, 30 Oct 2024 23:05:12 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A66043858D21 for ; Thu, 31 Oct 2024 03:05:11 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id D84033858D21 for ; Thu, 31 Oct 2024 03:04:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D84033858D21 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D84033858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730343888; cv=none; b=cPPg4+3jnTe9dfunPkCYOOSfWgrBNSTBAY9idic7L0ECI/To+1Dv0IN7wXJneZQHkt3+9cvw0oXabYT4nBmRQmCG/T+FocRxRz5QVNaGz7kdJN5wDf7LXR+GMnpF0r/PNPlC5Z2OG2VzcocAhYK8fGLL5N/XyoCsohPRTtLg5E0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730343888; c=relaxed/simple; bh=vplCajwT6VFaD2kTL5JMM7+OZE+YkvGH+nGK9s2YHSs=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=wfnVWr1gXalbwAMuCF4J8JNuxypiGKM/M3XlGScWJKtm8Tk3+l1yElhcEnUY6S7nVjKab/Fh2ByNaW9uhQAvrzlBKeclURUp53+vk3HriN1/JGPYFYg8bMDoj1FpFuRkPXDZOztYiZ45vPXPORVjOR3A2mVu6RoI1TReUFgDslo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730343883; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WX46N7Z/kQurdvGGH+V61NtxU0k4nrnJexfp6OFbxRY=; b=BQp0bWLtyRoTbUTI8UoIG7o6p8CGcX3NsslyUUNl0tl8UQ6hDKQtUKIJ6zyyImlOKoYL2H YP/G1XIqUZg4L2nqiOzK4pqoF3/BcIF87UTZ5JZkpm2+1jOHnk2cuFsClFLFFJVozw62Lc GXfL4TEOin3nGcAOx52BZGxFU7ZSjcM= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-449-vo27SwnnOKiW7Op8_GDBCA-1; Wed, 30 Oct 2024 23:04:41 -0400 X-MC-Unique: vo27SwnnOKiW7Op8_GDBCA-1 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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 mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 31A771955F67; Thu, 31 Oct 2024 03:04:40 +0000 (UTC) Received: from f40-zbm-amd (unknown [10.22.64.38]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 55C8D1956052; Thu, 31 Oct 2024 03:04:39 +0000 (UTC) Date: Wed, 30 Oct 2024 20:04:34 -0700 From: Kevin Buettner To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v4 1/4] Make linux checkpoints work with multiple inferiors Message-ID: <20241030200434.46738394@f40-zbm-amd> In-Reply-To: References: <20240626020148.68109-1-kevinb@redhat.com> <20240626020148.68109-2-kevinb@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII 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 Wed, 23 Oct 2024 21:10:53 +0100 Pedro Alves wrote: > 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. As you say, it was intentional, but it's easy enough to change it to always print fully-qualified ids when there are multiple inferiors. I'll make that change (and will update the test case). > 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". The current linux-fork.c code prints . In the v1 series, I had used '*' and '+' as the first character to indicate the active forks, with '*' also indicating the active inferior. You recommended that I instead use a state character "A" and dispense with the '+' indicators. Well, since we have one state character, why not another, hence "R". (It makes the output more compact.) If we change "R" to "(running)", the state character "A" seems a little odd to me; why not say "(active)" or, instead, use a compact method of indicating active forks as I did in my v1 patch. But perhaps this is needless bike-shedding. If you really want it to be "(running)", I'll change it. But do give some thought about whether the state character "A" still makes sense. > 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. I'll look into the various problems that you mention above and will also look at adding some more tests. (I'll fix the nits for the v5 series too.) Kevin