Message ID | VI1PR03MB4528BAD4E0EB8E72394FFCD8E44B0@VI1PR03MB4528.eurprd03.prod.outlook.com |
---|---|
State | New, archived |
Headers |
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: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> 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 <bernd.edlinger@hotmail.de> To: "gdb-patches@sourceware.org" <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: <VI1PR03MB4528BAD4E0EB8E72394FFCD8E44B0@VI1PR03MB4528.eurprd03.prod.outlook.com> x-microsoft-original-message-id: <88bc2bae-2bc7-375c-f279-7440628c0ac3@hotmail.de> x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_002_VI1PR03MB4528BAD4E0EB8E72394FFCD8E44B0VI1PR03MB4528eurp_" MIME-Version: 1.0 |
Commit Message
Bernd Edlinger
Nov. 24, 2019, 12:17 p.m. UTC
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=<optimized out>, at_end=<optimized out>, 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.
Comments
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 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=<optimized out>, at_end=<optimized out>, > 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. >
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... > > > 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=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=<optimized out>, at_end=<optimized out>, >> 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. >>
On 2019-11-24 7:17 a.m., 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=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=<optimized out>, at_end=<optimized out>, > 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 I have a hard time understanding what is going wrong and what we should see instead. I think it would help if you showed what's $pc at every place where you are stopping, as well as the output for readelf --debug-dump=decodedline for those regions. It would also help if you provided the same session without and with your patch applied, so we could see the difference. Simon
On 12/15/19 2:25 AM, Simon Marchi wrote: > On 2019-11-24 7:17 a.m., 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=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=<optimized out>, at_end=<optimized out>, >> 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 > > I have a hard time understanding what is going wrong and what we should see > instead. I think it would help if you showed what's $pc at every place where > you are stopping, as well as the output for readelf --debug-dump=decodedline > for those regions. It would also help if you provided the same session without > and with your patch applied, so we could see the difference. > Hi Simon, the issue is there is a line-info from the inline function right at the end of the inline superblock without any code just variable tacking info there. Maybe it helps to get the background if you look at my attempt of fixing this as a gcc bug: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html and Alexandre Oliva's response here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01771.html So this is a problem in the design of the dwarf line info which has stmt-type line info at the end of a inlined subroutine. Those fall outside the inline block, therefore the step over stops at the line where the inline function ends, and for gdb it just appears as if this line was in the calling subroutine, which happens since the line info does not have any connection to the inlined subroutine range info. Contents of the .debug_info section: <2><4f686>: Abbrev Number: 12 (DW_TAG_inlined_subroutine) <4f687> DW_AT_abstract_origin: <0x53d4e> <4f68b> DW_AT_entry_pc : 0x7280 <4f693> DW_AT_GNU_entry_view: 1 <4f695> DW_AT_ranges : 0xb480 <4f699> DW_AT_call_file : 8 <- alias.c <4f69a> DW_AT_call_line : 839 <4f69c> DW_AT_call_column : 8 <4f69d> DW_AT_sibling : <0x4f717> The File Name Table (offset 0x253): 8 2 0 0 alias.c 10 2 0 0 tree.h Contents of the .debug_ranges section: 0000b480 0000000000007280 0000000000007291 0000b480 0000000000002764 000000000000277e 0000b480 <End of list> The problem is at pc=0x7291 in the Line Number Section: Line Number Statements: [0x00008826] Special opcode 61: advance Address by 4 to 0x7284 and Line by 0 to 3380 [0x00008827] Set is_stmt to 1 [0x00008828] Special opcode 189: advance Address by 13 to 0x7291 and Line by 2 to 3382 (*) [0x00008829] Set is_stmt to 0 (**) [0x0000882a] Copy (view 1) [0x0000882b] Set File Name to entry 8 in the File Name Table <- back to alias.c [0x0000882d] Set column to 8 [0x0000882f] Advance Line by -2543 to 839 [0x00008832] Copy (view 2) [0x00008833] Set column to 27 [0x00008835] Special opcode 61: advance Address by 4 to 0x7295 and Line by 0 to 839 [0x00008836] Set column to 3 [0x00008838] Set is_stmt to 1 <-- next line info counts: alias.c:847 [0x00008839] Special opcode 153: advance Address by 10 to 0x729f and Line by 8 to 847 [0x0000883a] Set column to 7 (*) this line is tree.h:3382, but the program counter is *not* within the subroutine, but exactly at the first instruction *after* the subroutine according to the debug_ranges. What makes it worse, is that (**) makes gdb ignore the new location info alias.c:839, which means, normally the n command would have continued to pc=0x729f, which is at alias.c:847. What this patch does, is a heuristic, that means when the last satement line number (*) contains no code, and is followed by a non-statment line number in another file, then pretend the non-statement (**) was actually a stmt-type line number. By adding the end of sequence marker here this code in buildsym.c cancels the last line number in the inline file: /* Normally, we treat lines as unsorted. But the end of sequence marker is special. We sort line markers at the same PC by line number, so end of sequence markers (which have line == 0) appear first. This is right if the marker ends the previous function, and there is no padding before the next function. But it is wrong if the previous line was empty and we are now marking a switch to a different subfile. We must leave the end of sequence marker at the end of this group of lines, not sort the empty line to after the marker. The easiest way to accomplish this is to delete any empty lines from our table, if they are followed by end of sequence markers. All we lose is the ability to set breakpoints at some lines which contain no instructions anyway. */ if (line == 0 && subfile->line_vector->nitems > 0) { e = subfile->line_vector->item + subfile->line_vector->nitems - 1; while (subfile->line_vector->nitems > 0 && e->pc == pc) { e--; subfile->line_vector->nitems--; } } (That's where I discovered the line number 65535 issue BTW) Bernd.
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... > > 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... >> >> >> 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=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=<optimized out>, at_end=<optimized out>, >>> 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. >>>
* Bernd Edlinger <bernd.edlinger@hotmail.de> [2020-01-06 08:14:37 +0000]: > 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 I think we should investigate tracking the line table is_stmt property better, as I suggested in another mail in this thread. I see you've provided some feedback to the patch I posted, I just haven't had time to look at it yet, but will try to get to it as soon as I can. Thanks, Andrew > > Thanks > Bernd. > > On 12/14/19 2:52 PM, Bernd Edlinger wrote: > > 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... > >> > >> > >> 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=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=<optimized out>, at_end=<optimized out>, > >>> 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. > >>>
On 1/6/20 11:09 PM, Andrew Burgess wrote: > * Bernd Edlinger <bernd.edlinger@hotmail.de> [2020-01-06 08:14:37 +0000]: > >> 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 > > I think we should investigate tracking the line table is_stmt property > better, as I suggested in another mail in this thread. > Sure, no problem. I am fully aware that this is just a workaround. > I see you've provided some feedback to the patch I posted, I just > haven't had time to look at it yet, but will try to get to it as soon > as I can. > Thanks, one additional thought I had about your patch: I believe that we should also look at implementing the variable-location-views. I mean adding a view number to the record_line function. That would mean adding PC.view in the line table. That could in theory be used to find out if a location view is inside a subroutine or in the main program, even if the PC is the same, using the view number it would be possible to find that out. That would allow us to step to the return statement of the inline function if we are stepping in the inline function and to step over the whole inline if we want to. The only part that is really missing for that is the view number in addition to the PC where the inline function ends. Note there is already a view number where the inline starts: <2><918>: Abbrev Number: 43 (DW_TAG_inlined_subroutine) <919> DW_AT_abstract_origin: <0x9b5> <91d> DW_AT_entry_pc : 0x40117b <925> DW_AT_GNU_entry_view: 0 <926> DW_AT_low_pc : 0x40117b <92e> DW_AT_high_pc : 0xa <936> DW_AT_call_file : 1 <937> DW_AT_call_line : 24 <938> DW_AT_call_column : 10 <939> DW_AT_sibling : <0x965> conceptually the subroutine starta at DW_AT_entry_pc/DW_AT_GNU_entry_view and ends at DW_AT_high_pc/<end view number>, but the end view number is not yet specified. That IMHO is what should be added here. Bernd.
From 18017c39f9598dcd8e3204afd624afd2ac723301 Mon Sep 17 00:00:00 2001 From: Bernd Edlinger <bernd.edlinger@hotmail.de> 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