how dynamic stack approximation works

[Peter Hercek]

Simon Marlow wrote:
> Perhaps you're already aware of this wiki page, but I'll post the link 
> anyway:
>
> http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack

I was writing about a way how to maintain the stack as described in 
point 6 of the page (provided that point is about dynamic stack). The 
point only says it would be fine to have stack without hints how to do it.

>
> The dynamic call stack is already present, in the form of the runtime 
> execution stack.  For debugging you might want to track more 
> information than we store on this stack, however.

Does GHC have the same stack for both return addresses and arguments or 
are they separated? I assumed separated but I'm in doubt now. Do you 
have enough (debug) information there already to at least match 
arguments to function calls?

My point is that having an exact stack is probably better if it is not 
too hard to do. On the other side if there is not enough debug 
information already present, it may be easier to to maintain an 
approximate debugging stack because most of the information needed for 
it is already in there.

As I already said in other emails, I would rather choose dynamic stack 
over lexical one if I was forced to choose only one of them. Actually, I 
almost do not care about lexical stack and still do not understand why 
people want it. Even for profiling it looks fishy because at least in 
some cases it behaves like a dynamic stack (time is attributed where 
expression is forced not where the expression looks to be in the lexical 
stack).

> You seem to have a plan for maintaining a dynamic stack for debugging, 
> perhaps you could flesh out the details in a wiki page, mainly to 
> ensure that we're discussing the same thing?

Sure, but the plan to maintain an approximate debugging dynamic stack 
depends on one thing:
The number of items (continuations) on the return stack  from the 
beginning of /case tick<n> of {_->e}/ to the moment when we can check 
the count of items in the return stack inside /tick<n>/ is constant and 
known for a given runtime version of ghc. Or variable but known for each 
call individually. This is important to find out the number of return 
addresses on the return stack just before the execution of /case tick<n> 
of {_->e}/.

This looks achievable to me, but maybe it is not.
Do you think the condition can be satisfied without too much work?
If yes, I'll go on to write the page. If not it would be waste of time.

Thanks,
   Peter.