This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PING**3] [PATCH] Fix an issue with the gdb step-over aka. "n" command
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Simon Marchi <simark at simark dot ca>, Andrew Burgess <andrew dot burgess at embecosm dot com>
- Date: Mon, 6 Jan 2020 08:14:37 +0000
- Subject: [PING**3] [PATCH] Fix an issue with the gdb step-over aka. "n" command
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- 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=GFgG1DasP3780kjnPKBztd+3teOuj3B98dkgd6JuJ9k=; b=MqjjjlIyaOqgizwgAry9IDZ/3C+nkqQAzRBOHkMymmVJXj9A5ZcAlJwMflE70WO6HcBIl9StwU7ry0d12emOE+vv42yn2Zogew7RAG/uXp8YGMgMBSn2A1KHVxqchyCNwV/OI4J85C1jK8Ke4IA26gQI5FuVqvZSui5tLPlgmhHb7+mtmt1MNH0A2BYJBshUvs9wIN/hBWeEnb5q55TuOrjimgRQfxsnSH8P6khr3R2SIPonPTbmqw/uiRixPUSLohgdRImpXbUzGOF11LlK3xwcWcqefYridPeEDC2iexqolsCYFwqpAQmypVJICxOPseV0vZZQ4JBy/6lwf39aBQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RxRpBaqVPJM/RR0rJokm8/6dEJwLFMQ1C2MckHQD/T2x6v/P1Zd3Jw3ke7pz1wRA62YEZDCh+3Mw46xrVbX1TDzlekGLKGjr535pS+hOLYdGPTFTU9jka/+Q6MGzc7bcsvNf4nFQdwt+wdHULDZUefI1z8cVOZ2mmhS6I+PcL7I+5YtRC3K+txhfN4rKiyoUcmjwJ5FXqQs3rJqliMkfEM/+YmaeO85vLgkk5qK/bFPuEazNEyr0u/Qzw8MgzzS6WJRy72wHuAA5YypEqaPn/ALuelwFwtbIJrc9MoladJbGuzp641woLhcmRylEYSRHTaTfb0Thx9iClWmsbKYE8w==
- References: <VI1PR03MB4528BAD4E0EB8E72394FFCD8E44B0@VI1PR03MB4528.eurprd03.prod.outlook.com> <VI1PR08MB53255D700F9B4144C22FC0E8E4400@VI1PR08MB5325.eurprd08.prod.outlook.com> <AM0PR08MB37142FA70A37821E55078F0EE4570@AM0PR08MB3714.eurprd08.prod.outlook.com>
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.
>>>