[Bug c++/27556] New: "<no data fields>" for some C++ coroutine frame types

["nilsgladitz at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 27556
           Summary: "<no data fields>" for some C++ coroutine frame types
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: nilsgladitz at gmail dot com
  Target Milestone: ---

Created attachment 13298
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13298&action=edit
Test case source code

Given the attached source code compiled with GCC 10.2.0 thusly:
  g++ -fcoroutines -std=c++20 -g test.cpp -o test

There are two seemingly identical coroutines.
One having global scope (function1) and one being a static struct member
(function2).

Setting a breakpoint at the co_return line in function1 lets me inspect
"*frame_ptr" (frame_ptr being a pointer to the gcc generated coroutine frame):

type = struct _ZL9function1i.frame {
    void (*__resume)(_ZL9function1i.frame *);
    void (*__destroy)(_ZL9function1i.frame *);
    std::__n4861::__coroutine_traits_impl<task, void>::promise_type __p;
    bool __frame_needs_free;
    unsigned short __resume_at;
    std::__n4861::coroutine_handle<task::promise_type> __self_h;
    int __parm.fooParameter;
    bool __i_a_r_c.1.1;
    std::__n4861::suspend_always __Is.2.2;
    int __fooLocal1.2.3;
    int __fooLocal2.2.3;
    std::__n4861::suspend_always __Fs.2.4;
} *


Doing the same in function2 however seems to indicate that the corresponding
coroutine frame type does not have any members:

type = struct Foo::_ZN3Foo9function2Ei.frame {
    <no data fields>
} *

I tried looking into the debug information via dwarfdump and as far as I can
tell both coroutine frame types are present including member definitions.

I can't tell if there is something gdb is overlooking / mishandling or if gcc
is not correctly generating debug information or generating it in some
unexpected fashion.

FWIW the gcc implementation is still pretty fresh and other aspects of
corresponding debug information are currently expected to be lacking e.g.:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

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