From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Eqs4LXBvtWnKMykAWB0awg (envelope-from ) for ; Sat, 14 Mar 2026 10:23:44 -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=bQSJqF4l; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A279C1E08D; Sat, 14 Mar 2026 10:23:44 -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 8A58A1E08D for ; Sat, 14 Mar 2026 10:23:43 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 7B2D64C318BA for ; Sat, 14 Mar 2026 14:23:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7B2D64C318BA 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=bQSJqF4l 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 01C5E4C31890 for ; Sat, 14 Mar 2026 14:23:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 01C5E4C31890 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 01C5E4C31890 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=1773498186; cv=none; b=vDyPxBfAcIV865zhHYa25fX6TjNV9KSbSeIDdryqFQFMk3yVAyqu4mfR3T3s8wrt4lxWyYunwQY+3mcoPQV9KEkLt5VOVYNE+/ILuNo2yjkqQL3WPDwvWmwvfUlJ2wJknbGNCR3+Fy+V/Z+gcy0PI38CkQJjhxPEdMhZ9usYA1g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773498186; c=relaxed/simple; bh=mUGm3u5gLOHysTZUqiXV5MUM280CDCiTKO+KqmBZ8w0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=vVblNBaG5HMRAsJP4dUh0AXKqQ0q3+fxUWj1qx9cHrFt6HjaMjU9mlasgWdHlyXV4WtARLBz3f45iEF03oXIbY80tHFLqL/zs3b1pSdImI76TX+yZNz/OgRFMnjzK3bs0w2UfHtA2BPECsG6O8USFNhqd6RKdV2oIPrSQRKCAlU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 01C5E4C31890 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773498185; 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=Prp1FLrJZTXh465FcKIjc0lVThVvRI1szkVSR49j4x8=; b=bQSJqF4lIxPWFUkCmvknrPppE24z1XxlHpiC/YMZ6amkm//yL/cg49zQ1fYKuY3Tc0Hue0 LrdC7jbJTR0SxyM5l7qjrzsobupnbJ0LNPX9yhzJzP1OWnVruETUz+4jt7x9QjYbH0hX2Z MbpeGP/Y3JAe8uICfRdqajhZB7jN9bw= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-577-9p4EoodKOL2GzCc-A6FcWg-1; Sat, 14 Mar 2026 10:23:04 -0400 X-MC-Unique: 9p4EoodKOL2GzCc-A6FcWg-1 X-Mimecast-MFC-AGG-ID: 9p4EoodKOL2GzCc-A6FcWg_1773498183 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-b9794b9d3e3so29496066b.0 for ; Sat, 14 Mar 2026 07:23:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773498183; x=1774102983; 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=Prp1FLrJZTXh465FcKIjc0lVThVvRI1szkVSR49j4x8=; b=dJP3XUkJnY8N6bH9i6y93LoLKxmoFle+2ZqzX0qGq4JJ2o+lt2ewqmR1XxCxStEg3V mSZKH6KyPL/3MsxsS1d0knHt+Z+RSDzkB59GeBYNaoklSWHjRgj4ipIcB+GxbgzBLyhQ AZSSFVjOn9encPujkGevsz/gMk5+xLVeg241YDeVbNdk+iYzyYOtXinMlQsgcQU4hww4 r5OMtV8Oxw/VlL2pXkMomCu1v/CGmDzsSW93LqHw6U8BXkzNvwXaIT/l9GAXe0rS6fbS nC4H+cZreyG7BkSnpzEo2cgPHZP/Xx+pw/K4fPrs7xCoX/UVoZmpiHq1Z6JvyI4JZKTT wQag== X-Forwarded-Encrypted: i=1; AJvYcCVvdqVmvkqAL6tvMXOS1yqRVVDaZ7o8UQ+SwH9WJxck83NuP9L2M9MuyzGqXlupYLCS9TcKI+t8n7MsmA==@sourceware.org X-Gm-Message-State: AOJu0YzHX+TYFNasArM/2zIbh643fBUvgk/LRVltznzCqVZQusrSpwga np45/e4wRnoaZAxJDwcEO0sKLXUOpyULz4uY8zwPFiCJVDl12c50hUhqpSvpTKsfJItW5ENKq6O TBjdAx6q6U3BnXaTrqQIyTlkof6jlbPvmafMFFvmBQ+ZhCSU3sUtvcYMbWrGQ5Hg= X-Gm-Gg: ATEYQzxmX5xY3KHyZTNOU1CjLIqhJAIr8vGs3cF+4yeksDRZ1lY5E8iWxZdVkQv26Sr 6UYhbB9RaPIxzQwNVqyfa4hYGdIE8oNWNCKViT15We52nICc9f3x36aty6VE3PrxLM5tyxKYk9F FDouwSmvfSngI/L+LsVGQCcrId3jOPJPWQ7vY5UXAt1jYokUijA58BSvhqCDHRYupAWl+kL4mrl G+40/mdZsUe8CJYkWbS6oCvwp4gwPEPo5MCq0/mZwpgsjn0uem6/H/2U6jJHDlYkHv48FSDzqQm Y1ixDedqmGqnAeXEsPvzNbkVTDH1pHAPb8ZifDOHEZauQlwN7pvoCwq6vtTGmdua0CyW6TFsgea AZ7nMfQ0RkVrDnhjXaX+y0iSltWeV4hU9dh+X3sKSLqLEMg== X-Received: by 2002:a17:907:68a3:b0:b93:80f3:b356 with SMTP id a640c23a62f3a-b9764f7eabamr293908166b.8.1773498182679; Sat, 14 Mar 2026 07:23:02 -0700 (PDT) X-Received: by 2002:a17:907:68a3:b0:b93:80f3:b356 with SMTP id a640c23a62f3a-b9764f7eabamr293907166b.8.1773498182086; Sat, 14 Mar 2026 07:23:02 -0700 (PDT) Received: from localhost (92.40.185.182.threembb.co.uk. [92.40.185.182]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b9791c30cf3sm112576266b.2.2026.03.14.07.23.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Mar 2026 07:23:01 -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: <40a83dad-1a3a-4b68-b84e-9b7cc3b9f866@suse.de> References: <20260302114849.1797017-1-tdevries@suse.de> <20260302114849.1797017-4-tdevries@suse.de> <875x738ybx.fsf@redhat.com> <40a83dad-1a3a-4b68-b84e-9b7cc3b9f866@suse.de> Date: Sat, 14 Mar 2026 14:22:59 +0000 Message-ID: <87pl567anw.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 5IftfFIPNgPLzjjyh87Uf_pt827sDg2nuX6PWzivwXQ_1773498183 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: > 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. Thanks, Andrew