From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83033 invoked by alias); 6 Jan 2020 08:14:45 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 83001 invoked by uid 89); 6 Jan 2020 08:14:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=apologies, session, stage3, HX-Spam-Relays-External:sk:EUR01-D X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com Received: from mail-oln040092064102.outbound.protection.outlook.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (40.92.64.102) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Jan 2020 08:14:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RxRpBaqVPJM/RR0rJokm8/6dEJwLFMQ1C2MckHQD/T2x6v/P1Zd3Jw3ke7pz1wRA62YEZDCh+3Mw46xrVbX1TDzlekGLKGjr535pS+hOLYdGPTFTU9jka/+Q6MGzc7bcsvNf4nFQdwt+wdHULDZUefI1z8cVOZ2mmhS6I+PcL7I+5YtRC3K+txhfN4rKiyoUcmjwJ5FXqQs3rJqliMkfEM/+YmaeO85vLgkk5qK/bFPuEazNEyr0u/Qzw8MgzzS6WJRy72wHuAA5YypEqaPn/ALuelwFwtbIJrc9MoladJbGuzp641woLhcmRylEYSRHTaTfb0Thx9iClWmsbKYE8w== 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=GFgG1DasP3780kjnPKBztd+3teOuj3B98dkgd6JuJ9k=; b=MqjjjlIyaOqgizwgAry9IDZ/3C+nkqQAzRBOHkMymmVJXj9A5ZcAlJwMflE70WO6HcBIl9StwU7ry0d12emOE+vv42yn2Zogew7RAG/uXp8YGMgMBSn2A1KHVxqchyCNwV/OI4J85C1jK8Ke4IA26gQI5FuVqvZSui5tLPlgmhHb7+mtmt1MNH0A2BYJBshUvs9wIN/hBWeEnb5q55TuOrjimgRQfxsnSH8P6khr3R2SIPonPTbmqw/uiRixPUSLohgdRImpXbUzGOF11LlK3xwcWcqefYridPeEDC2iexqolsCYFwqpAQmypVJICxOPseV0vZZQ4JBy/6lwf39aBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR01FT064.eop-EUR01.prod.protection.outlook.com (10.152.0.59) by HE1EUR01HT118.eop-EUR01.prod.protection.outlook.com (10.152.0.237) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Mon, 6 Jan 2020 08:14:37 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.0.52) by HE1EUR01FT064.mail.protection.outlook.com (10.152.1.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Mon, 6 Jan 2020 08:14:37 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::c895:7517:78e7:1eac]) by AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::c895:7517:78e7:1eac%7]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 08:14:37 +0000 Received: from [192.168.1.101] (146.60.252.106) by FR2P281CA0013.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Mon, 6 Jan 2020 08:14:36 +0000 From: Bernd Edlinger To: "gdb-patches@sourceware.org" , Simon Marchi , Andrew Burgess Subject: [PING**3] [PATCH] Fix an issue with the gdb step-over aka. "n" command Date: Mon, 06 Jan 2020 08:14:00 -0000 Message-ID: References: In-Reply-To: x-microsoft-original-message-id: x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: <3C5B54719152E74595A871E5E73B3655@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2020-01/txt/msg00101.txt.bz2 Hi, I'd like to ping for this patch again. The latest version (including testcase + changelog) can be found here: https://sourceware.org/ml/gdb-patches/2019-12/msg01052.html Thanks Bernd. On 12/14/19 2:52 PM, Bernd Edlinger wrote: > Ping... >=20 > I'm pinging for this patch here: > https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html >=20 > Thanks > Bernd. >=20 > On 12/1/19 9:47 PM, Bernd Edlinger wrote: >> Ping... >> >> >> On 11/24/19 1:17 PM, Bernd Edlinger wrote: >>> 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 wi= th >>> 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=3Dt@entry=3D0x7ffff7ff7ab0) at ../../gcc= -trunk/gcc/alias.c:837 >>> 837 if (t =3D=3D error_mark_node >>> (gdb) n >>> 839 && (TREE_TYPE (t) =3D=3D 0 || TREE_TYPE (t) =3D=3D error_mark_no= de))) >>> (gdb) n >>> 3382 return __t; <-- now we have a problem: wrong line info here >>> (gdb) bt >>> #0 get_alias_set (t=3Dt@entry=3D0x7ffff7ff7ab0) at ../../gcc-trunk/gcc= /tree.h:3382 >>> #1 0x0000000000b25dfe in set_mem_attributes_minus_bitpos (ref=3D0x7fff= f746f990, t=3D0x7ffff7ff7ab0, objectp=3D1, bitpos=3D...) >>> at ../../gcc-trunk/gcc/emit-rtl.c:1957 >>> #2 0x0000000001137a55 in make_decl_rtl (decl=3D0x7ffff7ff7ab0) at ../.= ./gcc-trunk/gcc/varasm.c:1518 >>> #3 0x000000000113b6e8 in assemble_variable (decl=3D0x7ffff7ff7ab0, top= _level=3D, at_end=3D,=20 >>> dont_output_data=3D0) at ../../gcc-trunk/gcc/varasm.c:2246 >>> #4 0x000000000113f0ea in varpool_node::assemble_decl (this=3D0x7ffff74= 5b000) at ../../gcc-trunk/gcc/varpool.c:584 >>> #5 0x000000000113fa17 in varpool_node::assemble_decl (this=3D0x7ffff74= 5b000) 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 -gstateme= nt-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 n= ext >>> 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. >>>