The real expert in the RTS data structures is Simon Marlow, who's been away at the ICFP PC meeting, hence no reply. And you seem to have been getting on pretty well yourself -- well done.
Certainly, once you have found an info-pointer on the stack, you should be able to walk the stack with complete precision; and you're right to look at the existing stack-walking code for guidance. Sounds as if you had difficulty "getting started" from an ill-defined state, which isn't surprising. I don't' think we'd thought about that. Bulat explained why IO has a bigger arity than you expected. Simon | -----Original Message----- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Esa Ilari | Vuokko | Sent: 21 May 2006 21:35 | To: [EMAIL PROTECTED] | Subject: Re: Problems understanding Spineless Tagless G-Machine | | | 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 | _______________________________________________ | Cvs-ghc mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
