From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93898 invoked by alias); 14 Dec 2019 13:52: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 93890 invoked by uid 89); 14 Dec 2019 13:52:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 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=gcctrunk, gcc-trunk, ping**2, HX-Spam-Relays-External:sk:HE1EUR0 X-HELO: EUR02-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092069023.outbound.protection.outlook.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (40.92.69.23) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Dec 2019 13:52:17 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jwULmic53CJHBSVjJJ6tuwBxNRpOCWRfQfL0mS8JOdIDezf0xWoR4BPq/UUukeIY4Ay4rM/2vwXz1E+KSpqnWtl5kGNciNB4F+VyBp5pfZ+k2K6OlkljfLVmQ7+d/n22LrHnBe72d6oUqKYgtJpxiPpgkC2bZ6yPibyEXtBOQuaXgwm9mcd6J3rCi1I+kSFoQR8G2BHhU4QGCKv3RCn3Mix5Om69/nzu8/059pa/8GAe3mrgCK6rwg1tw1h8+QwtP/5SJw4Q2eASQzKsggRr35mtTzfDm8b4kSEKQxLNF5+9eAaox3ltanYXT+FPeh8pBNmeUpzMeZzsl85BkDkPOQ== 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=aI4H9enCI81s7gEf4QuK+em/SYpk4n7m7FIyxu5OcTo=; b=WTSgEcjAfdz5hcKS3EJnhiBym1t3uX7bRhkGPTlEmNYcW0wrb3FPU81gSDR6OEkRQFY+EZwm3NtPCn52JRANKvnnk4p+E/gOoa7lbI4dKmBj6vpAMFENkjT1ZZJqw6+KWJqotWxcmMXRQjXtVM7U+YaDohFNZSKsVonuL/MC2gQq3Da7oakTOxRTVUgc4gY+TZZV13zQext4teDEMyOcKNkVTOlOB8aXIGOSXm9RQyXl+AcMQbl1qUht6td+eqShQBXtszBdO73ILa9NKjH3pJAV/JtAG9A8H8zDQtxD/AXX3yANIl6FbarPsNLhfgowuv8opXyTqlUVAnGWrdIU0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR02FT016.eop-EUR02.prod.protection.outlook.com (10.152.10.60) by HE1EUR02HT243.eop-EUR02.prod.protection.outlook.com (10.152.10.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14; Sat, 14 Dec 2019 13:52:13 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.10.53) by HE1EUR02FT016.mail.protection.outlook.com (10.152.10.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14 via Frontend Transport; Sat, 14 Dec 2019 13:52:13 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769]) by AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769%7]) with mapi id 15.20.2538.019; Sat, 14 Dec 2019 13:52:13 +0000 From: Bernd Edlinger To: "gdb-patches@sourceware.org" Subject: [PING**2] [PATCH] Fix an issue with the gdb step-over aka. "n" command Date: Sat, 14 Dec 2019 13:52:00 -0000 Message-ID: References: In-Reply-To: x-microsoft-original-message-id: <2c4c0c1d-a949-d52d-856e-9a027979e9bf@hotmail.de> x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg00659.txt.bz2 Ping... I'm pinging for this patch here: https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html Thanks Bernd. On 12/1/19 9:47 PM, Bernd Edlinger wrote: > Ping... >=20 >=20 > 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 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=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_nod= e))) >> (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=3D0x7ffff= 746f990, 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=3D0x7ffff745= b000) at ../../gcc-trunk/gcc/varpool.c:584 >> #5 0x000000000113fa17 in varpool_node::assemble_decl (this=3D0x7ffff745= b000) 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 -gstatemen= t-frontiers >> those do not have the is_stmt and are completely ignored by gdb at the m= oment. >> >> >> This patch fixes the effect by rewriting the is_stmt attribute of the ne= xt >> location info under certain conditions. >> >> I have no idea how to write a test case for this since it happens only i= n optimized code, >> and only under very special conditions. >> >> >> Thanks >> Bernd. >>