[Bug c++/28137] New: "Cannot evaluate function -- may be inlined" for a lambda that's not really inlined

[Bug c++/28137] New: "Cannot evaluate function -- may be inlined" for a lambda that's not really inlined

[b7.10110111 at gmail dot com]

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

            Bug ID: 28137
           Summary: "Cannot evaluate function -- may be inlined" for a
                    lambda that's not really inlined
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

Consider the following C++ code:

```
#include <iostream>

int main()
{
    const auto lamb = []{};
    std::cerr << "Lambda created\n";
    lamb();
}
```

I compile it with GCC 9.2.0 as

```
g++ test.cpp -o test -g
```

Then GDB session (with GDB 12.0.50.20210725-git) goes as follows:
```
$ gdb -q ./test -ex start
Reading symbols from ./test...
Temporary breakpoint 1 at 0x8048599: file test.cpp, line 6.
Starting program: /tmp/test 

Temporary breakpoint 1, main () at test.cpp:6
6           std::cerr << "Lambda created\n";
(gdb) n
Lambda created
7           lamb();
(gdb) call lamb.operator()()
Cannot evaluate function -- may be inlined
(gdb) disas
Dump of assembler code for function main():
[...]
   0x080485ab <+35>:    add    esp,0x10
=> 0x080485ae <+38>:    sub    esp,0xc
   0x080485b1 <+41>:    lea    eax,[ebp-0x9]
   0x080485b4 <+44>:    push   eax
   0x080485b5 <+45>:    call   0x8048582 <<lambda()>::operator()(void) const>
   0x080485ba <+50>:    add    esp,0x10
   0x080485bd <+53>:    mov    eax,0x0
[...]
```

As you can see, the lambda isn't really inlined, and is available as an actual
callable function — yet GDB fails to call it.

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

[Bug c++/28137] "Cannot evaluate function -- may be inlined" for a lambda that's not really inlined

[ssbssa at sourceware dot org]

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

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++/28137] "Cannot evaluate function -- may be inlined" for a lambda that's not really inlined

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-12-29
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Hannes Domani <ssbssa at sourceware dot org> ---
When comparing the operator() of normal classes and lambdas:
```
struct S {
  int operator() (int x) { return x + 5; }
};

int main () {
  S s;

  auto l = [](int i) {
    return i + 5;
  };

  auto l2 = [](int i) {
    return i * 2;
  };

  return s(23) + l(10) + l2(20);
}
```

You can only call the operator() from the normal class:
```
(gdb) p s.operator()(10)
$1 = 15
(gdb) p l.operator()(10)
Cannot evaluate function -- may be inlined
```

nm shows symbols for all 3 of them:
```
0000000000000000 T _ZN1SclEi
0000000000000000 t _ZZ4mainENKUliE_clEi
0000000000000014 t _ZZ4mainENKUliE0_clEi
```

But there seems to be some problem with the symbol name:
```
(gdb) p 'S::operator()(int)'
$2 = {int (S * const, int)} 0x1400025a0 <S::operator()(int)>
(gdb) p 'main::{lambda(int)#1}::operator()(int) const'
$3 = {int (const struct {...} * const, int)} 0x140001600 <operator()(int)
const>
(gdb) p 'main::{lambda(int)#2}::operator()(int) const'
$4 = {int (const struct {...} * const, int)} 0x140001614 <operator()(int)
const>
```

For S::operator() the debug info looks like this:
```
 <1><57>: Abbrev Number: 15 (DW_TAG_structure_type)
    <58>   DW_AT_name        : S
    <5a>   DW_AT_byte_size   : 1
    <5b>   DW_AT_decl_file   : 1
    <5c>   DW_AT_decl_line   : 1
    <5d>   DW_AT_decl_column : 8
    <5e>   DW_AT_sibling     : <0x88>
 <2><62>: Abbrev Number: 16 (DW_TAG_subprogram)
    <63>   DW_AT_external    : 1
    <63>   DW_AT_name        : (indirect string, offset: 0x9): operator()
    <67>   DW_AT_decl_file   : 1
    <68>   DW_AT_decl_line   : 2
    <69>   DW_AT_decl_column : 7
    <6a>   DW_AT_linkage_name: _ZN1SclEi
    <74>   DW_AT_type        : <0x88>
    <78>   DW_AT_declaration : 1
    <78>   DW_AT_object_pointer: <0x7c>
```

And for the lambdas it's like this:
```
 <2><c8>: Abbrev Number: 8 (DW_TAG_structure_type)
    <c9>   DW_AT_byte_size   : 1
    <c9>   DW_AT_decl_file   : 1
    <c9>   DW_AT_decl_line   : 8
    <ca>   DW_AT_decl_column : 13
    <cb>   DW_AT_sibling     : <0x181>
...
 <3><13e>: Abbrev Number: 12 (DW_TAG_subprogram)
    <13f>   DW_AT_name        : (indirect string, offset: 0x9): operator()
    <143>   DW_AT_type        : <0x88>
    <147>   DW_AT_artificial  : 1
    <147>   DW_AT_object_pointer: <0x167>
    <14b>   DW_AT_low_pc      : 0x0
    <153>   DW_AT_high_pc     : 0x13
    <15b>   DW_AT_frame_base  : 1 byte block: 9c        (DW_OP_call_frame_cfa)
    <15d>   DW_AT_call_all_calls: 1
```

There is no DW_AT_linkage_name here, which is the reason gdb can't find
the address of operator() when trying to call it.
But there is DW_AT_low_pc available, so should gdb use it instead (I'm not
sure if that's possible)?

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