how dynamic stack approximation works

[Peter Hercek]

pepe wrote:
> Having (a kind of messy approximation of) a dynamic stack is possible 
> with a variant of the cost center stacks mechanism used for profiling. 
> But the downside is that code and libraries would need to be compiled 
> for debugging.
Is there any info somewhere why the approximation of the dynamic stack 
needs libraries to be recompiled for debugging? I thought about it but I 
could not figure out why it would be needed. Here is what I thought is 
the way it works:

* the ticks only inform about the approximate start of the selected 
expression; this is acceptable provided it makes it much easier to implement
* 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

Provided the above is true then we can find out the number of items on 
the return stack which was valid just before /case tick<n> of {_->e}/ 
was entered. Lets mark this number as tick_stack_size<n>. Then the only 
thing we need to build the approximation of the dynamic stack is to get 
a callback from the runtime just before the number of items in the 
return stack gets below tick_stack_size<n> for the corresponding /case 
tick<n> of {_->e}/ expression. That is the moment of "step out" from the 
selected expression and that is the moment when we can pop an item from 
our dynamic stack approximation. (Each entering of /tick<n>/ pushes one 
item to the dynamic stack approximation.)

All the requirements to implement the above way seem to be easy to do 
and they do not look like having too bad speed consequences. Just one 
indirect memory access and a conditional jump more for each pop of a 
continuation address from the return stack. And the most important thing 
is that it does not matter whether a library you use is "strobed" with 
ticks or not. If a library is not "strobed" it would just look like one 
item in the approximation of the dynamic stack. If a library is not 
interpreted (it is not being debugged) we do not want to be bugged with 
its stack frames anyway ... probably. It looks to me better this way 
without any experience with it yet. Some of the conditional jumps would 
happen and would result in more work (maintaining the approximation of 
the dynamic stack), but all non-tagged value accesses would not as well 
as all expressions which are not annotated with ticks (like e.g. list 
creation).

Anyway, since the libs would be needed to be compiled for debugging 
something in the above is wrong. I would like to know what is wrong or 
some pointer to some web page or paper which describes how the 
approximation of the dynamic stack works for profiler. I cannot think of 
other way the profiler dynamic stack approximation would work :-/

Thanks,
  Peter.