[Bug symtab/25884] New: Stepping over inlined function without line number statement fails

[Bug symtab/25884] New: Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

            Bug ID: 25884
           Summary: Stepping over inlined function without line number
                    statement fails
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With test-case gdb.opt/inline-cmds.exp, we have:
...
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/NNNN)
...

In contrast, with clang, we have:
...
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
74        func1 (); /* second call */^M
(gdb) PASS: gdb.opt/inline-cmds.exp: next to second func1
...

The difference seems to be that with clang, for these instructions:
...
  400520:       c7 04 25 34 10 60 00    movl   $0x0,0x601034
  400527:       00 00 00 00
  40052b:       c7 04 25 34 10 60 00    movl   $0x0,0x601034
  400532:       00 00 00 00
  400536:       e8 75 00 00 00          callq  4005b0 <bar>
  40053b:       e8 70 00 00 00          callq  4005b0 <bar>
  400540:       e8 8b 00 00 00          callq  4005d0 <marker>
...
we have line number statements for both calls to bar:
...
  [0x0000018a]  Special opcode 77: advance Address by 5 to 0x400520 and Line by
2 to 70
  [0x0000018b]  Special opcode 160: advance Address by 11 to 0x40052b and Line
by 1 to 71
  [0x0000018c]  Set column to 3
  [0x0000018e]  Advance Line by -36 to 35
  [0x00000190]  Special opcode 159: advance Address by 11 to 0x400536 and Line
by 0 to 35
  [0x00000191]  Set is_stmt to 0
  [0x00000192]  Special opcode 75: advance Address by 5 to 0x40053b and Line by
0 to 35
  [0x00000193]  Set is_stmt to 1
  [0x00000194]  Advance Line by 40 to 75
  [0x00000196]  Special opcode 75: advance Address by 5 to 0x400540 and Line by
0 to 75
...
while with gcc, for these instructions:
...
  400501:       c7 05 29 0b 20 00 00    movl   $0x0,0x200b29(%rip)        #
601034 <result>
  400508:       00 00 00
  40050b:       c7 05 1f 0b 20 00 00    movl   $0x0,0x200b1f(%rip)        #
601034 <result>
  400512:       00 00 00
  400515:       e8 61 00 00 00          callq  40057b <bar>
  40051a:       e8 5c 00 00 00          callq  40057b <bar>
  40051f:       e8 72 00 00 00          callq  400596 <marker>
...
we have a single line number statement that contains both calls to bar:
...
  [0x0000016a]  Special opcode 77: advance Address by 5 to 0x400501 and Line by
2 to 70
  [0x0000016b]  Special opcode 146: advance Address by 10 to 0x40050b and Line
by 1 to 71
  [0x0000016c]  Advance Line by -36 to 35
  [0x0000016e]  Special opcode 145: advance Address by 10 to 0x400515 and Line
by 0 to 35
  [0x0000016f]  Advance Line by 40 to 75
  [0x00000171]  Special opcode 145: advance Address by 10 to 0x40051f and Line
by 0 to 75
...

Still the information about the different calls is here:
...
 <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
...
so gdb could do better.

Indeed, lldb does better:
...
$ lldb outputs/gdb.opt/inline-cmds/inline-cmds      
(lldb) target create "outputs/gdb.opt/inline-cmds/inline-cmds"
Current executable set to 'outputs/gdb.opt/inline-cmds/inline-cmds' (x86_64).
(lldb) b 71
Breakpoint 1: where = inline-cmds`main + 100 at inline-cmds.c:71, address =
0x000000000040050b
(lldb) r
Process 17050 launched:
'/data/gdb_versions/devel/outputs/gdb.opt/inline-cmds/inline-cmds' (x86_64)
Process 17050 stopped
* thread #1, name = 'inline-cmds', stop reason = breakpoint 1.1
    frame #0: 0x000000000040050b inline-cmds`main at inline-cmds.c:71
   68     marker ();
   69  
   70     result = 0;
-> 71     result = 0; /* set breakpoint 3 here */
   72  
   73     func1 (); /* first call */
   74     func1 (); /* second call */
(lldb) n
Process 17050 stopped
* thread #1, name = 'inline-cmds', stop reason = step over
    frame #0: 0x0000000000400515 inline-cmds`main at inline-cmds.c:73
   70     result = 0;
   71     result = 0; /* set breakpoint 3 here */
   72  
-> 73     func1 (); /* first call */
   74     func1 (); /* second call */
   75     marker ();
   76  
(lldb) n
Process 17050 stopped
* thread #1, name = 'inline-cmds', stop reason = step over
    frame #0: 0x000000000040051a inline-cmds`main at inline-cmds.c:74
   71     result = 0; /* set breakpoint 3 here */
   72  
   73     func1 (); /* first call */
-> 74     func1 (); /* second call */
   75     marker ();
   76  
   77     result = 0;
(lldb)
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25884] Stepping over inlined function without line number statement fails

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> The difference seems to be that with clang, for these instructions:
> ...
>   400520:       c7 04 25 34 10 60 00    movl   $0x0,0x601034
>   400527:       00 00 00 00
>   40052b:       c7 04 25 34 10 60 00    movl   $0x0,0x601034
>   400532:       00 00 00 00
>   400536:       e8 75 00 00 00          callq  4005b0 <bar>
>   40053b:       e8 70 00 00 00          callq  4005b0 <bar>
>   400540:       e8 8b 00 00 00          callq  4005d0 <marker>
> ...
> we have line number statements for both calls to bar:
> ...
>   [0x0000018a]  Special opcode 77: advance Address by 5 to 0x400520 and Line
> by 2 to 70
>   [0x0000018b]  Special opcode 160: advance Address by 11 to 0x40052b and
> Line by 1 to 71
>   [0x0000018c]  Set column to 3
>   [0x0000018e]  Advance Line by -36 to 35
>   [0x00000190]  Special opcode 159: advance Address by 11 to 0x400536 and
> Line by 0 to 35
>   [0x00000191]  Set is_stmt to 0
>   [0x00000192]  Special opcode 75: advance Address by 5 to 0x40053b and Line
> by 0 to 35
>   [0x00000193]  Set is_stmt to 1
>   [0x00000194]  Advance Line by 40 to 75
>   [0x00000196]  Special opcode 75: advance Address by 5 to 0x400540 and Line
> by 0 to 75
> ...

Which, decoded, looks like: 
...
Line number    Starting address    View    Stmt
70            0x400520               x
71            0x40052b               x
35            0x400536               x
35            0x40053b
75            0x400540               x
...
So, why is the second entry with line 35 not the start of a statement?  That
looks like a clang bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Filed gcc PR 98780 -" Missing line table entry for inlined stmt at -g -O0" (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98780 ).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> Filed gcc PR 98780 -" Missing line table entry for inlined stmt at -g -O0" (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98780 ).

With the tentative gcc patch filed there, the KFAIL referring to this PR is
gone.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
FWIW, the KFAIL states:
...
    -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
    }
...

I'm not sure if I agree with the assessment that the gcc output is reasonable
(hence the gcc PR).

Anyway, this looks trivial to fix in gcc.

I'm not sure yet if it's easy to do a work around in gdb.  From what I
understand, the most orthogonal fix would be to edit the line table to add an
entry when parsing the DW_TAG_inlined_subroutine in the debug_info.

Fixing this in the stepping code itself feels like a bad idea, that code looks
convoluted enough already.  But perhaps that could change with a refactoring.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #4)
> Fixing this in the stepping code itself feels like a bad idea, that code
> looks convoluted enough already.

Anyway, this seems to work:
...
diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index 6f0ed952de6..3cfc5f02f06 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -1009,6 +1009,18 @@ prepare_one_step (thread_info *tp, struct
step_command_fsm *sm)
                                 &tp->control.step_range_start,
                                 &tp->control.step_range_end);

+         if (inline_skipped_frames (tp) > 0)
+           {
+             symbol *sym = inline_skipped_symbol (tp);
+             gdb_assert (sym);
+
+             const block *block = SYMBOL_BLOCK_VALUE (sym);
+             if (block
+                 && BLOCK_START (block ) == tp->control.step_range_start
+                 && 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.  */
...
and we get:
...
$ gdb -batch outputs/gdb.opt/inline-cmds/inline-cmds \
  -ex "break 71" \
  -ex run \
  -ex next \
  -ex next 
Breakpoint 1 at 0x40050b: file inline-cmds.c, line 71.

Breakpoint 1, main () at inline-cmds.c:71
71        result = 0; /* set breakpoint 3 here */
73        func1 (); /* first call */
74        func1 (); /* second call */
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> Anyway, this seems to work:

Survived x86_64-linux reg-test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|symtab                      |breakpoints

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
patch submitted:
https://sourceware.org/pipermail/gdb-patches/2021-January/175346.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/25884] Stepping over inlined function without line number statement fails

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=340d00fb783658a55a1e1d0bd97c9da360bf03fd

commit 340d00fb783658a55a1e1d0bd97c9da360bf03fd
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Apr 6 15:12:38 2021 +0200

    [gdb/breakpoints] Workaround missing line-table entry

    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.

    gdb/ChangeLog:

    2021-04-06  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-04-06  Tom de Vries  <tdevries@suse.de>

            PR breakpoints/25884
            * gdb.opt/inline-cmds.exp: Remove kfail.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/25884] Stepping over inlined function without line number statement fails

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25884

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |11.1
             Status|NEW                         |RESOLVED

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch committed, marking resolved-fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.