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

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.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).