From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1698 invoked by alias); 1 Dec 2019 20:47:20 -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 1690 invoked by uid 89); 1 Dec 2019 20:47:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 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, aka X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092066040.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (40.92.66.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 01 Dec 2019 20:47:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VWRTkpc2Vd0NdgXBe9BByCGNJ4TcbWTtAOuGhykG/CRetcgG9iqmBof1KLKiz/+bh0pMbSOlLFXF4OVIV73qi6Eh7P77cPdRNfvf3fzmuf6F6+SCjLQuNjeaMP6hydXWs6AgZ896ZHniCJVk3X/ABj6EHHqEjzW3ZJlE73QStSSIdZ9/+oBmWFYqZKMWG4LsRSbLX2sOmIIUK/mf46RlFsAYA4rwBJoVpyxuRlWO/p6yKMmfvtAZ3qArbX4x0rzJfXuv9j+94HyEdK0iHa0CdUBIMxFjiuIP6jpjzm6QLGgYZMidDCT8fK2kACWnDtHzzepaKQ7CF7BBrwWRf5GTUA== 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=k1wJQFtm2IU2sNOdwTCl/MPMqkaW0Pw2nAJsicgeYsc=; b=eJK4UisSOismIo5Czu2qXul3DU2DCCUbA6ZZlevp7xXTGHg+WTXA8BrVFcfCbhpvIHHfdIRoYDZkAOzQbzmGa7U7vKwBE/59vWrbu2yU6oUhazo7f7R8vGohMfSnc8h8VtjnErzMq3ZLwsJpoal/I46KbN2+K3XTuA67MdlbtrTOticYV7FLwYQK8zLnOlHz9r6qiBe2zAOFL71LF+miObo7lEdxDnuq+z3VWGkuQ9Inbqa9ATu6e1TD5Ft7wOYxO9LlKMEJbYgsfVYc/FhSd7E4Px/JWvp3AtGOrOMMwc3NOnklQqrhYPeJq1WdKPN3qiu2vVGWIRxN8+tM80Hvgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB5EUR01FT050.eop-EUR01.prod.protection.outlook.com (10.152.4.56) by DB5EUR01HT229.eop-EUR01.prod.protection.outlook.com (10.152.5.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Sun, 1 Dec 2019 20:47:15 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (10.152.4.59) by DB5EUR01FT050.mail.protection.outlook.com (10.152.5.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18 via Frontend Transport; Sun, 1 Dec 2019 20:47:15 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::5861:779d:3997:2e70]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::5861:779d:3997:2e70%7]) with mapi id 15.20.2495.014; Sun, 1 Dec 2019 20:47:15 +0000 From: Bernd Edlinger To: "gdb-patches@sourceware.org" Subject: [PING] [PATCH] Fix an issue with the gdb step-over aka. "n" command Date: Sun, 01 Dec 2019 20:47: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: <7FFC3B48CF33504C82F520B869C8ABC1@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg00028.txt.bz2 Ping... On 11/24/19 1:17 PM, Bernd Edlinger wrote: > Hi, >=20 > this fixes an issue with the gdb step-over aka. "n" command. >=20 > 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... >=20 > It can be seen when you debug an optimized stage-3 cc1 > it does not affect -O0 code, though. >=20 > Note: you can use "gcc -S hello.c -wrapper gdb,--args" to invoke cc1 with > debugger attached. >=20 > This example debug session will explain the effect. >=20 > (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-t= runk/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_node= ))) > (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/t= ree.h:3382 > #1 0x0000000000b25dfe in set_mem_attributes_minus_bitpos (ref=3D0x7ffff7= 46f990, 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_l= evel=3D, at_end=3D,=20 > dont_output_data=3D0) at ../../gcc-trunk/gcc/varasm.c:2246 > #4 0x000000000113f0ea in varpool_node::assemble_decl (this=3D0x7ffff745b= 000) at ../../gcc-trunk/gcc/varpool.c:584 > #5 0x000000000113fa17 in varpool_node::assemble_decl (this=3D0x7ffff745b= 000) at ../../gcc-trunk/gcc/varpool.c:750 >=20 > 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 mo= ment. >=20 >=20 > This patch fixes the effect by rewriting the is_stmt attribute of the next > location info under certain conditions. >=20 > 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. >=20 >=20 > Thanks > Bernd. >=20