[PING^2][PATCH][gdb/breakpoints] Workaround missing line-table entry

[Tom de Vries <tdevries@suse.de>]

On 2/5/21 11:07 AM, Tom de Vries wrote:
> On 1/22/21 10:15 AM, Tom de Vries wrote:
>> Hi,
>>
>> When running test-case gdb.opt/inline-cmds.exp, we run into this KFAIL with
>> gcc:
>> ...
>> Breakpoint 7, main () at gdb.opt/inline-cmds.c:71^M
>> 71        result = 0; /* set breakpoint 3 here */^M
>> (gdb) PASS: gdb.opt/inline-cmds.exp: continue to breakpoint: consecutive func1
>> next^M
>> 73        func1 (); /* first call */^M
>> (gdb) PASS: gdb.opt/inline-cmds.exp: next to first func1
>> next^M
>> 75        marker ();^M
>> (gdb) KFAIL: gdb.opt/inline-cmds.exp: next to second func1 (PRMS: gdb/25884)
>> ...
>> while with clang we have instead:
>> ...
>> next^M
>> 74        func1 (); /* second call */^M
>> (gdb) PASS: gdb.opt/inline-cmds.exp: next to second func1
>> ...
>>
>> The relevant bit of the test source is here in inline-cmds.c:
>> ...
>>     71    result = 0; /* set breakpoint 3 here */
>>     72
>>     73    func1 (); /* first call */
>>     74    func1 (); /* second call */
>>     75    marker ();
>> ...
>> with func1 defined as:
>> ...
>>     33  inline __attribute__((always_inline)) int func1(void)
>>     34  {
>>     35    bar ();
>>     36    return x * y;
>>     37  }
>> ...
>>
>> The corresponding insns are:
>> ...
>>   40050b:       movl   $0x0,0x200b1f(%rip)        # 601034 <result>
>>   400515:       callq  40057b <bar>
>>   40051a:       callq  40057b <bar>
>>   40051f:       callq  400596 <marker>
>> ...
>> and the line number info is:
>> ...
>> Line number    Starting address    View    Stmt
>>          71            0x40050b               x
>>          35            0x400515               x
>>          75            0x40051f               x
>> ...
>>
>> The line number info is missing an entry for the insn at 40051a, and that is
>> causing the FAIL.  This is a gcc issue, filed as PR gcc/98780 -" Missing line
>> table entry for inlined stmt at -g -O0".
>>
>> [ For contrast, with clang we have an extra entry:
>> ...
>> Line number    Starting address    View    Stmt
>>          71            0x40050b               x
>>          35            0x400515               x
>>          35            0x40051a
>>          75            0x40051f               x
>> ...
>> though it appears to be missing the start-of-statement marker. ]
>>
>> However, there is debug info that indicates that the insn at 40051a is not
>> part of the line table entry for the insn at 400515:
>> ...
>> <2><1c4>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
>>     <1c5>   DW_AT_abstract_origin: <0x2a2>
>>     <1c9>   DW_AT_low_pc      : 0x400515
>>     <1d1>   DW_AT_high_pc     : 0x5
>>     <1d9>   DW_AT_call_file   : 1
>>     <1da>   DW_AT_call_line   : 73
>>  <2><1db>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
>>     <1dc>   DW_AT_abstract_origin: <0x2a2>
>>     <1e0>   DW_AT_low_pc      : 0x40051a
>>     <1e8>   DW_AT_high_pc     : 0x5
>>     <1f0>   DW_AT_call_file   : 1
>>     <1f1>   DW_AT_call_line   : 74
>> ...
>> and indeed lldb manages to "next" from line 73 to line 74.
>>
>> Work around the missing line table entry, by using the inline frame info to
>> narrow the stepping range in prepare_one_step.
>>
>> Tested on x86_64-linux.
>>
>> Any comments?
>>

Ping.

Thanks,
- Tom

>> [gdb/breakpoints] Workaround missing line-table entry
>>
>> gdb/ChangeLog:
>>
>> 2021-01-22  Tom de Vries  <tdevries@suse.de>
>>
>> 	PR breakpoints/25884
>> 	* infcmd.c (prepare_one_step): Using inline frame info to narrow
>> 	stepping range.
>>
>> gdb/testsuite/ChangeLog:
>>
>> 2021-01-22  Tom de Vries  <tdevries@suse.de>
>>
>> 	PR breakpoints/25884
>> 	* gdb.opt/inline-cmds.exp: Remove kfail.
>>
>> ---
>>  gdb/infcmd.c                          | 14 ++++++++++++++
>>  gdb/testsuite/gdb.opt/inline-cmds.exp | 17 +----------------
>>  2 files changed, 15 insertions(+), 16 deletions(-)
>>
>> diff --git a/gdb/infcmd.c b/gdb/infcmd.c
>> index 6f0ed952de6..ecb3de31879 100644
>> --- a/gdb/infcmd.c
>> +++ b/gdb/infcmd.c
>> @@ -1009,6 +1009,20 @@ prepare_one_step (thread_info *tp, struct step_command_fsm *sm)
>>  				 &tp->control.step_range_start,
>>  				 &tp->control.step_range_end);
>>  
>> +	  /* There's a problem in gcc (PR gcc/98780) that causes missing line
>> +	     table entries, which results in a too large stepping range.
>> +	     Use inlined_subroutine info to make the range more narrow.  */
>> +	  if (inline_skipped_frames (tp) > 0)
>> +	    {
>> +	      symbol *sym = inline_skipped_symbol (tp);
>> +	      if (SYMBOL_CLASS (sym) == LOC_BLOCK)
>> +		{
>> +		  const block *block = SYMBOL_BLOCK_VALUE (sym);
>> +		  if (BLOCK_END (block) < tp->control.step_range_end)
>> +		    tp->control.step_range_end = BLOCK_END (block);
>> +		}
>> +	    }
>> +
>>  	  tp->control.may_range_step = 1;
>>  
>>  	  /* If we have no line info, switch to stepi mode.  */
>> diff --git a/gdb/testsuite/gdb.opt/inline-cmds.exp b/gdb/testsuite/gdb.opt/inline-cmds.exp
>> index 17720c46795..981dcbb4a29 100644
>> --- a/gdb/testsuite/gdb.opt/inline-cmds.exp
>> +++ b/gdb/testsuite/gdb.opt/inline-cmds.exp
>> @@ -222,22 +222,7 @@ gdb_breakpoint $line3
>>  gdb_continue_to_breakpoint "consecutive func1"
>>  
>>  gdb_test "next" ".*func1 .*first call.*" "next to first func1"
>> -set msg "next to second func1"
>> -gdb_test_multiple "next" $msg {
>> -    -re ".*func1 .*second call.*$gdb_prompt $" {
>> -	pass $msg
>> -    }
>> -    -re ".*marker .*$gdb_prompt $" {
>> -	# This assembles to two consecutive call instructions.
>> -	# Both appear to be at the same line, because they're
>> -	# in the body of the same inlined function.  This is
>> -	# reasonable for the line table.  GDB should take the
>> -	# containing block and/or function into account when
>> -	# deciding how far to step.  The single line table entry
>> -	# is actually two consecutive instances of the same line.
>> -	kfail gdb/25884 $msg
>> -    }
>> -}
>> +gdb_test "next" ".*func1 .*second call.*" "next to second func1"
>>  
>>  # It is easier when the two inlined functions are not on the same line.
>>  set line4 [gdb_get_line_number "set breakpoint 4 here"]
>>