From patchwork Sun Nov 24 12:17:45 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 36162 Received: (qmail 28278 invoked by alias); 24 Nov 2019 12:17:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 28270 invoked by uid 89); 24 Nov 2019 12:17:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-17.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy=UD:dwarf2read.c, Breakpoint, dwarf2readc, dwarf2read.c X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Received: from mail-oln040092067028.outbound.protection.outlook.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (40.92.67.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Nov 2019 12:17:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MDpOvYmbq06R5nDgGqMMHXupMWBZS5EtZh77s/dnrdedug80LUgn3X8/nT+WjXTCt/ij1nyucutFcZue0CpDKX5gB3R7zWL581Hd/P5q5vAd2CqUntHekLBgyUIQIlQP/F9+18zGIv0rD0JJIzOnXxpC0Y1SqhsEq0i9d7PZdXdt6gGiUQ21Gwc4a0YTiAWIEbiP5Dy+YIckS4rSgVjJaGJMpLD7wpfEZqbCoamqDIhHuOZ/zgHeiyuGQEDbqUDs7n8jyGRj8UyV2ESA+NJFcSBxjaE1to0hhIaDZBBCeh9uq0w7tfTg4eXIpDsQUMt/xCmHz5rksx6Vwxjnd/cMZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M63voFh0NYHcqD/PDrp3xRHdtyONH0wTSEBhBM4ekXk=; b=dQRXcJMMe1Yst3PAyfYPqnf7zUMlO5E8IwCHiFSB/7kIOUnQxLOd7Iikys9d6BDMAagZCJeVmDTNJ63G7T8LlnCOlVsyNybF8z9EOc6Qqyi/2aFkIy++wHPAPjJfbGbNoxTz5+vKDbceUpHOqtEqBGBYHozFLnlf6GcXhhOqLNmldSYeCBCRBm/5VNFzsBM9HbqJ4GTVK6asml3wqRm1TpWrj+/Ep4UFmXzGpGK5AI6RfhuRkcejhB2NgGnItIZj3ALpZCX3UnIFEoIOVKSOeEu4Oy0e6Fucwgab/DOcrqRVgWvkltLYZY0r+MxKjdqiBFNkbLAWY+pyz5uw+3D+kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM5EUR02FT060.eop-EUR02.prod.protection.outlook.com (10.152.8.51) by AM5EUR02HT190.eop-EUR02.prod.protection.outlook.com (10.152.9.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17; Sun, 24 Nov 2019 12:17:46 +0000 Received: from VI1PR03MB4528.eurprd03.prod.outlook.com (10.152.8.60) by AM5EUR02FT060.mail.protection.outlook.com (10.152.9.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17 via Frontend Transport; Sun, 24 Nov 2019 12:17:45 +0000 Received: from VI1PR03MB4528.eurprd03.prod.outlook.com ([fe80::49b8:a7e6:9f6f:862d]) by VI1PR03MB4528.eurprd03.prod.outlook.com ([fe80::49b8:a7e6:9f6f:862d%3]) with mapi id 15.20.2474.023; Sun, 24 Nov 2019 12:17:46 +0000 From: Bernd Edlinger To: "gdb-patches@sourceware.org" Subject: [PATCH] Fix an issue with the gdb step-over aka. "n" command Date: Sun, 24 Nov 2019 12:17:45 +0000 Message-ID: x-microsoft-original-message-id: <88bc2bae-2bc7-375c-f279-7440628c0ac3@hotmail.de> x-ms-exchange-transport-forked: True MIME-Version: 1.0 Hi, this fixes an issue with the gdb step-over aka. "n" command. Apologies, the motivation for this patch was from sub-optimal debug experience using some gcc code involving inlined functions, and initially I tried to convince gcc folks that it is in fact a gcc bug, but... It can be seen when you debug an optimized stage-3 cc1 it does not affect -O0 code, though. Note: you can use "gcc -S hello.c -wrapper gdb,--args" to invoke cc1 with debugger attached. This example debug session will explain the effect. (gdb) b get_alias_set Breakpoint 5 at 0xa099f0: file ../../gcc-trunk/gcc/alias.c, line 837. (gdb) r Breakpoint 5, get_alias_set (t=t@entry=0x7ffff7ff7ab0) at ../../gcc-trunk/gcc/alias.c:837 837 if (t == error_mark_node (gdb) n 839 && (TREE_TYPE (t) == 0 || TREE_TYPE (t) == error_mark_node))) (gdb) n 3382 return __t; <-- now we have a problem: wrong line info here (gdb) bt #0 get_alias_set (t=t@entry=0x7ffff7ff7ab0) at ../../gcc-trunk/gcc/tree.h:3382 #1 0x0000000000b25dfe in set_mem_attributes_minus_bitpos (ref=0x7ffff746f990, t=0x7ffff7ff7ab0, objectp=1, bitpos=...) at ../../gcc-trunk/gcc/emit-rtl.c:1957 #2 0x0000000001137a55 in make_decl_rtl (decl=0x7ffff7ff7ab0) at ../../gcc-trunk/gcc/varasm.c:1518 #3 0x000000000113b6e8 in assemble_variable (decl=0x7ffff7ff7ab0, top_level=, at_end=, dont_output_data=0) at ../../gcc-trunk/gcc/varasm.c:2246 #4 0x000000000113f0ea in varpool_node::assemble_decl (this=0x7ffff745b000) at ../../gcc-trunk/gcc/varpool.c:584 #5 0x000000000113fa17 in varpool_node::assemble_decl (this=0x7ffff745b000) at ../../gcc-trunk/gcc/varpool.c:750 The reason for this is a line number information that is exactly at the end of the inlined function, but there is no code at that place, only variable values (views) are declared there. Unfortunately the next instruction is again in the main program, but due to -gstatement-frontiers those do not have the is_stmt and are completely ignored by gdb at the moment. This patch fixes the effect by rewriting the is_stmt attribute of the next location info under certain conditions. I have no idea how to write a test case for this since it happens only in optimized code, and only under very special conditions. Thanks Bernd. From 18017c39f9598dcd8e3204afd624afd2ac723301 Mon Sep 17 00:00:00 2001 From: Bernd Edlinger Date: Sat, 23 Nov 2019 20:59:25 +0100 Subject: [PATCH] Fix an issue with the gdb step-over aka. "n" command When debugging optimized code with inlined functions built with -gstatement-frontiers debug info, it may happen that an inline function has a line location exactly at the end of a block which has the is_stmt attribute set, followed by a location info which is at the call site but has the is_stmt attribute cleared and is therefore ignored. The visual effect is that "n" does sometimes not step over the inlined function but instead jumps to the last line of the inline function, but the inline function has already returned, hence the line number information is inconsistent at this point. This patch detects a is_stmt location info followed by a location info in a different file at the same address, but without is_stmt location set, and forces the second location info to replace the previous one. --- gdb/dwarf2read.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index 1ca801c..a7c4c8e 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -20915,6 +20915,7 @@ private: example, when discriminators are present. PR 17276. */ unsigned int m_last_line = 0; bool m_line_has_non_zero_discriminator = false; + CORE_ADDR m_last_address = (CORE_ADDR) -1; }; void @@ -21097,7 +21098,10 @@ lnp_state_machine::record_line (bool end_sequence) else if (m_op_index == 0 || end_sequence) { fe->included_p = 1; - if (m_record_lines_p && (producer_is_codewarrior (m_cu) || m_is_stmt)) + if (m_record_lines_p + && (producer_is_codewarrior (m_cu) || m_is_stmt || end_sequence + || (m_last_subfile != m_cu->get_builder ()->get_current_subfile () + && m_last_address == m_address))) { if (m_last_subfile != m_cu->get_builder ()->get_current_subfile () || end_sequence) @@ -21120,6 +21124,7 @@ lnp_state_machine::record_line (bool end_sequence) } m_last_subfile = m_cu->get_builder ()->get_current_subfile (); m_last_line = m_line; + m_last_address = m_address; } } } -- 1.9.1