Problems understanding Spineless Tagless G-Machine

[Esa Ilari Vuokko]

Esa Ilari Vuokko wrote:

Answering myself and maybe providing info for other interested
souls or maybe someone correct me if I am wrong.

>  * Is it even possible to walk the stack in this manner?
>    Kind of critical question :-)  (I realise I can't deduct
>    all functions correctly at the moment)

It is possible to walk stack in this way, iff this two bits are
known (if I understood right):
 * the current infopointer where we entered function to be evaluated.
 * the amount of temporary stuff on stack.

Because of the latter, in practice it's only possible to walk the
stack if we have debugpoint right on first bits of entering a closure
(so stack contains closure information without infotable pointer,
which we can get from current codelocation) or if thread is blocked
via some stg functionality (blackholes come to mind) or if the thread
has called something Cish.  It is maybe possible to deduct right
circumstances and skip the first (currently evaluated) closure on
crash etc by reading stack downwards until an infotable pointer is
found, and that'd mark beginning of closure.

After that, it's just many closures after each other, for closuretypes
it can contain, see GC.c, scavenge_stack-function.

>  * How do I know if pointer to InfoTable in stack is FunInfoTable?
>    Or RetInfoTable?  Thunks I suppose are identified by closure
>    type's flags.  (I identify _THU-flagged as ThunkInfoTable and
>    FUN_-closures as FunInfoTable currently.)  run-time-system.ps
>    mentions, very useful sounding function/macro called isFUN,
>    and friends, but I couldn't find them in ghc sources.

This isn't actually always clear to me.  Lucky for me, I don't need
to know anything else besides which are FunInfoTables as thunk and
return infotables only contain additional SRT-data which isn't
interesting.

>  * I can't see correlation between Sp-stack entries and
>    arities/function types (as told by StgFunInfoTable.f.fun_type)
>    and other entries in the stack.  Should I?

I am still puzzled by function arities, only thing I can see is that
IO-function seems to have arity one too big.

There is one thing that still is kind of wierd...it seems I can read
stack by using bitmap-representation and function representation params,
but both, as far as I can see, sometimes have marked params as
non-pointer, and the word still contains very clearly a stack address
(or sometimes an address of static closure.)

Except the lacking infoptr on top of stack, all of is contained in
docs, but it was just a bit too complex for me to understand - and maybe
I was approaching this from diffrent angle than docs suppose.

I am finding this tracing not to be as useful as I first thought, and
even probing heap is not very helpful because it's mainly thunks. So
it seems that tracer won't be much help for anyone except people
deeply knowledgeable in stg/rts.  Most debugging would require
clever use of conditional breakpoints to show the real values.  Or
maybe RTS support for evaluating values.

Best regards,
Esa