[PING**3] [PATCH] Fix an issue with the gdb step-over aka. "n" command

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

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.
>>>