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
pepe wrote: 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.