From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5n4uHA23umkD9C4AWB0awg (envelope-from ) for ; Wed, 18 Mar 2026 10:30:37 -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=g4IqFk3Z; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 611261E0BC; Wed, 18 Mar 2026 10:30:37 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 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_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 C2E291E08C for ; Wed, 18 Mar 2026 10:30:35 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 33EEB4B920B2 for ; Wed, 18 Mar 2026 14:30:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 33EEB4B920B2 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=g4IqFk3Z 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 0360C4BCA435 for ; Wed, 18 Mar 2026 14:29:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0360C4BCA435 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine 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 0360C4BCA435 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=1773844200; cv=none; b=FzoYucBABnBJvFtGN8CEikX/hjuG/2p3+oXOf0RL0iSpwS+/4qrbAdlymSJa6yDsVb06q1E4ufhfbtub1whbkVnZVLflpjkRbCfKw2orR28QN3Uks7HXDroPKukTAf8eOUH19RAsv2kfzHF7uLMeaGpiBe4vbkswPG+qi7m664o= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773844200; c=relaxed/simple; bh=/sv8NYE7gk+XmzChQNyBjd6WJ2omW+laPxg8TYQ3A2c=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xb8QTr8RUnmFqQJ7IXubdQcJdf07IFomBWS42KEAITZvPn1mIroBRaFrnJZemah7FjFRIVF99SMrHW3SA9TozcEGj/9TWvW3ltwiMaYu5TsNJRX9r7MyaoIVFFRjjPNzUTHphnUxIWh4WGP5lIaNWafULWJl4zQ0lwzdTnlZJjw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0360C4BCA435 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773844199; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mctQ9Nq15ZBnvh3CdyMq77ctH2Ta5FbU1NlrSoGobXU=; b=g4IqFk3Zv0+zhrfaFpw30Ij9o5HTVJJKEt7syvCnblyFwT7nGALxrdpop8hqyfB5hpuYNN kphKCmU1219kilNsG1F4pHZtpMECXxH3UuK/W+PwoEY3riLdRvMm5wUDmijJHyv5Ms3RSm RAbwYV/yJHVzOomZmT6j6PK2iNo+zLQ= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-321-LSzcQNJFMsqqHh6SkV-5ew-1; Wed, 18 Mar 2026 10:29:52 -0400 X-MC-Unique: LSzcQNJFMsqqHh6SkV-5ew-1 X-Mimecast-MFC-AGG-ID: LSzcQNJFMsqqHh6SkV-5ew_1773844191 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-43b42fe9031so577549f8f.0 for ; Wed, 18 Mar 2026 07:29:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773844191; x=1774448991; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mctQ9Nq15ZBnvh3CdyMq77ctH2Ta5FbU1NlrSoGobXU=; b=JFLSaqncgw9/c3O/Zh1dNEi9KZTJmhmiNSyA1nlF7QttTpmbVgF4Yw3y3eUBVC3y+M oXszfIdR9NqjSzHXA8oq36ZM8NQbZcxd/aXKGuQnnXRAb5B4ZWHMmkoSHNgFe/CMtB8s GfIhTVLE1d1DTomVr6tSsvHjHn4Y66WPUYdoH1kO/DfDwgghH9YxgA/wmQFtFKKVU5Fx t9tkByyw5/Zh0yLMJHCNe3rYFxxDDfXLFUTNKdn14Ewl7YOW3cl65b/VwRLAql0nNYlY uI8ngjaCjrPv/ZIK9fy7mr02x0XNHqWzwBcPu/x/HUGj6PGQahqcGmpW0JXY/nC3BL2N t8pQ== X-Forwarded-Encrypted: i=1; AJvYcCXLnAOaLadH162IR59J3pOcilFQ1ev7d3RuFu5FckutrvOL01/8TqjGNc6KgqibTbSbvMHcQJrlwV+jKg==@sourceware.org X-Gm-Message-State: AOJu0Yy4VQ0/o6UlTXbnyzI7gVh3FqRYyX48tCGLJbjLq62hyhH0D4RT luzkw6fcv4gi3zR+sZ++RAV8Yv8eSvrlQUf5tvsUQjRvrSZNCLL+vgRhjU6rTNzcMq2gPzVlZvD qCsB/gQgXRsU2YXTVfO327nLAaVzQCl//51nNUSjlJFnjmjN6Y4mjeVZoRY9LEc4gtt+gbxs= X-Gm-Gg: ATEYQzzOzRDS+2ez5g6x4UVyPzYruHRSJSpFNtozntSaO0h0r/7Ui/66pQeamnQpegK 6Nj/ydPTV3z0QAQunPWQd+Yht894o/iyddyaH3raNMxHEEBID22Bi7oq0ukHR5USX7sR7dj6YrF EGiM0Dwi5wla9hi/nc/0Z1J+fH9pY9twwauZAr/zQSNKa7Gi44/qgNxFBVIC/rMDsUVyYjJ3F4i Ui3UXtMNKCOFjAAQbUCDyaVW2af/VNkZAnS6IjM7ajd8q4wxtNm1FSoyYtbKxDQo64r6P71isS6 Vun4QhFyKSzXQK2X1XrJEs7NptvOM1MY9dCW3prj48KS2lmsbWPPbynTLZ3fRFHbPNOg+yTUAsz 4/8L8hLBjQFzZ1Hzh X-Received: by 2002:a05:6000:4013:b0:43b:50d6:4f00 with SMTP id ffacd0b85a97d-43b527c4b66mr6151581f8f.30.1773844190642; Wed, 18 Mar 2026 07:29:50 -0700 (PDT) X-Received: by 2002:a05:6000:4013:b0:43b:50d6:4f00 with SMTP id ffacd0b85a97d-43b527c4b66mr6151509f8f.30.1773844190010; Wed, 18 Mar 2026 07:29:50 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b51851e43sm8105110f8f.10.2026.03.18.07.29.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 07:29:49 -0700 (PDT) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [PATCH] [gdb] Fix missing print frame when stepping out of function In-Reply-To: <20260312120211.3806600-1-tdevries@suse.de> References: <20260312120211.3806600-1-tdevries@suse.de> Date: Wed, 18 Mar 2026 14:29:48 +0000 Message-ID: <871phh6wir.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: JlPtM7CUTnDkaw0ztN6y5MJEdlmxa4DKz7ueiq8O0TQ_1773844191 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Tom de Vries writes: > Consider test-case gdb.dwarf2/dw2-extend-inline-block.exp, specifically the > "contiguous block" prefix part, which can be stepped through like this: > ... > $ gdb -q outputs/gdb.dwarf2/dw2-extend-inline-block/dw2-extend-inline-block-5 > Reading symbols from dw2-extend-inline-block-5... > (gdb) start > ... > Temporary breakpoint 1, main () at dw2-extend-inline-block.c:35 > 35 /* main:2 */ > (gdb) s > 36 /* main:3 */ foo (); /* foo call line */ > (gdb) > foo () at dw2-extend-inline-block.c:26 > 26 /* foo:1 */ > (gdb) s > 27 /* foo:2 */ > (gdb) s > 28 /* foo:3 */ > (gdb) s > main () at dw2-extend-inline-block.c:37 > 37 /* main:4 */ > (gdb) > ... > > If we slightly modify the line program: > ... > DW_LNE_set_address main_4 > + DW_LNS_advance_line 1 > DW_LNS_copy > > DW_LNE_set_address main_5 > - DW_LNS_advance_line 1 > DW_LNS_negate_stmt > DW_LNS_copy > ... > we change the 36/0x401165 entry into a 37/0x401165 entry: > ... > File name Line number Starting address View Stmt > dw2-extend-inline-block.c 34 0x401116 x > dw2-extend-inline-block.c 35 0x401129 x > dw2-extend-inline-block.c 26 0x401138 x > dw2-extend-inline-block.c 27 0x401147 x > dw2-extend-inline-block.c 28 0x401156 x > dw2-extend-inline-block.c 36 0x401156 > -dw2-extend-inline-block.c 36 0x401165 > +dw2-extend-inline-block.c 37 0x401165 > dw2-extend-inline-block.c 37 0x401174 x > dw2-extend-inline-block.c 38 0x401183 x > dw2-extend-inline-block.c 39 0x401192 x > dw2-extend-inline-block.c 40 0x4011a1 x > dw2-extend-inline-block.c - 0x4011b7 > ... > > As it happens, the fix to extend truncated inlined function blocks doesn't > work in this case. This is PR33930. > > We can work around this by making sure that the inlined function block isn't > truncated in the first place: > ... > - DW_AT_high_pc main_3 addr > + DW_AT_high_pc main_4 addr > ... > > But then we still run into PR33981: the problem that gdb doesn't notify us > when stepping out of main: > ... > (gdb) step^M > 28 /* foo:3 */^M > (gdb) step^M > 37 /* main:4 */^M > (gdb) > ... > > What happens is that the slightly different line program triggers a different > stepping path, which includes a case of "stepped to a different frame, but > it's not the start of a statement", which refreshes the stepping info and > consequently updates tp->control.step_frame_id to the frame id of main. > > So by the time we're stopped at line 37, and are trying to figure out what to > print in print_stop_location, this condition evaluates to true: > ... > if (tp->control.stop_step > && (tp->control.step_frame_id > == get_frame_id (get_current_frame ())) > && (tp->control.step_start_function > == find_symbol_for_pc (tp->stop_pc ()))) > ... > and we get: > ... > /* Finished step in same frame and same file, just print source > line. */ > source_flag = SRC_LINE; > ... > > It's good to realize here that because foo is inlined into main, > tp->control.step_start_function is not foo but main, so consequently the > step_start_function check (which checks if we are still in the same function) > also passes, even though we actually stepped from foo into main. > > No longer refreshing the stepping info in the "stepped to a different frame, > but it's not the start of a statement" case does fix the problem. > > But the refreshing is needed to be able to handle stepping out of say function > f1 into function f2 and immediately stepping back into f1 again. If we don't > refresh in between, it looks like we stayed in f1. > > Fix this by: > - adding a new field thread_control_state::step_frame_id_changed, > - updating the new field in set_step_info when refreshing, and > - using the new field in print_stop_location. > > Tested on x86_64-linux. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33981 > --- > gdb/gdbthread.h | 4 ++ > gdb/infrun.c | 10 ++++- > gdb/infrun.h | 5 ++- > .../gdb.dwarf2/dw2-extend-inline-block.exp | 45 +++++++++++++++++-- > 4 files changed, 57 insertions(+), 7 deletions(-) > > diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h > index 68d7aebbbf7..02cf8f01fca 100644 > --- a/gdb/gdbthread.h > +++ b/gdb/gdbthread.h > @@ -146,6 +146,10 @@ struct thread_control_state > any inlined frames). */ > struct frame_id step_stack_frame_id {}; > > + /* True if step_frame_id was changed after the stepping command was > + issued. */ > + bool step_frame_id_changed = false; > + > /* True if the thread is presently stepping over a breakpoint or > a watchpoint, either with an inline step over or a displaced (out > of line) step, and we're now expecting it to report a trap for > diff --git a/gdb/infrun.c b/gdb/infrun.c > index c05c2b0f42f..df55c9a3c66 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -3084,6 +3084,7 @@ clear_proceed_status_thread (struct thread_info *tp) > tp->control.step_range_end = 0; > tp->control.may_range_step = 0; > tp->control.step_frame_id = null_frame_id; > + tp->control.step_frame_id_changed = false; > tp->control.step_stack_frame_id = null_frame_id; > tp->control.step_over_calls = STEP_OVER_UNDEBUGGABLE; > tp->control.step_start_function = nullptr; > @@ -4818,12 +4819,16 @@ fetch_inferior_event () > > void > set_step_info (thread_info *tp, const frame_info_ptr &frame, > - struct symtab_and_line sal) > + struct symtab_and_line sal, bool refresh_p) > { > /* This can be removed once this function no longer implicitly relies on the > inferior_ptid value. */ > gdb_assert (inferior_ptid == tp->ptid); > > + if (refresh_p > + && tp->control.step_frame_id != null_frame_id Unfortunately, this doesn't work. Comparing frame_ids ends up in frame_id::operator== in frame.c, which always returns false if either frame-id is null_frame_id. As a result, the != above always returns true. I think this is why you ended up having to add the refresh_p argument maybe? As a *hack* to check this theory, I removed the check of `refresh_p` here, and replaced the comparison to null_frame_id with: memcmp (&tp->control.step_frame_id, &null_frame_id, sizeof (decltype (null_frame_id))) != 0 NOTE: This is NOT actual proposed code, just a hack to test this theory. With these changes in place your modified dw2-extend-inline-block.exp still passes. But I want to go back to something you said earlier: > It's good to realize here that because foo is inlined into main, > tp->control.step_start_function is not foo but main, so consequently the > step_start_function check (which checks if we are still in the same function) > also passes, even though we actually stepped from foo into main. I haven't looked into the history of this, but I wonder if there is a good reason why step_start_function doesn't record the actual function? Again, without looking, my guess would be that this is just the way it has always been, so maybe the answer here is to have step_start_function track the actual function symbol. As a *hack* everywhere that step_start_function is set or referenced, where we currently use `find_symbol_for_pc` I switched to use `find_symbol_for_pc_sect_maybe_inline` passing nullptr for the section. This would need dealing with properly for a real fix, but is good enough for a quick test. With this change in place, and the GDB code parts of your patch reverted, your modified test case still passes. I think that it is worth at least investigating altering step_start_function to track the actual function, including inline functions, this seems like it would be a better fix. But if not then at least we'll understand why it's not the right solution. Thanks, Andrew