<div dir="ltr"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">I am following up on an earlier conversation here with respect to jit stack traces. Any thing changed here with respect to latest llvm versions..</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="monospace, monospace">On Wed, Nov 13, 2013 at 08:51 AM, Reid Kleckner </font><<a href="mailto:llvm-dev%40lists.llvm.org?Subject=Re%3A%20%5BLLVMdev%5D%20Stack%20traces%20from%20JIT%20code&In-Reply-To=%3CCACs%3Dty%2BS9Y6KFJU0qCS%3D-zV%3DeKVe9D2Yg5nnyX2mFbZhv5%2Bayg%40mail.gmail.com%3E" title="[LLVMdev] Stack traces from JIT code" style="font-family:monospace,monospace;font-size:medium;white-space:normal">rnk at google.com </a><span style="font-family:monospace,monospace">> wrote:</span></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="monospace, monospace"><i>> Writing your own JITEventListener is probably the best way to capture</i><br></font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><pre style="white-space:pre-wrap"><i><font face="monospace, monospace">> traces from production.  Using the existing gdb/JIT interface support is

> probably far too heavyweight for production.  If you roll your own, you can

> record the PC ranges efficiently and that should be good enough to capture

> traces from production.</font>

</i>

On Tue, Nov 12, 2013 at 2:56 PM, Priyendra Deshwal

<<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">deshwal at thoughtspot.com</a>>wrote:

><i> [Resending this email after subscribing to the group. Got an error message

</i>><i> the previous time around]

</i>><i>

</i>><i> Hey guys,

</i>><i>

</i>><i> In our project we have the following workflow:

</i>><i>

</i>><i> - Given a user request, we construct a C++ program to service the request

</i>><i> - We create a compiler invocation to compile that program into an IR module

</i>><i> - We use JIT (and optionally MCJIT) to convert the IR into executable code

</i>><i> and run it

</i>><i>

</i>><i> Occasionally, we have a crash in the JIT code and we are looking to figure

</i>><i> out best practices around debuggability. With the MCJIT option, we can

> debug in gdb so that is already a big step forward.

</i>><i>

</i>><i> However, that does not work for a production crash. We want to capture the

</i>><i> stack trace from the crash and write it to stderr. Our binary has a signal

</i>><i> handler that does stack unwinding and symbolization upon crash. Based on my

</i>><i> reading so far, we need to implement a JITEventListener which would keep

</i>><i> track of the dynamically generated symbol addresses and use the resulting

> maps for symbolization.

</i>><i>

> Will that work? Is there a simpler way?

</i>><i>

</i>><i> Thanks,

</i>><i> -- Priyendra</i></pre></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><br></pre></div>