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..
On Wed, Nov 13, 2013 at 08:51 AM, Reid Kleckner <rnk at google.com
<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>>
wrote:
*> Writing your own JITEventListener is probably the best way to capture*
*> 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.
*
On Tue, Nov 12, 2013 at 2:56 PM, Priyendra Deshwal
<deshwal at thoughtspot.com
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>>wrote:
>* [Resending this email after subscribing to the group. Got an error message
*>* the previous time around]
*>>* Hey guys,
*>>* In our project we have the following workflow:
*>>* - Given a user request, we construct a C++ program to service the
request
*>* - We create a compiler invocation to compile that program into an IR
module
*>* - We use JIT (and optionally MCJIT) to convert the IR into executable
code
*>* and run it
*>>* Occasionally, we have a crash in the JIT code and we are looking to
figure
*>* out best practices around debuggability. With the MCJIT option, we can
*>* debug in gdb so that is already a big step forward.
*>>* However, that does not work for a production crash. We want to
capture the
*>* stack trace from the crash and write it to stderr. Our binary has a
signal
*>* handler that does stack unwinding and symbolization upon crash. Based on
my
*>* reading so far, we need to implement a JITEventListener which would keep
*>* track of the dynamically generated symbol addresses and use the resulting
*>* maps for symbolization.
*>>* Will that work? Is there a simpler way?
*>>* Thanks,
*>* -- Priyendra*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/6515b817/attachment.html>
