https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Nils Gladitz from comment #7)
> (In reply to Nils Gladitz from comment #5)
> > Apparently when the coroutine happens to be a member function (even a static
> > one) printing *frame_ptr results in "{<No data fields>}".
>
> I reported the "{<No data fields>}" issue at the gdb issue tracker:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27556
>
> Managed to create a local workaround from comments made there.
> It was mentioned that gcc itself may be generating improper debug
> information (I think specifically nesting the frame type within a function)
> but as I mentioned over there I myself don't know for sure if this is
> uncommon or actually invalid.
I am not 100% sure about the nesting of the type info
on one hand, the type _is_ local to the function (it's compiler-generated, end
users shouldn't need to look inside it - we are only doing so as a work-around
for missing info)
on the other, I suppose it's also unique to the function and therefore could be
pushed to file scope.
In the end I expect things to work better if we make use of the existing
machinery for decls being represented by some specified expression - then you
would not need to be poking inside the private (compiler-generated) type for
the frame.
In support of improved debug, I'm collecting some local patches - ready for
next stage 1. One thing done already is to change the resume index even if the
suspend is not taken - so that an interrupted coro would have some indication
of which part of the code was active.
