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

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Bernd Edlinger <bernd.edlinger@hotmail.de> [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=<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.
> >>>