From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YawhGFlBsGn84yEAWB0awg (envelope-from ) for ; Tue, 10 Mar 2026 12:05:45 -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=AkN9d2LH; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5BE941E0DD; Tue, 10 Mar 2026 12:05:45 -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,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 E9ECF1E089 for ; Tue, 10 Mar 2026 12:05:43 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 79B884BA23C9 for ; Tue, 10 Mar 2026 16:05:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79B884BA23C9 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=AkN9d2LH 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 C22324BA2E10 for ; Tue, 10 Mar 2026 16:05:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C22324BA2E10 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 C22324BA2E10 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=1773158714; cv=none; b=d5EFaTwNRwN6h+2v17+SjCYSG5dUEecWo5waBNAoJ0iAkLi50jXJgQ/thRxZ+azHjqudKbo5pZRKiTA6GWrA5W3WOVEio7Y4NOD0nNpHzwZBuaAtFjzz/Ep4iP+YTHVQWIq2VknWg0VeL/KPi2csHhEvE7lJyxopRqeJ5NeqEw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773158714; c=relaxed/simple; bh=XKEo4icDARZwvk03uDNM766S/HoR5AcTxAoNO8h7VSQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=v600AALElf/gh6BRWUg2oD/e2EM2iF6RTl1CPosGBRf5yUlEx7Xd5OJUBUb06gVxgMAc+j6reoMfE9dy6zWRaL2Aa2S7uy9SOqISGXYa9GW9KlS3L4jEvQjJEdJDKnGCAM8pUIhyP/ivSWHJjoDRJUKHJFJuSZqHdFdL3HGCPkk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C22324BA2E10 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773158714; 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=Ew2XKoO9+eYnD1RZODQaaTG71rB1FEFte559H2lzWL0=; b=AkN9d2LHcpFx7kt7uochtnbAG+plFsw+4yfD2NsGZHZAmcI2MKY+6/9LRotM9MYTfRg8Dn J/54Ne3OvwzmrUsbcmcQqToNBZoL/lNPOa5gk02hyOEQKctxyC7ewTVMWawiEh+60FGwPv W9xO7Zpwi6xg876nWq7FGlZGJlWBVFM= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-247-QVVQCpSUOUytATfIy02uQw-1; Tue, 10 Mar 2026 12:05:12 -0400 X-MC-Unique: QVVQCpSUOUytATfIy02uQw-1 X-Mimecast-MFC-AGG-ID: QVVQCpSUOUytATfIy02uQw_1773158711 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-48541cac34dso11923475e9.0 for ; Tue, 10 Mar 2026 09:05:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773158710; x=1773763510; 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=Ew2XKoO9+eYnD1RZODQaaTG71rB1FEFte559H2lzWL0=; b=tg2w2+8TuVA9oitKNDb34pGjXRAR6kXdztBymRoSGaBEQPKnsxIOV8y5z5nU6kk6rh YSkKevB6ChJDmIenqt5SuYrOi8MB8LslYo4VMDnjqFu+dAld6hABU+S0vri8b23jLBCv Ovx8bh7ZlBp6oWTNdIBINB53rtwbOMKqMC4tXGhaeVVQ7Smos8Nb6uWCs0kTvrVLaeZ4 UNo3Cm4P0q7lJ/q5GXaKqCSROPktnbG6CXyjb8+rCORrLQgqjHHF/fYrZmt6+vUT6ZuE enc7lPcSRlfLs64nsXcwhI7/22wo3i/gWPFugnFU6MyWMlseETvG6BgA8qrX3CPHEVEz SXbg== X-Forwarded-Encrypted: i=1; AJvYcCW1xYET3NU2ONsYLbfXiJ4Ir0FKtWtc+EriV+oFG/JHzt5pvYlHccTOvsxgntkYhOCVR/L8+HBy9/FVUA==@sourceware.org X-Gm-Message-State: AOJu0YxiKaPVWTLlpzgxMIme9ZE6RnitNkEldXAMJyBiblaJDcmePzU/ RzjSHIq3rUouKyMzPlKHcnhKXNbV5msKf2WFmV4IIFOVGckpwp/BQcjpA9o+W7NEo0MAtUoxQmH ZjvuybTp9EKJZ24Tcr6VwEkRAx2TvgxQKOOA9e0RrlRuaJRFgGIGFfWXPzVaLQgc2/k6CbrE= X-Gm-Gg: ATEYQzzJXhAsmbvA2D3XJ3imlv/4b8tcpw17kwIicTVyD+SDrbw8p72VcwqA6nkKduM JT+fC3m/YZ+3S5b9Qj8f11vK1gPFtcFOXdutP5bOWhzCizTTuQsibZx9Z5Vrq3xO6akr8QdoxWO zsya/3G6+9EUu7v2BBNGW0/6z84QPP0IP4x+OS3XKtX0il8n/n4JL8Uz2EIWYHdH1ktEknZIVOd 4dP1DWgOuKYAJJLEujdFAhe+UeHZRNxd3zQA4rki0O+gMCSBoGOI102aWCZ2Xjx58oQxgm8MvBt 5eILDZbVAjY9b5F6PqeYb7MVxjEcmdlvYdWs44FGHBwzqXc3ZQsYwFE9QkHd1TAqvz3AQm53Yf9 I2Kh2tdme0lfYjyUc X-Received: by 2002:a05:600c:c107:b0:485:3eba:ab96 with SMTP id 5b1f17b1804b1-4853ebab021mr85991295e9.3.1773158709905; Tue, 10 Mar 2026 09:05:09 -0700 (PDT) X-Received: by 2002:a05:600c:c107:b0:485:3eba:ab96 with SMTP id 5b1f17b1804b1-4853ebab021mr85990365e9.3.1773158709084; Tue, 10 Mar 2026 09:05:09 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485354f96fesm73788995e9.30.2026.03.10.09.05.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 09:05:08 -0700 (PDT) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] [gdb/symtab] Tweak fix-up of truncated inline function block ranges In-Reply-To: <20260302114849.1797017-4-tdevries@suse.de> References: <20260302114849.1797017-1-tdevries@suse.de> <20260302114849.1797017-4-tdevries@suse.de> Date: Tue, 10 Mar 2026 16:05:06 +0000 Message-ID: <875x738ybx.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: PHvlB_Bue81JJRvMoJ-y0pv5a9YbjxTSSeIJtJ2qbIs_1773158711 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.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. 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