few questions about GHC RTS

[Simon Marlow]

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