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

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

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