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

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

[nilsgladitz at gmail dot com]

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.

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

[nilsgladitz at gmail dot com]

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

--- Comment #1 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Created attachment 13299
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13299&action=edit
Test case executable with debug information

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

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-03-12

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
On the one hand, this is a bug in gdb.
It stops in read_structure_type for DIE 0x5cc (the struct in question).
However, it never calls process_structure_scope for that DIE --
and this is how the contents of the struct are filled in.

On the other hand, the DIE is quite strange.  It's referred to by
various things in the DWARF but is nested inside one particular function:

 <2><5be>: Abbrev Number: 50 (DW_TAG_subprogram)
    <5bf>   DW_AT_name        : (indirect string, offset: 0x102):
_ZN3Foo9function2Ei.destroy
    <5c3>   DW_AT_artificial  : 1
    <5c3>   DW_AT_declaration : 1
    <5c3>   DW_AT_sibling     : <0x673>
 <3><5c7>: Abbrev Number: 14 (DW_TAG_formal_parameter)
    <5c8>   DW_AT_type        : <0x70f>
 <3><5cc>: Abbrev Number: 51 (DW_TAG_structure_type)
    <5cd>   DW_AT_name        : (indirect string, offset: 0x33e):
_ZN3Foo9function2Ei.frame
    <5d1>   DW_AT_byte_size   : 48
    <5d2>   DW_AT_decl_file   : 2
    <5d3>   DW_AT_decl_line   : 76
    <5d4>   DW_AT_decl_column : 2


So, I would say that while it is a bug in gdb, it should also be fixed in the
compiler.

Offhand I am not sure why gdb isn't processing this DIE.
Normally expanding a CU ought to process everything.
Perhaps it is because it is artificial/declaration, though.

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

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

[nilsgladitz at gmail dot com]

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

--- Comment #3 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Thank you for looking into this.

I am not familiar enough with the corresponding standards to tell if nesting
the type definition inside the function is a violation or valid but unusual.

FWIW I think the type is tightly coupled with the coroutine so nesting it in
the corresponding function might make sense that way. I don't know if there is
precedence for this elsewhere but given that the implementation is new that
might justify the current uncommonness.

In the working case of "function1" the type is also nested and the function
also artificial but it is not marked as a declaration which if I understand you
correctly might be why it currently breaks for "function2".

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

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

[nilsgladitz at gmail dot com]

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

--- Comment #4 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Based on your notes I managed to make this work locally but I don't know what
side effects the change might have; maybe usable as groundwork though:

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index d6881300fa..859643f1bd 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -13566,8 +13566,11 @@ read_func_scope (struct die_info *die, struct
dwarf2_cu *cu)
          child_die = spec_die->child;
          while (child_die && child_die->tag)
            {
-             if (child_die->tag == DW_TAG_imported_module)
-               process_die (child_die, spec_cu);
+          if (child_die->tag == DW_TAG_imported_module
+              ||child_die->tag == DW_TAG_structure_type)
+            {
+              process_die (child_die, spec_cu);
+            }
              child_die = child_die->sibling;
            }

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

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

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
> I am not familiar enough with the corresponding standards to tell if nesting the type definition inside the function is a violation or valid but unusual.

I think valid but (very) unusual.

> Based on your notes I managed to make this work locally but I don't know
> what side effects the change might have; maybe usable as groundwork though:

Offhand I am not sure why this is done in 2 phases.
Possibly something could go wrong with recursive data structures?
That's my only guess.

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