Hi,
As discussed with Jason at WG21 in Prague - last year, this amends the
way in which the coroutine frame copies of variables are represented in
the front end lowering. Instead of an explicit pointer->field we now
apply a DECL_VALUE_EXPR to each instead (where that value is the
pointer->field).
Although this was initially targeted at improving the debug experience
in fact it simplifies and shortens the code, and makes subsequent bug-
fixes easier to implement. Therefore, I'm posting this series first.
In addition to the change applied to local variables:
- there is an implementation of a mechanism to make the original
function arguments debug-visible. These are actually copied into
the frame by the ramp function, so we create proxy vars for them
and attach a DECL_VALUE_EXPR for the frame copy.
- It is likely that someone debugging a coroutine will want to inspect
parts of the implementation state (especially items such as the
suspend index and the promise object). Although these are not a
direct part of the user's source code, we expose them as synthetic
variables in the implementation name-space _Coro_xxxxxx.
Patches to follow:
coroutines: Use DECL_VALUE_EXPR instead of rewriting vars.
coroutines: Add a helper for creating local vars.
coroutines: Support for debugging implementation state.
coroutines: Make some of the artificial names more debugger-friendly.
coroutines: Define and populate accessors for debug state.
coroutines: Convert implementation variables to debug-friendly form.
coroutines: Make proxy vars for the function arg copies.
coroutines: Make the continue handle visible to debug.
gcc/cp/coroutines.cc | 701 +++++++++++++++++++------------------------
1 file changed, 304 insertions(+), 397 deletions(-)
This has been tested quite a bit over some months on x86_64-darwin and
on x86_64, powerpc64-linux,
OK for master?
backports?
thanks,
Iain
***
I've tested with GDB and LLDB that we now have visibility of the coro
state, local variables and function parameters. However the debug
experience is still a little "jumpy" in respect of stepping through the
code - this is because synthesized expressions default to using
'input_location' as their location - which is typically pointing to the
closing brace of the function. So I think there is more that can
be done for PR99215, but it's a different kind of problem from the one
being solved with the DECL_VALUE_EXPRs.
