how dynamic stack approximation works

[Simon Marlow]

Peter Hercek wrote:
> Simon Marlow wrote:
>> 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}/.

I don't fully understand what it is you mean.  e.g. I don't know what "from 
the beginning of /case tick<n> of {_->e}/" means.

Let me try to explain a couple of things that might (or might not!) help 
clarify.  We don't normally see

  case tick<n> of { _ -> e }

because the byte-code generator turns this into

  let
      z = case tick<n> of { _ -> e }
  in
      z

the debugger paper explains why we do this.  Anyway, the byte code for the 
closure for z does this:

   - if the breakpoint at <n> is enabled then stop,
   - otherwise, evaluate e

i.e. it doesn't push any stack frames.

Does that help frame your question?

Cheers,
	Simon