[Bug c++/25987] New: Wrong line for code containing inlined functions

[Bug c++/25987] New: Wrong line for code containing inlined functions

[brenorg at gmail dot com]

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

            Bug ID: 25987
           Summary: Wrong line for code containing inlined functions
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: brenorg at gmail dot com
  Target Milestone: ---

TLDR:

GDB is showing the wrong line information for a function call in a line with
inlined functions. Like this:

```
some_unique_ptr->fn();
```

In the backtrace, GDB shows "unique_ptr::operator->" as line information for
the call to "fn".


The long version: 


For the following code:

```

struct MyClass;
struct ptr {
    MyClass* get() { return t; }
    MyClass* t;
};
struct MyClass { void call(); };
void MyClass::call() {
    *(char*)(nullptr) = 1;
}
static void intermediate(ptr p) {
    p.get()->call();
}
int main() {
    intermediate(ptr{new MyClass});
}

```

Compiled with GCC 8 or above with these flags:

```
g++ -Og -g -o main main.cpp
```

The function "call" will crash and the backtrace using GDB HEAD looks like
this:

```
#0  MyClass::call (this=0x416c20) at main.cpp:8
#1  0x0000000000401140 in intermediate (p=...) at main.cpp:3
#2  0x0000000000401157 in main () at main.cpp:14
```

Notice that the "intermediate" frame is pointing to main.cpp:3 which is the
call to "get". I would expect it to show main.cpp:11

I tested GDB 8 and it shows the correct information but that seems by chance.
If I move the "ptr" definition to a header, then it also fails with GDB 8 (but
works with GDB head).

Looking at the decoded line information, it seems that there is no way for GDB
to tell which is the correct call:

```
$ objdump -D main | grep callq.*intermediate
  401152:       e8 e4 ff ff ff          callq  40113b <_ZL12intermediate3ptr


$ objdump --dwarf=decodedline main | grep 40113b
main.cpp 10 0x40113b               x
main.cpp 11 0x40113b       1       x
main.cpp  3 0x40113b       2       x
main.cpp  3 0x40113b       3       x
main.cpp  3 0x40113b       4
main.cpp 11 0x40113b       5

```

There seems to be multiple line information for the same "callq" instruction.
So I'm not sure how GDB would tell the difference. Maybe from the dwarf
information it should be able to figure out which of those lines refer to
inlined functions ?

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

[Bug c++/25987] Wrong line for code containing inlined functions

[brenorg at gmail dot com]

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

--- Comment #1 from Breno Guimarães <brenorg at gmail dot com> ---
I marked this as "critical" because this is happening left and right with
std::unique_ptr, std::function, and other inlined functions.
But I don't know the actual criteria for the priority, so sorry if I got that
wrong.

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

[Bug c++/25987] Wrong line for code containing inlined functions

[ssbssa at sourceware dot org]

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

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 c++/25987] Wrong line for code containing inlined functions

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #2 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I just realized that my inline end range handling patch
fixes this test case:

https://sourceware.org/pipermail/gdb-patches/2020-December/174333.html

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

[Bug c++/25987] Wrong line for code containing inlined functions

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
The test case is interesting, as it contains an
empty inlined subroutine ptr::get() :

 <2><11c>: Abbrev Number: 17 (DW_TAG_inlined_subroutine)
    <11d>   DW_AT_abstract_origin: <0x18a>
    <121>   DW_AT_entry_pc    : 0x40113f
    <129>   DW_AT_GNU_entry_view: 2
    <12a>   DW_AT_low_pc      : 0x40113f
    <132>   DW_AT_high_pc     : 0x0
    <13a>   DW_AT_call_file   : 1
    <13b>   DW_AT_call_line   : 11
    <13c>   DW_AT_call_column : 18
    <13d>   DW_AT_sibling     : <0x14f>

The call instruction is immediately after this empty inline block,
when the call stack is printed, the line table finds
the stmt line 3 followed by non-stmt line 11.
My patch modifies the logic in find_pc_sect_line if a line at the
end of the subroutine is found, but the PC is larger than that,
the non-stmt line 11 following the subroutine is preferred.

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