From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66854 invoked by alias); 15 Dec 2019 01:25:21 -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 66846 invoked by uid 89); 15 Dec 2019 01:25:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=showed, H*c:windows-1252 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 15 Dec 2019 01:25:19 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BF3E51E50B; Sat, 14 Dec 2019 20:25:17 -0500 (EST) Subject: Re: [PATCH] Fix an issue with the gdb step-over aka. "n" command To: Bernd Edlinger , "gdb-patches@sourceware.org" References: From: Simon Marchi Message-ID: Date: Sun, 15 Dec 2019 01:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-12/txt/msg00678.txt.bz2 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=, 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 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