From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26843 invoked by alias); 15 Dec 2019 08:39:35 -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 26832 invoked by uid 89); 15 Dec 2019 08:39:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=sk:dw_at_c, sk:DW_AT_c, Advance X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092066083.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (40.92.66.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 15 Dec 2019 08:39:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GXmi4YShC2XHB5nwVKACTMbftil9NmaRMN6ckm6akzTiyGh6xarbj+3a7ovj50eFBvK5Cj5kn/wnEdll3c/mlzP0RNDBcvaExeU2WnFAciVaTwjzZ756AUt97IqaXZS30NAFk18smdGBAa6E1zuOLnAwZ8DQGJ4CqYIZb5/88xFTWcflT62gfEv31LEpBQWq9a+HkhCGOdnMtzRAPiHxlPShl+fGP0iaVPg4PSKd414EbmKsbp3429ZOwQUhf+9Ctbrc3I1j0FWFsNqV2WjA0qVF8nMB3P+h1zDy0WiCU0ae5HZTvclYDtbbYZb32juS2HWzdXyGUSiGyuSDp8eG7Q== 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=hHwSKm57xCIWyK4uSeWs/IIHIpNKiggUuKDq6HAquDA=; b=GhHhF2z1cJytZRcL+bpzPR6BUeLsWNVBrE/NfJATeibIx8i+H1F2gjt321nkO5/KuTaVxxWRwki0R+Ed0fFzo7RC5KoEaOm3ces1Z4F66vQ9B5RrDRDmOIbEhQvRQKFKexJ/faWMiQ9todrJgHH+3270xukwMjKnRRLXWx96qJi5PCJz9r9CNwE9fvp19CzLlZAh5hL0zvcxANh+1czHk2MnjScvSG3CF9L864Inr/Nt8qGPYE5Zc/h4D0DifVYaCo+LTOFTWlqQBfYJJnb8lhGcZQr9JeYtJ1SUR24HAEOFh9jT525xWWMGo1MK9VZvQDXZvj6CyPIMP1GMzGbjhw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB5EUR01FT061.eop-EUR01.prod.protection.outlook.com (10.152.4.53) by DB5EUR01HT050.eop-EUR01.prod.protection.outlook.com (10.152.4.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14; Sun, 15 Dec 2019 08:39:29 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.4.60) by DB5EUR01FT061.mail.protection.outlook.com (10.152.5.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14 via Frontend Transport; Sun, 15 Dec 2019 08:39:29 +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; Sun, 15 Dec 2019 08:39:29 +0000 From: Bernd Edlinger To: Simon Marchi , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Fix an issue with the gdb step-over aka. "n" command Date: Sun, 15 Dec 2019 08:39: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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg00685.txt.bz2 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=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 >=20 > I have a hard time understanding what is going wrong and what we should s= ee > instead. I think it would help if you showed what's $pc at every place w= here > you are stopping, as well as the output for readelf --debug-dump=3Ddecode= dline > for those regions. It would also help if you provided the same session w= ithout > and with your patch applied, so we could see the difference. >=20 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 th= is 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=20 0000b480 0000000000002764 000000000000277e=20 0000b480 The problem is at pc=3D0x7291 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 Lin= e 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 Lin= e by 8 to 847 [0x0000883a] Set column to 7 (*) this line is tree.h:3382, but the program counter is *not* within the s= ubroutine, but exactly at the first instruction *after* the subroutine according to th= e debug_ranges. What makes it worse, is that (**) makes gdb ignore the new location info al= ias.c:839, which means, normally the n command would have continued to pc=3D0x729f, wh= ich is at alias.c:847. What this patch does, is a heuristic, that means when the last satement lin= e 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 ad= ding the end of sequence marker here this code in buildsym.c cancels the last line n= umber 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 =3D=3D 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 =3D=3D 0 && subfile->line_vector->nitems > 0) { e =3D subfile->line_vector->item + subfile->line_vector->nitems - 1; while (subfile->line_vector->nitems > 0 && e->pc =3D=3D pc) { e--; subfile->line_vector->nitems--; } } (That's where I discovered the line number 65535 issue BTW) Bernd.