few questions about GHC RTS
Hi, I thought I may look at the :next command for GHCi debugger again. If I do, I will not make it before 6.12.1 is out. I have few questions about RTS in relation to :next implementation. If they is easy to answer I would appreciate it, if not, don't bother since I'm not sure I'll do it ... and If I decide to do it I may just figure it out myself or fail again :) Why is stg_nofoceIO_info added as last argument to IO actions in unregistered mode? Do I still need to pass it in even when (I think) my IO action does not need it? E.g. is it required for every IO action by some stack walking code or something? Are there any Cmm functions in RTS with signature (IO()) or signature (Int->IO()) which I could check out as examples to see how they are done? ... and ideally also how they are called from the stack. Are there any special things to do when adding a new field (e.g. simulated stack size) to StgTSO? Thanks, Peter.
On 19/08/2009 10:18, Peter Hercek wrote:
Hi,
I thought I may look at the :next command for GHCi debugger again. If I do, I will not make it before 6.12.1 is out. I have few questions about RTS in relation to :next implementation. If they is easy to answer I would appreciate it, if not, don't bother since I'm not sure I'll do it ... and If I decide to do it I may just figure it out myself or fail again :)
Why is stg_nofoceIO_info added as last argument to IO actions in unregistered mode? Do I still need to pass it in even when (I think) my IO action does not need it? E.g. is it required for every IO action by some stack walking code or something?
The comment in Interpreter.c says // Note [unreg]: in unregisterised mode, the return // convention for IO is different. The // stg_noForceIO_info stack frame is necessary to // account for this difference. However, the return convention for IO is now the same under both registerised and unregisterised builds (I made the change becuase of the proliferation of obscure conditional RTS code like the above), so I'm guessing the stg_noforceIO_info hack, and the above comment, are now redundant. It needs testing though.
Are there any Cmm functions in RTS with signature (IO()) or signature (Int->IO()) which I could check out as examples to see how they are done? ... and ideally also how they are called from the stack.
See e.g. stg_catchzh in Exceptions.cmm, which needs to call an IO action. It tail-calls it though, which is perhaps not what you're after. To invoke an IO operation in the RTS, you just need to apply it to the RealWorld token, which in practice means applying it to a void argument, which you can do by loading it into R1 and tail-calling stg_ap_v_fast.
Are there any special things to do when adding a new field (e.g. simulated stack size) to StgTSO?
Just remember to rebuild enough things, because this will change the offsets of certain TSO fields, which are baked into the generated code for certain operations. I don't think GHC will force a rebuild of the libraries in this case (the build system will recompile everything, but the recompilation checker doesn't know that these offsets have changed) so you'll need to make clean in the libraries. Oh, and if the design is at all non-obvious, then writing a wiki page and asking for review would be a good first step. Adding fields to StgTSO is a pretty big change to make, especially if there are new invariants that have to be maintained, so a good justification will be needed. Cheers, Simon
Simon Marlow wrote:
On 19/08/2009 10:18, Peter Hercek wrote:
Why is stg_nofoceIO_info added as last argument to IO actions in unregistered mode? Do I still need to pass it in even when (I think) my IO action does not need it? E.g. is it required for every IO action by some stack walking code or something?
The comment in Interpreter.c says
// Note [unreg]: in unregisterised mode, the return // convention for IO is different. The // stg_noForceIO_info stack frame is necessary to // account for this difference.
However, the return convention for IO is now the same under both registerised and unregisterised builds (I made the change becuase of the proliferation of obscure conditional RTS code like the above), so I'm guessing the stg_noforceIO_info hack, and the above comment, are now redundant. It needs testing though.
Just for your information. I was curious and tried to remove the additional stg_noforceIO_info argument. Breakpoints stopped to be called but otherwise ghci seemed to work fine. It was surprising. It looked like the call to rts_breakpoint_io_action was somehow optimized away but I would not expect any optimizations at this level. Maybe I did not do it correctly. The patch I used is at the end of this email. Thanks, Peter. hunk ./rts/Interpreter.c 879 // in a reasonable state for the GC and so that // execution of this BCO can continue when we resume ioAction = (StgClosure *) deRefStablePtr (rts_breakpoint_io_action); - Sp -= 9; - Sp[8] = (W_)obj; $ - Sp[7] = (W_)&stg_apply_interp_info; - Sp[6] = (W_)&stg_noforceIO_info; // see [unreg] below + Sp -= 8; + Sp[7] = (W_)obj; $ + Sp[6] = (W_)&stg_apply_interp_info; Sp[5] = (W_)new_aps; // the AP_STACK Sp[4] = (W_)BCO_PTR(arg3_freeVars); // the info about local vars of the breakpoint Sp[3] = (W_)False_closure; // True <=> a breakpoint hunk ./rts/Interpreter.c 885 - Sp[2] = (W_)&stg_ap_pppv_info; + Sp[2] = (W_)&stg_ap_ppp_info; Sp[1] = (W_)ioAction; // apply the IO action to its two arguments above Sp[0] = (W_)&stg_enter_info; // get ready to run the IO action hunk ./rts/Interpreter.c 888 - // Note [unreg]: in unregisterised mode, the return - // convention for IO is different. The - // stg_noForceIO_info stack frame is necessary to - // account for this difference. // set the flag in the TSO to say that we are now // stopping at a breakpoint so that when we resume
participants (2)
-
Peter Hercek -
Simon Marlow