search for: notifyfunctionemit

Great stuff; thanks both! I'm also looking to turn my MCJIT conversion spike into our main use case. The only thing I'm missing is the ability to get a post-linked copy of the generated assembly. In JIT I used JITEventListener's NotifyFunctionEmitted and used a MCDisassembler to disassemble the stream (with my own custom annotators), and redirected the output to the relevant place for auditing of our app. With MCJIT I notice that NotifyFunctionEmitted is gone (understandably) and so I hook NotifyObjectEmitted. I then run through all the fun...

Thanks Andrew for the update. Does it support NotifyFunctionEmitted? Cheers. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:06 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC The current 3.2 code branch has events bein...

...vent, '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 [mailto:Manny.Ko at imgtec.com] Sent: Monday, November 26, 2012 1:10 PM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC Thanks Andrew for the update. Does it suppo...

...> Great stuff; thanks both! >> >> I'm also looking to turn my MCJIT conversion spike into our main use >> case. The only thing I'm missing is the ability to get a post-linked >> copy of the generated assembly. >> >> In JIT I used JITEventListener's NotifyFunctionEmitted and used a >> MCDisassembler to disassemble the stream (with my own custom >> annotators), and redirected the output to the relevant place for >> auditing of our app. >> >> With MCJIT I notice that NotifyFunctionEmitted is gone >> (understandably) and so I hoo...

...vent, '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 [mailto:Manny.Ko at imgtec.com] Sent: Monday, November 26, 2012 1:10 PM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC Thanks Andrew for the update. Does it suppo...

...seful for gdb support. I'm considering adding some flags to the JITEventListener to let the JIT avoid collecting information no listener is going to use, but I won't do that until there's a need. I've added EmittedFunctionDetails in this patch so that I don't have to change the NotifyFunctionEmitted() interface in a future patch. To record line number information, oprofile wants an array of structs of the form: struct debug_line_info { unsigned long vma; unsigned int lineno; /* The filename format is unspecified, absolute path, relative etc. */ char const * fil...

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 e...

...m > considering adding some flags to the JITEventListener to let the JIT > avoid collecting information no listener is going to use, but I won't > do that until there's a need. > > I've added EmittedFunctionDetails in this patch so that I don't have > to change the NotifyFunctionEmitted() interface in a future patch. To > record line number information, oprofile wants an array of structs of > the form: > >  struct debug_line_info { >       unsigned long vma; >       unsigned int lineno; >       /* The filename format is unspecified, absolute path, relative...

...dding some flags to the JITEventListener to let the JIT >> avoid collecting information no listener is going to use, but I won't >> do that until there's a need. >> >> I've added EmittedFunctionDetails in this patch so that I don't have >> to change the NotifyFunctionEmitted() interface in a future patch. To >> record line number information, oprofile wants an array of structs of >> the form: >> >> struct debug_line_info { >> unsigned long vma; >> unsigned int lineno; >> /* The filename format is unspecifi...

...Wednesday, November 13, 2013 9:23 AM > *To:* Reid Kleckner > *Cc:* llvmdev at cs.uiuc.edu > *Subject:* Re: [LLVMdev] Stack traces from JIT code > > > > 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 hand...

...the JITEventListener to let the JIT >>> avoid collecting information no listener is going to use, but I won't >>> do that until there's a need. >>> >>> I've added EmittedFunctionDetails in this patch so that I don't have >>> to change the NotifyFunctionEmitted() interface in a future patch. To >>> record line number information, oprofile wants an array of structs of >>> the form: >>> >>>  struct debug_line_info { >>>       unsigned long vma; >>>       unsigned int lineno; >>>       /* The...

...uc.edu] On Behalf Of Andrew MacPherson Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces from JIT code 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 e...

...n Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] Stack traces from JIT code 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 e...

Hi Jim, Thanks for a very quick reply! That indeed does the trick! Presumably the default has changed in 3.5 to be a "generic" CPU instead of the native one? If that's the case I wonder why: especially when JITting it really only makes sense to target the actual CPU - unless I'm missing something? :) Thanks again, Matt On Wed, Sep 17, 2014 at 2:16 PM, Jim Grosbach

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

...lor at intel.com> wrote: > The fact that you are getting line number information leads me to > believe that whether you intended it or not you are using the old JIT > (which is now gone), not MCJIT. The “Mapping 0x7f5ed6893032 to loopy.c:13” > lines come from a path called through NotifyFunctionEmitted and as far as I > know nothing in MCJIT calls that. > > > > At one time oprofile support worked completely with the old JIT. It > sounds like you might have a build where the old JIT was partially > dismantled. That may or may not be why things aren’t working for you. >...

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

[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

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

I've been trying to get oprofile results for jitted code without success. I built an 3.5.0 llvm with oprofile enabled, and tested it with lli on a small test case. I built the latest oprofile from the git repository. Debugging I can see that lli is registering the listener and making the oprofile calls to the libopagent api to specify the names and address ranges of jit'd routines, and