From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id hsf2E4uAsGmnYiIAWB0awg (envelope-from ) for ; Tue, 10 Mar 2026 16:35:23 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=nisr9+S5; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=9G1MG/Lo; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=nisr9+S5; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=9G1MG/Lo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 32C381E089; Tue, 10 Mar 2026 16:35:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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,WEIRD_PORT 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 8AFC11E089 for ; Tue, 10 Mar 2026 16:35:20 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 1CBF24BAD16A for ; Tue, 10 Mar 2026 20:35:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1CBF24BAD16A Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=nisr9+S5; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=9G1MG/Lo; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=nisr9+S5; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=9G1MG/Lo Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id D3C0A4B9DB68 for ; Tue, 10 Mar 2026 20:34:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D3C0A4B9DB68 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D3C0A4B9DB68 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773174890; cv=none; b=ekHBb0wFbYhJZSFtcesE7RSCxNiJQOqExJDHtqIbQWn8rxJWEdUFboHVQ3DaiY9a4sgxRQUY4RPkW0i+zSOUe/MEx6mwhnBipJ+Sfybi8IGkwPzqRMc2A3YWdZfwt0SoiwsbvEoQPKfJmBXsLpHeAQs2z3kmCtQPbfGoGGH5Kz8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773174890; c=relaxed/simple; bh=FcBhhj2Jr2Xo5I8AYMBI0r27aeFrT74ZObO37kpzBP0=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=pfalDLoRzREhdcmmFkIJWOXW23rZJkxorXFFZSuZuRztRl4+wgxsSWNw1756rKeQQXKZalvMwuDp2V0bEjcWRVlWb1ebqOWSnH/Kdgc/CtNZw2x3Q18vZwrn+w2CJctF7p+kWYbOGm2VWO7Okk+hMqqYAEsfO8H3/hIfOG9Rlco= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3C0A4B9DB68 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B6B825BD0D; Tue, 10 Mar 2026 20:34:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1773174888; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7eDM3F5a0WT0wn57qclmzOfdDrXrIquq5/mx5QVuxYg=; b=nisr9+S5Kv/0YTG/qy5pLF8EFR17s47dN6XuCuYHN9sIkwxERZRTuL3a5MDKaDfUfux63R 1We913kTjgn4ZJBiVYJe+oGEjIqR94uEJizrZXrbKdaHncnYjiP8jsaJsrNtaiaOmsnmy9 A/TakeYsseVIvDELTVJrNiMtv7vi+w0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1773174888; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7eDM3F5a0WT0wn57qclmzOfdDrXrIquq5/mx5QVuxYg=; b=9G1MG/LodfSHJ1u/qXssaDA8GIt+J1egBEKaJvsso/LdG5KLGkqVepsxEym6pVUdJwvvfb UEBkEIP3XFhY78Ag== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1773174888; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7eDM3F5a0WT0wn57qclmzOfdDrXrIquq5/mx5QVuxYg=; b=nisr9+S5Kv/0YTG/qy5pLF8EFR17s47dN6XuCuYHN9sIkwxERZRTuL3a5MDKaDfUfux63R 1We913kTjgn4ZJBiVYJe+oGEjIqR94uEJizrZXrbKdaHncnYjiP8jsaJsrNtaiaOmsnmy9 A/TakeYsseVIvDELTVJrNiMtv7vi+w0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1773174888; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7eDM3F5a0WT0wn57qclmzOfdDrXrIquq5/mx5QVuxYg=; b=9G1MG/LodfSHJ1u/qXssaDA8GIt+J1egBEKaJvsso/LdG5KLGkqVepsxEym6pVUdJwvvfb UEBkEIP3XFhY78Ag== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 988A83F643; Tue, 10 Mar 2026 20:34:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id SklAI2iAsGnIFAAAD6G6ig (envelope-from ); Tue, 10 Mar 2026 20:34:48 +0000 Message-ID: <40a83dad-1a3a-4b68-b84e-9b7cc3b9f866@suse.de> Date: Tue, 10 Mar 2026 21:34:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] [gdb/symtab] Tweak fix-up of truncated inline function block ranges To: Andrew Burgess , gdb-patches@sourceware.org References: <20260302114849.1797017-1-tdevries@suse.de> <20260302114849.1797017-4-tdevries@suse.de> <875x738ybx.fsf@redhat.com> Content-Language: en-US From: Tom de Vries In-Reply-To: <875x738ybx.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email] 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 3/10/26 5:05 PM, Andrew Burgess wrote: > Tom de Vries writes: > >> Consider test-case gdb.cp/step-and-next-inline.exp on ppc64le-linux. >> >> The corresponding source file step-and-next-inline.cc contains functions >> tree_check and get_alias_set: >> ... >> 35 #define TREE_TYPE(NODE) (*tree_check (NODE, 0)) >> 36 >> 37 inline tree * >> 38 tree_check (tree *t, int i) >> 39 { >> 40 if (t->x != i) >> 41 abort(); >> 42 tree *x = t; >> 43 return x; >> 44 } >> ... >> 48 int __attribute__((noinline, noclone)) >> 49 get_alias_set (tree *t) >> 50 { >> 51 if (t != NULL >> 52 && TREE_TYPE (t).z != 1 >> 53 && TREE_TYPE (t).z != 2 >> 54 && TREE_TYPE (t).z != 3) >> 55 return 0; >> 56 return 1; >> 57 } >> ... >> as well as a trivial function main calling get_alias_set. >> >> Say we step into the first call to tree_check, and then step to the return >> at line 43: >> ... >> (gdb) s >> tree_check (i=0, t=0x10020030 ) at step-and-next-inline.cc:40 >> 40 if (t->x != i) >> (gdb) s >> 43 return x; >> (gdb) >> ... >> >> At that point, we have pc 0x1000071c: >> ... >> (gdb) p $pc >> $1 = (void (*)(void)) 0x1000071c >> (gdb) >> ... >> and the backtrace looks like this: >> ... >> (gdb) bt >> #0 tree_check (i=, t=) at >> step-and-next-inline.cc:43 >> #1 get_alias_set (t=t@entry=0x10020030 ) at step-and-next-inline.cc:52 >> #2 0x0000000010000560 in main () at step-and-next-inline.cc:64 >> (gdb) >> ... >> which shows all 3 functions. >> >> This seems trivial, but it's not. >> >> All three calls to tree_check are inlined, and the first call is represented >> by: >> ... >> <2><877>: Abbrev Number: 40 (DW_TAG_inlined_subroutine) >> <878> DW_AT_abstract_origin: <0x967> >> <87c> DW_AT_entry_pc : 0x10000710 >> <884> DW_AT_GNU_entry_view: 0 >> <885> DW_AT_ranges : 0xc >> <88a> DW_AT_call_line : 52 >> ... >> with DW_AT_ranges referring to: >> ... >> Contents of the .debug_rnglists section: >> >> Offset Begin End >> 0000000c 0000000010000710 (base address) >> 00000015 0000000010000710 000000001000071c >> 00000018 000000001000077c 000000001000077c (start == end) >> 0000001b 0000000010000788 0000000010000790 >> 0000001f >> ... >> >> The range at offset 0x15 is [0x10000710, 0x1000071c), so address 0x1000071c >> does not fall in the range, and consequently the debug info does not consider >> 0x1000071c part of the inlined tree_check. >> >> However, since commit 8efed40efd6 ("gdb: fix-up truncated inline function >> block ranges"), gdb contains a fix in lnp_state_machine::record_line: >> ... >> if (m_address != m_last_address >> && m_stmt_at_address >> && m_cu->producer_is_gcc () >> && (m_flags & LEF_IS_STMT) == 0) >> dwarf_find_and_extend_inline_block_range (m_cu, m_last_address, >> m_address, m_line); >> ... >> that looks at the corresponding line number information: >> ... >> File name Line number Starting address View Stmt >> step-and-next-inline.cc 42 0x1000071c x >> step-and-next-inline.cc 43 0x1000071c 1 x >> step-and-next-inline.cc 43 0x1000071c 2 >> step-and-next-inline.cc 52 0x1000071c 3 >> step-and-next-inline.cc 52 0x10000720 >> ... >> and extends the range of the inlined tree_check to include >> [0x1000071c, 0x10000720). >> >> [ Please read the commit message of aforementioned commit to understand why >> the fix is correct. ] >> >> Let's look in more detail at how the call to >> dwarf_find_and_extend_inline_block_range is activated for the fix. It's >> activated for the last entry (52/0x10000720), with: >> - m_last_address == 0x1000071c, >> - m_address == 0x10000720, and >> - m_line == 52 (matching the DW_AT_call_line). >> >> It's easy to see that for the last entry, (m_flags & LEF_IS_STMT) == 0 holds, >> because it doesn't have an x in the "Stmt" column. >> >> I found it less obvious that m_stmt_at_address also holds. >> >> [ The documentation clarifies that this is related to m_last_address: >> .... >> /* Set to true when a previous line at the same address (using >> m_last_address) had LEF_IS_STMT set in m_flags. This is reset to false >> when a line entry at a new address (m_address different to >> m_last_address) is processed. */ >> bool m_stmt_at_address = false; >> ... >> >> To get maximum clarity, I checked the value for each entry: >> ... >> address m_stmt_at_address >> --------------------------------- >> before false >> 42/0x1000071c false->true >> 43/0x1000071c/1 true >> 43/0x1000071c/2 true >> 52/0x1000071c/3 true >> 52/0x10000720 true->false >> ... >> >> Again it's easy to relate the transitions for particular entries to the "Stmt" >> column. >> >> The tricky bit is that the transition takes place at the end of >> lnp_state_machine::record_line, so while processing entry 52/0x10000720, we >> sample m_stmt_at_address while it's still true. ] >> >> Likewise, the fix works for the second inlined call. >> >> But not for the third. The debug info has the same problem, but the fix is >> not applied. >> >> The corresponding line info looks slightly different: >> ... >> File name Line number Starting address View Stmt >> step-and-next-inline.cc 42 0x1000074c x >> step-and-next-inline.cc 43 0x1000074c 1 x >> step-and-next-inline.cc 43 0x1000074c 2 >> step-and-next-inline.cc 54 0x1000074c 3 >> step-and-next-inline.cc 55 0x10000750 >> ... >> >> In this case, dwarf_find_and_extend_inline_block_range gets called with: >> - m_last_address == 0x1000074c, >> - m_address == 0x10000750, and >> - m_line == 55, >> but since line 55 doesn't match DW_AT_call_line 54: >> ... >> <2><918>: Abbrev Number: 44 (DW_TAG_inlined_subroutine) >> <919> DW_AT_abstract_origin: <0x967> >> <91d> DW_AT_entry_pc : 0x10000740 >> <925> DW_AT_GNU_entry_view: 0 >> <926> DW_AT_low_pc : 0x10000740 >> <92e> DW_AT_high_pc : 0xc >> <937> DW_AT_call_line : 54 >> ... >> the fix is not applied. >> >> I'm proposing the following simple tweak, to handle the third inlined call as >> well: instead of using m_line, use m_last_line. >> >> Tested on x86_64-linux and ppc64le-linux. >> >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930 > > Hi Tom, > > Thanks for looking at this failure. Can you confirm which gcc version > you're using please. I don't see the same failure on cfarm29 (from gcc > compile farm), using gcc 'gcc (Debian 14.2.0-19) 14.2.0'. But that > step-and-next-inline test can change behaviour based on compiler > version, so I'm not surprised you're seeing failures on some specific > combinations. Hi Andrew, As stated here ( https://sourceware.org/bugzilla/show_bug.cgi?id=33930#c2 ) ... Used compiler version: ... [vries@cfarm120 gdb]$ gcc --version gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11) ... So I'd try cfarm120. Thanks, - Tom > Which is why I tried to write DWARF assembler tests to cover edge cases > as I found them, and I think it would be great if we could get such a > test to cover this fix too. I'm happy to help with, or even write, the > test, once I can reproduce the failure. > > I'll try some other ppc64le machines I have access too, maybe one of > those will have the right compiler version already installed, otherwise > I'll have to rebuild gcc once you let me know which version is causing > problems. > > Thanks, > Andrew >