From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JodVFJt2tWlHOykAWB0awg (envelope-from ) for ; Sat, 14 Mar 2026 10:54:19 -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=UD1+ZUwc; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=A+FNjlU/; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=fsQc/Dok; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=sPn0szPc; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3CF2E1E0DD; Sat, 14 Mar 2026 10:54:19 -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 3E4D41E08D for ; Sat, 14 Mar 2026 10:54:17 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id A9C474B35888 for ; Sat, 14 Mar 2026 14:54:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A9C474B35888 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=UD1+ZUwc; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=A+FNjlU/; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=fsQc/Dok; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=sPn0szPc Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id 679BE4BAE7D6 for ; Sat, 14 Mar 2026 14:53:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 679BE4BAE7D6 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 679BE4BAE7D6 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773500028; cv=none; b=v4+Ht6BXfI9YhA/9lRSgwMWmEy0/O6g4+ToqHIRHcl0+ChO4mQzOhRM5R6FLCtycyRZEa79XQ+FROgimUkJjlLd3bdUZY2pbXfLHG9jpvvSd+DBw1FnYVYzqoTJBaMywizN0Y0oj0K0X96IQxWPvL9AAlhCNdN3q7KbTBEFS178= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773500028; c=relaxed/simple; bh=ALsUjB0UrUVoFL9pPiV/eyhvUoUztbwNu2RHee4ze1E=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=KyID6201JH3NCtTEKUjPKfdJsjTv5ur7p8XcF5G6IFNYLMV7BbzSpwVaBYqHpQ7Ne4HCxJ50oUiv4Opn97Pr2vLUJuE6Y9v6BDeX7eJn16Wcvu6/vPwoSQFBKQr1GdX8fGKjSHIhakv0S3S9pwM5WCwrC3bTxiZ1z4E7GY0sMV4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 679BE4BAE7D6 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-out1.suse.de (Postfix) with ESMTPS id 1CC3F4D204; Sat, 14 Mar 2026 14:53:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1773500027; 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=gvDfjFsHVFVClJuDagf7byn1KhoIjx2mJW/TDzDzYoI=; b=UD1+ZUwcRbVHrWkmJ8cXCmXs8BhNX9kna1MsAcQw4dxEdWzFJ0lh7Vm6g03t65QXuYzy4K jW1ByktJoXC/DZjuiJY6cVDrAgm12cxzXDV4xbotvMauyG083MX0S295P8/R0kUpVZF6pB usIBn6U2ZPqZ7+uVipLmlBylDdo6EKE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1773500027; 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=gvDfjFsHVFVClJuDagf7byn1KhoIjx2mJW/TDzDzYoI=; b=A+FNjlU/V8W78XtMIeRAVaeLTV/Kx4REd3G67pCFJY8s4XskEzzo0LxhLVCsN8RJ3xdFzN qA3prfMdk1GQfyCw== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1773500026; 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=gvDfjFsHVFVClJuDagf7byn1KhoIjx2mJW/TDzDzYoI=; b=fsQc/Dokri2Y6nO2DjNLTGPKW7vyPVEGt37mHzISV1A0gR4sfv4R1aJj2GQy3D86MfsH0/ OR8wMN94JpAVrvMUY3UwagtAz7TIdyypnidXqjHeW42qJd2UF4Oh7FJJgnqgaZ6aPMcrkJ HAdNv66liE4gW/k2vbYiQNcEdFYCR20= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1773500026; 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=gvDfjFsHVFVClJuDagf7byn1KhoIjx2mJW/TDzDzYoI=; b=sPn0szPcP11OrCeBRuYxBFyF23XTQ7e7/Ouoz+OyMn8CwHFIuVb1rB5Jit5Wz0yl3RApjW FpaIS1oDgI+hh6CQ== 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 0116142724; Sat, 14 Mar 2026 14:53:45 +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 UAcBOnl2tWkmWwAAD6G6ig (envelope-from ); Sat, 14 Mar 2026 14:53:45 +0000 Message-ID: <5d5cd7b6-a7bf-440d-aca9-8c4cee4dc613@suse.de> Date: Sat, 14 Mar 2026 15:53:45 +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> <40a83dad-1a3a-4b68-b84e-9b7cc3b9f866@suse.de> <87pl567anw.fsf@redhat.com> Content-Language: en-US From: Tom de Vries In-Reply-To: <87pl567anw.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)[-0.999]; 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)[imap1.dmz-prg2.suse.org:helo, sourceware.org:url, step-and-next-inline.cc:url, suse.de:mid, suse.de:email, cfarm120:email, entry: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/14/26 3:22 PM, Andrew Burgess wrote: > Tom de Vries writes: > >> 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. Just wanted to say I've not forgotten this patch. I managed to > reproduce the failure, and I understand what's going on now. I'm going > to think about this some more next week. > Great, thanks for the update. - Tom > Thanks, > Andrew >