similar to: [LLVMdev] Stack traces from JIT code

[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

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

>From NotifyObjectEmitted you should be able to get to any function that's visible via either the ELF headers or the DWARF information. Do you have functions that don't show up in either of those places? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew MacPherson Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc:

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

Yeah, take a look at the IntelJITEventListener code (in lib/ExecutionEngine/IntelJITEvents). It uses the debug info to find function names. -Andy From: Andrew MacPherson [mailto:andrew.macp at gmail.com] Sent: Wednesday, November 13, 2013 1:12 PM To: Kaylor, Andrew Cc: Reid Kleckner; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces from JIT code Hi Andy, In the NotifyObjectEmitted

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

Hi Andy, In the NotifyObjectEmitted method of our derived JITEventListener class we use the begin_symbol() iterator to walk the object's symbols looking for functions and only functions marked with ExternalLinkage seem to show up. I'm not sure how I would access the Dwarf info from within there, is there a way? Thanks, Andrew On Wed, Nov 13, 2013 at 8:23 PM, Kaylor, Andrew

Thanks for the info. I am using old JIT. So that should not be a problem. I will take a look at using oprofile. I have never used it - so will be somewhat of a learning curve. I notice that the configure script has a --with-oprofile option. In addition to enabling that, is there something else that also needs to be done? My copy of LLVM is compiled with --enable-optimized. Will --with-oprofile

Hi Priyendra, There is support for oprofile and Intel(r) VTune(tm) Performance Analyzer, but either one needs to be explicitly turned on during the build process. If you use MCJIT (as opposed to the older JIT) then oprofile support isn't in place yet. Both of these work by providing a JITEventListener that receives notification when new code is emitted and hooks it up to the profiling tool

Hey guys, I am currently working on a project that uses JIT compilation to compile incoming user requests to native code. Are there some best practises related to profiling the generated code? My project uses gperftools pprof for profiling etc. Is there a way to hook the two up? Are there any other profiling method that works? This page describes how to debug JIT code with GDB. I wonder if

I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though. Another critical feature missing from MCJIT is the JITEventListener. This is usually for supporting debuggers and profiling tools. Ciao. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Albert

On Mon, Nov 26, 2012 at 9:18 AM, Manny Ko <Manny.Ko at imgtec.com> wrote: > I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though. > > Another critical feature missing from MCJIT is the JITEventListener. This is usually for supporting debuggers and profiling tools. What makes you say it is missing? Eli

Hi, On 2017-02-01 23:20:40 -0800, Andres Freund wrote: > > Can you give a pointer to the patch so that I can assess the rough > > complexity? If it's simple enough, I'd be happy to help get it > > reviewed and in. If it's more complicated, I probably won't have the > > time to assist. > > Patch (and a prerequisite) attached. Took me a while to get

The current 3.2 code branch has events being broadcast from the MCJIT engine when a new object is emitted, but the profiling listeners do not do anything with the events (and I don't expect they will before the 3.2 release becomes official). I have implemented some code in trunk since the 3.2 branch to traverse the emitted object and pick out named functions in the IntelJITEventsListener. An

Yes, the GDB-jit registration stuff got pulled out (perhaps prematurely). That said, even without function names, it's still useful to have the EH bits so that gdb can unwind through the JIT'ed frames. Otherwise gdb (and glibc's backtrace() function, valgrind, etc) end up stopping the unwind prematurely, usually at the first JIT'ed frame. Combined with trivial use of the

Ops. I meant to say 3.1. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manny Ko Sent: Monday, November 26, 2012 9:27 AM To: Eli Bendersky Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC Sorry for speaking too soon. It is missing from 3.2 which is the

No. It adds a new event, 'NotifyObjectEmitted'. The Intel JIT listener that I mentioned then uses the emitted object to find the functions (which are all emitted together). Because of the way that MCJIT is implemented, it isn't really feasible to reconstruct things like the EmittedFunctionDetails in the NotifyFunctionEmitted event. -Andy -----Original Message----- From: Manny Ko

Sorry for speaking too soon. It is missing from 3.2 which is the version I have been using. If it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To: Manny Ko Cc: Albert Graef; Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT

HI Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging

I see. If I am writing my own listener can I still get back the (llvm::Function, void* Code, size_t Size)? Ciao. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:24 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC No. It adds a new event,