https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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>}".
>
> Ideally I'd want to have non-static member coroutines and would like to be
> able to inspect the "this" pointer during debugging.
.. 'this' gets translated into a reference to the original object for
coroutines... hmm have to see if there's any useful advice at this stage.
> I was also wondering if "frame_ptr" as a non-reserved name isn't problematic
> in case there happens to be e.g. a local variable with that name.
the local variables in the ramp are prefixed with 'coro.' which makes them not
a legal user identifiers. So it's actually coro.frame_ptr.
(where there is potential for clashes, frame variables named are pushed into
the implementation space e.g. __ or _CapitalLetter).
===
I should check in the actor/destroyer if there is scope for a clash (since the
variables are local, they are named xxxxxactor:frame_ptr)
.. and would be distinct from any var named frame_ptr in the original source ..
which would become xxxxxactor:frame_ptr->frame_ptr :)
However, when implementing the "idea" described above, I think that might
expose the issue - so prefixing with __ or changing the name to _Frame_ptr
might be necessary.
Of course, I didn't make a test case to prove this, .. but will try it
sometime.
