From patchwork Tue Jan 14 14:31:47 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 57941 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DFFBC385695B for ; Tue, 14 Jan 2025 14:32:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DFFBC385695B 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=YuyyPR7z X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 5E45E3856DF7 for ; Tue, 14 Jan 2025 14:31:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5E45E3856DF7 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 5E45E3856DF7 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=1736865115; cv=none; b=btsmY5COxC9o8BgTKSTNx1ial+MtMN1U+9wyD4RSL/7josJwNz89P5LFC6AnOgbN7NH1bnwjPq5r48SN2XZ7Cxcie6wh3LZINH2FoVa+js46rd8SCf9ivblnmRbLCsPQLPKQDoquKTf1CwVF8fHDF8kgy4THzkuYR0IzNqL9ioI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736865115; c=relaxed/simple; bh=A/fD3ybIUQNhnSWBlQCPg9MDkPhN/ULK+6bsWlz3DMU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=c3MLByRuXZXj1bkfhO7Vc5yszJap3NRTy/ooZYJuBuxy6fb3sBO/+mgGRjdEympMd7lT3jUPHlEIcUzLQmBJ+2Hm5odcXz8/8XrqzdFEbfddYZC9GcFXvz1OyqPbUArVi0nYVRm0f3U9qIMvcixtHgvP3dm06yL/rSEg4pfaz+s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5E45E3856DF7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736865115; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=abrFdK+pPBSV5a75tmvJkw4YoAXjIxcdHSsQGeWGDj0=; b=YuyyPR7zgPzVjShibe6J8FE7Bi2l7U3DKBgb5l2/t4r3MFTPIGyrEF0+R0fIxBxg3mXJ7X 5z5usi+hjp9zFmDYmF1muA/xWcRhCKfLkEZC4zsG4kOnGPBrKn5mpECvXGFDQtKM9x2u2q bnswBbuEJpPPVNL/s8wZA0AsnnpoOOY= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-mPJyu6fvPYeM2Q854-ZZ8g-1; Tue, 14 Jan 2025 09:31:54 -0500 X-MC-Unique: mPJyu6fvPYeM2Q854-ZZ8g-1 X-Mimecast-MFC-AGG-ID: mPJyu6fvPYeM2Q854-ZZ8g Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4359eb032c9so42637315e9.2 for ; Tue, 14 Jan 2025 06:31:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736865112; x=1737469912; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=abrFdK+pPBSV5a75tmvJkw4YoAXjIxcdHSsQGeWGDj0=; b=BklPgSavXm9Go5ZLZ8DejkA1HUJ7AIYGAN9TevJWUgtskFJdKitWfDU0LTDTH7chJN xHFoLcOzoTiHfekiMD6kfHEwoWSn+j8hZ7hHH64L54sZtzBAI6Dk3dsPlmxjzV2TDtVS E1AyIFENSV2oDGI3rgtUOArbsF3E2A4U226NvBOHEwggKSUd9tXCJmpVzDOkPOxvENge dvakK7ANo9+choFCqVRI9GGErnOFLGIfDCf3R8EYREV9MBPJgPZDAHRjRrMUf/tgwtuc Z2lBvPonDvuVg4MN+h2FsLGaRN3kqhwJe3t42YgkoXj1IHGp09jr3M8N3n+LtYBKIFho okpw== X-Gm-Message-State: AOJu0YwpHBRAyTM0Hk5sUCLLhuo/uljzMNKHkOP+sW+vwjEmd5lDOHrp K/CU20pPaCWcwW/I9tqDTs6xkgqd8au7cwa5m2+ATHoi0XqaAACD8yRnk8WusAPhbritzzvrSja /2T5XMXx7knp/A3Y4rvVMHKcgzN4jDq/+Pz1/MyYmJVIt5MOdyOxWhHXMuhIO4AaV1mwoG0SiqT EfX0o8RVu5qNqSoujIrju3ssuqdFq1ELvnW7cA1Oak9CQ= X-Gm-Gg: ASbGncsAqewNSUEcuouYtdS/bBnDc6n5K4gn6kgcbZUVuafBNnYHFCf5sNqWj9I03SG KacpR/Iqw0DbzVdrVn8so9FGio2qlLfCaOVltTRBf0ePPTy9rDxouu2VOb8gcAPGo3A1BnuBRGR tt2O/Rlq7I1RvyuIYwX4Gl5il18zeMO+mLBjX+G/g85gyeh8EZe10zInyUQFRq0UeYyhCKtDNXY kB6ID/E1VdPKmLnedbu6/p9+c9BV/zPKhoLn76xffXqezg6JC7B2pMOYFrSr0BJdGIOViyH4PTx s/agZA== X-Received: by 2002:a05:600c:3544:b0:42c:b9c8:2bb0 with SMTP id 5b1f17b1804b1-436e26ae55bmr219983215e9.4.1736865111600; Tue, 14 Jan 2025 06:31:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IF+MO+XJS8R42YIa9fPKyqZ4Wfe4TQNB+tx4+SKWOGsMSJmUdaFk6mpj3tzWcCZTHziwJMqJA== X-Received: by 2002:a05:600c:3544:b0:42c:b9c8:2bb0 with SMTP id 5b1f17b1804b1-436e26ae55bmr219982815e9.4.1736865111099; Tue, 14 Jan 2025 06:31:51 -0800 (PST) Received: from localhost (44.226.159.143.dyn.plus.net. [143.159.226.44]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a8e4c1b2asm14599175f8f.89.2025.01.14.06.31.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 06:31:50 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Bernd Edlinger , Andrew Burgess Subject: [PATCHv3 0/2] Handle empty ranges for inline subroutines Date: Tue, 14 Jan 2025 14:31:47 +0000 Message-ID: X-Mailer: git-send-email 2.47.1 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: thPf6T-p9U5lFEpLJAguFtsiIqjQ3tIAVYCzDQmvAwM_1736865113 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_LOTSOFHASH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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~patchwork=sourceware.org@sourceware.org In v3: - Based on Linaro CI test failures: tests have been updated to handle targets which compile as PIE by default. In v2: - Rebased, resolved minor merge conflict. --- This patch draws inspiration from the work submitted here: https://inbox.sourceware.org/gdb-patches/AS1PR01MB946510286FBF2497A6F03E83E4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com Patches #2 and #3 from this original series deal with issues interpreting the DWARF around the end address of inline functions. There have been previous attempts to fix this problem: https://inbox.sourceware.org/gdb-patches/AM6PR03MB51709D8514A8796DB84D006DE4ED0@AM6PR03MB5170.eurprd03.prod.outlook.com https://inbox.sourceware.org/gdb-patches/AM0PR0602MB341029C1241395C969437ED3E4D80@AM0PR0602MB3410.eurprd06.prod.outlook.com https://inbox.sourceware.org/gdb-patches/HE1PR0602MB3417B82A6028274A529E6168E4D50@HE1PR0602MB3417.eurprd06.prod.outlook.com https://inbox.sourceware.org/gdb-patches/AM6PR03MB51707894C46730F4D2DD88A8E41E0@AM6PR03MB5170.eurprd03.prod.outlook.com https://inbox.sourceware.org/gdb-patches/AM6PR03MB51707FDDD28177A2B85DBE3BE4C40@AM6PR03MB5170.eurprd03.prod.outlook.com There have been a number of different approaches proposed over the years. From a user perspective, the problem being addressed by these patches is that GDB will sometimes fail to realise that the inferior is inside an inlined function when the inferior is positioned at the end of an inlined function. This can impact placing breakpoints within the inline function, and stepping through, and out of, inline functions. The problem is caused by the interaction of two DWARF elements, the inline functions address ranges, as defined within the DIE (including with DW_AT_ranges), and the line table. What is often observed is that the address range of an inline function doesn't include a particular address, however, within the line table, this same address is marked as is-stmt for lines within the inline function. This confuses GDB during stepping as from a block perspective, GDB will believe it has stepped out of the block, but from a line table perspective, GDB will report the line within the inline function. The most recent proposal creates a new line table attribute at the address where an inline functions end. This attribute is then used in various places within GDB to influence the block selection algorithm. The result is that GDB can, when stopped at an address, return a block which does not appear to contain the current address. There are then some follow on changes needed to handle the fact that the inferior can be considered inside a block, despite the inferior being stopped at an address outside the blocks address ranges. The results achieved by this patch are indeed impressive. The changes proposed in this patch actually handle two slightly different, but related cases. In some cases, for small inline functions, the compiler ends up reporting the inline function as having an empty address range. This case is particularly bad as with an empty address range GDB completely discards the block, and its associated symbols, which means the inline function appears to disappear completely, the user cannot place breakpoints on the function, nor will GDB notice when the inferior stops at the location of the inline function. The second case is a little better, but still has some serious issues. In this case the address range of the inline function appears truncated. The instruction, which is often tagged as is-stmt in the line table, corresponding to the 'return' line for the inline function, is not part of the inline function's address range. In this case GDB is able to place breakpoints on the inline function, but when stepping out of the inline function GDB will be confused by the block and line-table inconsistencies. However, despite the impressive results of the original patch, I worry that changing GDB's block lookup to return blocks which don't contain a particular address, is too great of a risk. I believe that the issues being addressed here can, and should, be addressed within GDB's DWARF parser, and that we should spot the problem cases and adjust the data to present a view of the world which works with GDB's existing data structures. For the empty address range issue I would suggest that a cleaner solution is to spot the problem case and make the address range of the block non-empty. After this GDB's existing algorithms will "just work". The second problem, that of block range truncation, is slightly harder to handle, but I think this can still be resolved by cross referencing the block address range with the line table, and, where appropriate, extending the address range of the block. Again, if this is done correctly then GDB's existing algorithms will "just work". This series sets out to only address the first problem, that of empty address ranges. This is the far easier case to handle, but also, has the largest impact. Inline functions with an empty address range disappear completely from GDB's world view, so fixing these immediately means that GDB will know of these functions, and can break on them. If this patch is accepted then I will follow up addressing the second issue, I have a very rough prototype of the fix for this case which appears to work, but it is a bigger task, so I wanted to see how this change is received first. However, if my idea of addressing the second issue doesn't materialise, the original patch series does still apply on top of this patch, I have done this merge and pushed it to sourceware in the users/aburgess/gdb-opt-code-debug branch. The second patch in this series was already posted as a stand-alone patch here: https://inbox.sourceware.org/gdb-patches/2fa8d328be94dff72ec7be0609ec799765894594.1722007578.git.aburgess@redhat.com There was some feedback on the tests given, which I believe I have addressed. There was also a concern that the patch would conflict with the original optimised code series, which the sourceware branch referenced above shows is not an issue. I look forward to peoples thoughts on this series, Thanks, Andrew -- Andrew Burgess (2): gdb: handle empty ranges for inline subroutines gdb: improve line number lookup around inline functions gdb/dwarf2/read.c | 71 ++++- gdb/symtab.c | 25 +- gdb/testsuite/gdb.cp/step-and-next-inline.exp | 145 +++++----- .../gdb.dwarf2/dw2-empty-inline-low-high.c | 39 +++ .../gdb.dwarf2/dw2-empty-inline-low-high.exp | 128 +++++++++ .../gdb.dwarf2/dw2-empty-inline-ranges.c | 54 ++++ .../gdb.dwarf2/dw2-empty-inline-ranges.exp | 261 ++++++++++++++++++ gdb/testsuite/gdb.dwarf2/dw2-inline-bt.c | 79 ++++++ gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp | 227 +++++++++++++++ .../gdb.dwarf2/dw2-unexpected-entry-pc.exp | 67 +++-- gdb/testsuite/gdb.opt/empty-inline-cxx.cc | 65 +++++ gdb/testsuite/gdb.opt/empty-inline-cxx.exp | 95 +++++++ gdb/testsuite/gdb.opt/empty-inline.c | 40 +++ gdb/testsuite/gdb.opt/empty-inline.exp | 115 ++++++++ gdb/testsuite/gdb.opt/inline-bt.c | 28 ++ gdb/testsuite/gdb.opt/inline-bt.exp | 127 ++++++--- 16 files changed, 1435 insertions(+), 131 deletions(-) create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-empty-inline-low-high.c create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-empty-inline-low-high.exp create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-empty-inline-ranges.c create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-empty-inline-ranges.exp create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-bt.c create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp create mode 100644 gdb/testsuite/gdb.opt/empty-inline-cxx.cc create mode 100644 gdb/testsuite/gdb.opt/empty-inline-cxx.exp create mode 100644 gdb/testsuite/gdb.opt/empty-inline.c create mode 100644 gdb/testsuite/gdb.opt/empty-inline.exp base-commit: 127f733f88717bdb52f03c12c0c2d240bbc892e3