From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111645 invoked by alias); 6 Jan 2020 22:09:31 -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 111637 invoked by uid 89); 6 Jan 2020 22:09:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Jan 2020 22:09:29 +0000 Received: by mail-wm1-f65.google.com with SMTP id m24so16776333wmc.3 for ; Mon, 06 Jan 2020 14:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yknZF8iMG5tCSASiBpHR6xQkb0Nf+oXYzvf0dFdgkxY=; b=dp4e7E9nMa2WYvQng6ZwypXT8nSQ8h+VmpIL0mV0dmegNw+Bf9a1GVc4bVaSinlPAS EhMrmFttvQL93Ywi6YvuCSF+7Degh6KsDOKIjCG5XMbBlDMFoj/AYVxkprlOyxyaVNoG U6I0sYsWJjgRqDjAamwzWVi9WmjQJ5tvZ6waEY0YKx++UgbC4y1sPnj0uSSP5qw4F9oB 7t3bMZqC22+EpmitiMOwtszDA5rJX3+dPsAA4yfuGVINK283xjauRUKqqf7/pLTWTTka FvGwS8YNwc7uFvNBoGclqjF3igD4/gjGUg2ywjNbfC1lLr8aKTagsfv5t0rctM2i9AkW 0Unw== Return-Path: Received: from localhost (host86-186-80-236.range86-186.btcentralplus.com. [86.186.80.236]) by smtp.gmail.com with ESMTPSA id g18sm23936525wmh.48.2020.01.06.14.09.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Jan 2020 14:09:26 -0800 (PST) Date: Mon, 06 Jan 2020 22:09:00 -0000 From: Andrew Burgess To: Bernd Edlinger Cc: "gdb-patches@sourceware.org" , Simon Marchi Subject: Re: [PING**3] [PATCH] Fix an issue with the gdb step-over aka. "n" command Message-ID: <20200106220925.GU3865@embecosm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: People who push both buttons should get their wish. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00134.txt.bz2 * Bernd Edlinger [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=, at_end=, > >>> 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. > >>>