From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FAgwHJHdFGWB5x4AWB0awg (envelope-from ) for ; Wed, 27 Sep 2023 21:57:37 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=n7Mw2v8D; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 69A001E0C3; Wed, 27 Sep 2023 21:57:37 -0400 (EDT) Received: from server2.sourceware.org (ip-8-43-85-97.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 57A721E028 for ; Wed, 27 Sep 2023 21:57:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8CADA3857701 for ; Thu, 28 Sep 2023 01:57:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8CADA3857701 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1695866254; bh=bD2ndlGuxMjISBZKpOhjZe8yxaeo4dy6qgeOyHb5Eo4=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=n7Mw2v8DcugZDdrBV+EAHpp2rF+C9q8NjT4I7n/pOoWi84cq1xbtCUmEZzKKwnvRQ qcufy+djZA0/9aVHfVZb/HA1Ulavgw/kcmMUuIMsr/w9KKnbw1PgDw3u4PNrDOIOqT hMt4DYknmNaow1d8mXUX7gVQE7Hmv0vfDDprnvsg= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 019A73858C00 for ; Thu, 28 Sep 2023 01:57:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 019A73858C00 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-613-5EVoOnbaNMyBOuyg6cH2Qw-1; Wed, 27 Sep 2023 21:57:12 -0400 X-MC-Unique: 5EVoOnbaNMyBOuyg6cH2Qw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E60658002B2 for ; Thu, 28 Sep 2023 01:57:11 +0000 (UTC) Received: from f37-zws-nv (unknown [10.22.32.95]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E82040C2064; Thu, 28 Sep 2023 01:57:11 +0000 (UTC) Date: Wed, 27 Sep 2023 18:57:10 -0700 To: Kevin Buettner via Gdb-patches Cc: Guinevere Larsen Subject: Re: [PATCH v3 1/2] gdb/record: print frame information when exiting a recursive call Message-ID: <20230927185710.3475c282@f37-zws-nv> In-Reply-To: <20230927162231.5d301671@f37-zws-nv> References: <20230927101950.1913970-3-blarsen@redhat.com> <20230927101950.1913970-4-blarsen@redhat.com> <20230927142619.04ca311d@f37-zws-nv> <20230927162231.5d301671@f37-zws-nv> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham 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: , From: Kevin Buettner via Gdb-patches Reply-To: Kevin Buettner Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Wed, 27 Sep 2023 16:22:31 -0700 Kevin Buettner wrote: > I'll now do some actual debugging, comparing what happens with and > without Gwen's patch... I think I understand what's going on now. This part of the patch... diff --git a/gdb/infrun.c b/gdb/infrun.c index 4730d290442..3491327422d 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -6923,6 +6923,11 @@ process_event_stop_test (struct execution_control_state *ecs) frame = get_current_frame (); gdbarch = get_frame_arch (frame); + /* Shorthand to make if statements smaller. */ + struct frame_id original_frame_id + = ecs->event_thread->control.step_frame_id; + struct frame_id curr_frame_id = get_frame_id (get_current_frame ()); + switch (what.main_action) { case BPSTAT_WHAT_SET_LONGJMP_RESUME: ...is causing get_frame_id() to be called in situations where it might not have been called before. For the test case in question, it's causing glibc's symbols to be loaded - they weren't before. If the new code is either removed or moved to a location later in the function, then glibc's symbols aren't loaded. Is this a problem? For most (almost all?) debugging scenarios, this will merely cause some symbols to be loaded somewhat earlier in the debugging session than they would have been otherwise. Therefore, I don't think it's a problem. However, if someone has a different point of view, I'd like to hear it... How should we fix the regresssion? The problematic command in gdb.dwarf2/dw2-out-of-range-end-of-seq.exp is: maint info line-table main.c$ The 'main.c$' part of it is actually a regular expression. Due to the fact that glibc has been loaded earlier than it had been in the past, this RE is matching main.c, which is what we want, but also textdomain.c and support_test_main.c, which we don't. These latter two files are from glibc. The relevant lines from the log file are as follows: (gdb) maint info line-table main.c$ objfile: /mesquite2/sourceware-git/f38-review/bld/gdb/testsuite/outputs/gdb.dwarf2/dw2-out-of-range-end-of-seq/dw2-out-of-range-end-of-seq ((struct objfile *) 0x2273d50) compunit_symtab: main.c ((struct compunit_symtab *) 0x2267b80) symtab: /mesquite2/sourceware-git/worktree-review/gdb/testsuite/gdb.dwarf2/main.c ((struct symtab *) 0x2267c00) linetable: ((struct linetable *) 0x2267e20): INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END 0 1 0x0000000000401106 0x0000000000401106 Y 1 END 0x0000000000401111 0x0000000000401111 Y objfile: /usr/lib/debug/usr/lib64/libc.so.6-2.37-5.fc38.x86_64.debug ((struct objfile *) 0x23eecc0) compunit_symtab: ((struct compunit_symtab *) 0x2c47a50) symtab: /usr/src/debug/glibc-2.37-5.fc38.x86_64/intl/textdomain.c ((struct symtab *) 0x2c71530) linetable: ((struct linetable *) 0x0): No line table. objfile: /usr/lib/debug/usr/lib64/libc.so.6-2.37-5.fc38.x86_64.debug ((struct objfile *) 0x23eecc0) compunit_symtab: ((struct compunit_symtab *) 0x2c47a50) symtab: /usr/src/debug/glibc-2.37-5.fc38.x86_64/support/support_test_main.c ((struct symtab *) 0x2c87410) linetable: ((struct linetable *) 0x0): No line table. If the command is changed to "maint info line-table \bmain.c$", the word boundary anchor \b will cause only main.c to be matched. (Ideally, the . would also be escaped with '\' so that it would only match a literal . (period) and not any character.) Kevin