[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/20131112/e6677a44/attachment.html>
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>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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/022e9b64/attachment.html>
We implemented a similar solution for handling crashes in production but one issue we came across with MCJIT was that the NotifyFunctionEmitted call from the old JIT was replaced with NotifyObjectEmitted. The ObjectImage used by NotifyObjectEmitted does have a way of iterating symbols but non-external functions used in the module didn't seem to appear in this list so we were left with some gaps in our symbol handling coverage when execution involved these. If there's a way around it that would be great, otherwise something to keep in mind. Cheers, Andrew On Wed, Nov 13, 2013 at 5:51 PM, Reid Kleckner <rnk at google.com> 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> 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 >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/eea57069/attachment.html>