[Bug c++/99215] New: coroutines: debugging with gdb

[Bug c++/99215] New: coroutines: debugging with gdb

[nilsgladitz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

            Bug ID: 99215
           Summary: coroutines: debugging with gdb
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nilsgladitz at gmail dot com
  Target Milestone: ---

I am itching to get into C++20 coroutines (and very grateful for their
implementation) but am somewhat put off by the apparent inability to inspect
them from within a debugger currently.

While looking for existing related GCC specific issues, discussions or commits
(none of which I found) the following paper [Debugging C++ coroutines] did come
up: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2073r0.pdf
This seems to at least confirm the current state that I was seeing.

I can not tell if support for this is missing in GCC or GDB or both but I
figured I'd try finding out here first.
Presumably (hopefully) someone here is at least aware of the issue and might be
able to point out if this is maybe already done (and I am just doing it wrong
or using the wrong GCC version), in the works or on some agenda somewhere.

[Bug c++/99215] coroutines: debugging with gdb

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-02-23

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Nils Gladitz from comment #0)
> I am itching to get into C++20 coroutines (and very grateful for their
> implementation) but am somewhat put off by the apparent inability to inspect
> them from within a debugger currently.
> 
> While looking for existing related GCC specific issues, discussions or
> commits (none of which I found) the following paper [Debugging C++
> coroutines] did come up:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2073r0.pdf
> This seems to at least confirm the current state that I was seeing.

Indeed you are correct (I was present at the meeting that the paper was
reviewed).
At that time (a year ago) there was no specific support in either GCC/GDB or
clang/LLDB.  I guess the debugging I do is mainly on code-gen, so rarely
debugging the actual coroutines, more the compiler.

> I can not tell if support for this is missing in GCC or GDB or both but I
> figured I'd try finding out here first.
> Presumably (hopefully) someone here is at least aware of the issue and might
> be able to point out if this is maybe already done (and I am just doing it
> wrong or using the wrong GCC version), in the works or on some agenda
> somewhere.

I have some ideas about how the debug experience might be improved (at least
w.r.t examining frame content) - but, as with everything else, queued in the
long TODO.

Can you identify specific key blockers to progress?
(I think the paper cited contained a number of desiderata, but it would be good
to start from the most important requirements).

I'd be interested in some idea of "I tried to fix this, but failed because I
couldn't do xxxx".  I would expect source location-based breakpoints etc. to be
functional (modulo possible bugs in attaching locations to expressions).

[Bug c++/99215] coroutines: debugging with gdb

[nilsgladitz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #2 from Nils Gladitz <nilsgladitz at gmail dot com> ---
(In reply to Iain Sandoe from comment #1)
> Can you identify specific key blockers to progress?
> (I think the paper cited contained a number of desiderata, but it would be
> good to start from the most important requirements).

Thank you for the quick reply.

As you and the paper have stated setting breakpoints so far seems to work fine
for me.

What stands out most for me is being unable to inspect parameters (which for
the debugger don't seem to exist) and local variables (their names seem to be
known but their values all show as "<optimized out>").

On second look this seems to be only half true as I seem to be able to inspect
both local variables and parameters via the debugger visible "frame_ptr"
variable.

Not straightforward and names seem to be mangled but that might suffice to get
started to some degree; won't work with gdb frontends though (which I have been
using).

I have no idea of how any of this is actually implemented but I am hoping this
is just a matter of emitting debug information that tells gdb to look for
members and parameters in the corresponding frame_ptr locations?

[Bug c++/99215] coroutines: debugging with gdb

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Nils Gladitz from comment #2)
> (In reply to Iain Sandoe from comment #1)
> > Can you identify specific key blockers to progress?
> > (I think the paper cited contained a number of desiderata, but it would be
> > good to start from the most important requirements).

> As you and the paper have stated setting breakpoints so far seems to work
> fine for me.

great (there could still be room for improvement, so if you see something that
doesn't work, worth filing a PR).

> What stands out most for me is being unable to inspect parameters (which for
> the debugger don't seem to exist) and local variables (their names seem to
> be known but their values all show as "<optimized out>").
> 
> On second look this seems to be only half true as I seem to be able to
> inspect both local variables and parameters via the debugger visible
> "frame_ptr" variable.

That is correct, both parameters and local variables are moved into the
coroutine frame, but there is nothing telling the debugger that this
happened...

(there are also a bunch of artificial vars created in the frame to carry state
that must persist across suspension points).

The only debugger support I think is for MSVC - and they mentioned that it was
useful to know the suspension point index - one of the artificial values, (but
I don't think that there's any agreed way to represent that - certainly,
nothing formal in DWARF).

> Not straightforward and names seem to be mangled but that might suffice to
> get started to some degree; won't work with gdb frontends though (which I
> have been using).
> 
> I have no idea of how any of this is actually implemented but I am hoping
> this is just a matter of emitting debug information that tells gdb to look
> for members and parameters in the corresponding frame_ptr locations?

... the essence of the idea [on the mentioned long TODO] is to change the way
in which frame vars are referenced; instead of changing the uses to point to
the frame version, change the vars to have a DECL_VALUE_EXPR pointing to the
frame version.  This is a totally theoretical sketch (no experiments done yet).

Stated in one sentence, that doesn't sound too tricky .. but maintaining the
state of the coroutine *is* quite tricky (and lambdas already use the
DECL_VALUE_EXPRs).

[Bug c++/99215] coroutines: debugging with gdb

[nilsgladitz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #4 from Nils Gladitz <nilsgladitz at gmail dot com> ---
(In reply to Iain Sandoe from comment #3)
> ... the essence of the idea [on the mentioned long TODO] is to change the
> way in which frame vars are referenced; instead of changing the uses to
> point to the frame version, change the vars to have a DECL_VALUE_EXPR
> pointing to the frame version.  This is a totally theoretical sketch (no
> experiments done yet).
> 
> Stated in one sentence, that doesn't sound too tricky .. but maintaining the
> state of the coroutine *is* quite tricky (and lambdas already use the
> DECL_VALUE_EXPRs).

Alright, thank you! Just knowing that this is thought of, on a todo list and
currently not completely inaccessible helps build confidence somewhat; I think
for me enough to try some of this in production code. With some luck you still
get through your todo list faster than I get to my next corresponding release
:)

[Bug c++/99215] coroutines: debugging with gdb

[nilsgladitz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #5 from Nils Gladitz <nilsgladitz at gmail dot com> ---
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.

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.

[Bug c++/99215] coroutines: debugging with gdb

[iains at gcc dot gnu.org]

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.

[Bug c++/99215] coroutines: debugging with gdb

[nilsgladitz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #7 from Nils Gladitz <nilsgladitz at gmail dot com> ---
(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.

[Bug c++/99215] coroutines: debugging with gdb

[iains at gcc dot gnu.org]

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.

[Bug c++/99215] coroutines: debugging with gdb

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #8)
> (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>}".

> on the other, I suppose it's also unique to the function and therefore could
> be pushed to file scope.

um, maybe that should be the class scope, for member functions.

[Bug c++/99215] coroutines: debugging with gdb

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:d5b1bb0d197f9141a0f0e510f8d1b598c3df9552

commit r12-2229-gd5b1bb0d197f9141a0f0e510f8d1b598c3df9552
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Jul 7 19:56:20 2021 +0100

    coroutines: Factor code. Match original source location in helpers [NFC].

    This is primarily a source code refactoring, the only change is to
    ensure that the outlined functions are marked to begin at the same
    line as the original.  Otherwise, they get the default (which seems
    to be input_location, which corresponds to the closing brace at the
    point that this is done).  Having the source location point to that
    confuses some debuggers.

    This is a contributory fix to:
    PR c++/99215 - coroutines: debugging with gdb

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    gcc/cp/ChangeLog:

            * coroutines.cc (build_actor_fn): Move common code to
            act_des_fn.
            (build_destroy_fn): Likewise.
            (act_des_fn): Build the void return here.  Ensure that the
            source location matches the original function.

[Bug c++/99215] coroutines: debugging with gdb

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:feef2e414d45f732509ab044d4ad14aed125b024

commit r11-8786-gfeef2e414d45f732509ab044d4ad14aed125b024
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Jul 7 19:56:20 2021 +0100

    coroutines: Factor code. Match original source location in helpers [NFC].

    This is primarily a source code refactoring, the only change is to
    ensure that the outlined functions are marked to begin at the same
    line as the original.  Otherwise, they get the default (which seems
    to be input_location, which corresponds to the closing brace at the
    point that this is done).  Having the source location point to that
    confuses some debuggers.

    This is a contributory fix to:
    PR c++/99215 - coroutines: debugging with gdb

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    gcc/cp/ChangeLog:

            * coroutines.cc (build_actor_fn): Move common code to
            act_des_fn.
            (build_destroy_fn): Likewise.
            (act_des_fn): Build the void return here.  Ensure that the
            source location matches the original function.

    (cherry picked from commit d5b1bb0d197f9141a0f0e510f8d1b598c3df9552)

[Bug c++/99215] coroutines: debugging with gdb

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
also :

https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352947.html
https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352948.html
https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352949.html

[Bug c++/99215] coroutines: debugging with gdb

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:ddef3142151a3e88743aa4a990062d953a16c04e

commit r10-10164-gddef3142151a3e88743aa4a990062d953a16c04e
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Jul 7 19:56:20 2021 +0100

    coroutines: Factor code. Match original source location in helpers [NFC].

    This is primarily a source code refactoring, the only change is to
    ensure that the outlined functions are marked to begin at the same
    line as the original.  Otherwise, they get the default (which seems
    to be input_location, which corresponds to the closing brace at the
    point that this is done).  Having the source location point to that
    confuses some debuggers.

    This is a contributory fix to:
    PR c++/99215 - coroutines: debugging with gdb

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    gcc/cp/ChangeLog:

            * coroutines.cc (build_actor_fn): Move common code to
            act_des_fn.
            (build_destroy_fn): Likewise.
            (act_des_fn): Build the void return here.  Ensure that the
            source location matches the original function.

    (cherry picked from commit d5b1bb0d197f9141a0f0e510f8d1b598c3df9552)

[Bug c++/99215] coroutines: debugging with gdb

[jarrod.smith at ardentblue dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215

--- Comment #14 from Jarrod Smith <jarrod.smith at ardentblue dot com> ---
I've been following this and experiencing the issue in gcc 10.2. I still see
"<optimized out>" for all variables when debugging C++20 coroutines with gcc
11.2.

Is there a workaround (e.g. using a certain branch of gcc) in order to inspect
coroutine variables with gdb the meantime?