<div dir="ltr">Without any overhead we'll get the runtime stack trace, which isn't exactly the same as what we can get with emulation, but has the benefit that we can leave it on in all of our shipped code if we like. This latter is a really crucial property for stack traces to be widely useful.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 13, 2014 at 7:13 PM, Ömer Sinan Ağacan <span dir="ltr"><<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry for my previous email. (used a gmail shortcut by mistake)<br>
<br>
We won't have stacks as we have in imperative(without TCO) and strict<br>
languages. So we still need some kind of emulation and I think this<br>
means some extra run-time operations. I'm wondering about two things:<br>
<br>
1) Do we still get same traces as we get using GHC.Stack right now?<br>
2) If yes, then how can we have that without any runtime costs?<br>
<br>
Thanks and sorry again for my previous email.<br>
<div class=""><br>
---<br>
Ömer Sinan Ağacan<br>
<a href="http://osa1.net" target="_blank">http://osa1.net</a><br>
<br>
<br>
</div>2014-08-13 20:08 GMT+03:00 Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com">omeragacan@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Will generated stack traces be different that<br>
><br>
> ---<br>
> Ömer Sinan Ağacan<br>
> <a href="http://osa1.net" target="_blank">http://osa1.net</a><br>
><br>
><br>
> 2014-08-13 19:56 GMT+03:00 Johan Tibell <<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>>:<br>
>> Yes, it doesn't use any code modification so it doesn't have runtime<br>
>> overhead (except when generating the actual trace) or interfere with<br>
>> compiler optimizations. In other words you can actually have it enabled at<br>
>> all time. It only requires that you compile with -g, just like with a C<br>
>> compiler.<br>
>><br>
>><br>
>> On Wed, Aug 13, 2014 at 6:45 PM, Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com">omeragacan@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Is this stack trace support different than what we have currently?<br>
>>> (e.g. the one implemented with GHC.Stack and cost centers)<br>
>>><br>
>>> ---<br>
>>> Ömer Sinan Ağacan<br>
>>> <a href="http://osa1.net" target="_blank">http://osa1.net</a><br>
>>><br>
>>><br>
>>> 2014-08-13 18:02 GMT+03:00 Johan Tibell <<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>>:<br>
>>> > Hi,<br>
>>> ><br>
>>> > How's the integration of DWARF support coming along? It's probably one<br>
>>> > of<br>
>>> > the most important improvements to the runtime in quite some time since<br>
>>> > unlocks *two* important features, namely<br>
>>> ><br>
>>> >  * trustworthy profiling (using e.g. Linux perf events and other<br>
>>> > low-overhead, code preserving, sampling profilers), and<br>
>>> >  * stack traces.<br>
>>> ><br>
>>> > The former is really important to move our core libraries performance up<br>
>>> > a<br>
>>> > notch. Right now -prof is too invasive for it to be useful when<br>
>>> > evaluating<br>
>>> > the hotspots in these libraries (which are already often heavily tuned).<br>
>>> ><br>
>>> > The latter one is really important for real life Haskell on the server,<br>
>>> > where you can sometimes can get some crash that only happens once a day<br>
>>> > under very specific conditions. Knowing where the crash happens is then<br>
>>> > *very* useful.<br>
>>> ><br>
>>> > -- Johan<br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > ghc-devs mailing list<br>
>>> > <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>>> > <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
>>> ><br>
>><br>
>><br>
</div></div></blockquote></div><br></div>