Re: [tclquadcode] Still groping forward on the crash in CoroEarly

[Kevin K. <kev...@gm...>]

What's going on with mrtest::* really puzzles me, and I'd really appreciate
another pair of eyeballs.

The tester calls 'mrtest::calc' from Tcl, which enters the call thunk.

As far as I can tell, the failing sequence looks to be the same code as the
three test cases that pass.
By inserting strategic printf's, what I discovered:

The initial call from the thunk to 'mrtest::calc(STRING) succeeds.

mrtest::calc Tcl_Alloc's the coroutine frame, fills the initial values in,
and suspends, which returns the coro frame to the thunk. (This 'on ramp'
portion of the proc is actually inlined into the thunk.)

The coro frame starts with the resume address (I don't have any idea how to
get a link map, so no idea if it's the RIIGHT resume address!), the destroy
address (ditto!), the promise (correct at this point; TCL_OK for the Tcl
status and an uninitialized INT return value), the resume index (-3), and
the parameter 'x'.

The call to Tcl_NRAddCallback for the return thunk is made, and returns.

The call to Tcl_NRAddCallback for tcl.coro.runner is made, and returns.

The thunk returns to the trampoline, and the callback into tcl.coro.runner
fires.

tcl.coro.runner sees the same pointer to the coro frame that mrtest::calc
allocated. It calls whatever the resume address in the coro frame points
to. That address is the same address that mrtest::calc put there. As I
said, I have no idea whether it's the right address, but the code follows
the same pattern as the procedures that work.

The resume proc, mrtest::calc(STRING).resume, begins with a short codeburst
that LLVM inserts; I can't instrument this readily, or at least I don't
know how to do it.

I had a printf inserted immediately following the call to llvm.coro.suspend
in the entry block of mrtest::calc. That printf was never reached.

And that's as far as I can get tonight.