[llvm-dev] jit stack traces
Ashok Anand via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 3 17:05:46 PST 2018
I am following up on an earlier conversation here with respect to jit
stack traces. Any thing changed here with respect to latest llvm
On Wed, Nov 13, 2013 at 08:51 AM, Reid Kleckner <rnk at google.com
*> 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
>* [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?
*>* -- Priyendra*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev