search for: jiteventlisten

Hello, I've recently finished moving a cross-platform project to LLVM 3.0 and now transitioning to 3.1. One of the things I've hit is on OS X, I have linker errors involving JITEventListener and I've noticed if I move the JITEventListener destructor out of JIT.cpp and into JITEventListener.h (like other functions of JITEventListener), the linker is much happier. I'd like to push this change back to LLVM trunk if people think it is good. What do I need to do to gain blessing...

...I'm also a bit confused about RTDyldObjectLinkingLayer's notify integration. NotifyLoadedFtor is a class template parameter, but NotifyFinalizedFtor is just a std::function defaulting to empty? Is that just for historical raisins, or is there a deeper reason? To be able to use existing JITEventListeners - it'd surely be a shame to have to rewrite them anew - in custom stacks it also appears that there's no easy way to call JITEventListener->NotifyFreeingObject() - the to-be-freed objects aren't readily available in RTDyldObjectLinkingLayer. Greetings, Andres Freund

Hi All, Just a couple of updates this week: First: there is a preview patch up at https://reviews.llvm.org/D75838 to enable use of JITEventListeners in RTDyldObjectLinkingLayer. I've only done very preliminary testing on it, but was able to debug simple JIT'd programs on Linux using the GDB registration listener. If you've been wanting to move to ORC but held up by lack of debugger / profiler registration, chime in on the review...

...ntend to use this to support oprofile's ability to symbolize JITted > code through the interface described at > http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I > believe the interface will also be useful 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 &g...

I intend to use this to support oprofile's ability to symbolize JITted code through the interface described at http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I believe the interface will also be useful 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 informa...

...ss with the performance > tools? We're pushing to be more thread safe. As Eric said, this is just moving existing code, and it's #ifdef'ed out. I'll let the Shark folks invent a better solution. :) > +struct FunctionEmittedEvent { > +  // Indices are local to the RecordingJITEventListener, since the > +  // JITEventListener interface makes no guarantees about the order of > +  // calls between Listeners. > +  int Index; > > Use "unsigned" instead of "int"? Can index ever be negative? Sure, it's unsigned now. > On Jun 24, 2009, at 1:26 PM...

...of pre-compiled code to avoid re-compilation. > -- > 2.11.0.22.g8d7a455.dirty > > From debc641fbc5980461f8d36e534d5a6de70e0a293 Mon Sep 17 00:00:00 2001 > From: Andres Freund <andres at anarazel.de> > Date: Wed, 1 Feb 2017 23:10:45 -0800 > Subject: [PATCH 2/2] Add PerfJITEventListener for perf profiling support. > > --- > CMakeLists.txt | 13 + > include/llvm/Config/config.h.cmake | 3 + > include/llvm/Config/llvm-config.h.cmake | 3 + > include/llvm/ExecutionEngine/JITEventListener.h |...

...it-interface.txt > > A year or so perf also gained the ability to actually see code & debug > info. It's even being documented now: > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=b3151ea500655f232255ddcdf2bbcf691cb39646 > > I've a very preliminary JITEventListener using both of this. Is there > interest in integrating that into LLVM? If so, I'll try to follow LLVM > coding standards and submit it, otherwise I'll keep it somewhere in > postgres... > > If in LLVM, does anybody have preference about how to integrate the two > method...

...tion? From what I can tell, the event listener is responsible for allocating symbol table memory so it effectively owns it. Can we register the address with the performance tools? We're pushing to be more thread safe. +struct FunctionEmittedEvent { + // Indices are local to the RecordingJITEventListener, since the + // JITEventListener interface makes no guarantees about the order of + // calls between Listeners. + int Index; Use "unsigned" instead of "int"? Can index ever be negative? Evan On Jun 24, 2009, at 1:26 PM, Jeffrey Yasskin wrote: > Ack, sorry. I should h...

...otifiers-only-after-code-sections-ar.patch Type: text/x-patch Size: 2617 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170201/19627903/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-PerfJITEventListener-for-perf-profiling-support.patch Type: text/x-patch Size: 22529 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170201/19627903/attachment-0003.bin> -------------- next part -------------- #include <stdint.h> #include <stdbool.h> bool stup...

> Last time I tried it was some months ago with LLVM 9. I'll try it > shortly with LLVM trunk/master and report back. Finally, I found the time to try it out again. And it works fine in LLVM master. I haven't tried any other LLVM version. Profiling with perf on assembly level works fine. And so does gdb. One can set pending breakpoints on the to be generated function and execution

...1103 -- if you're interested in C APIs for OrcV2 please get involved. I would especially appreciate feedback and patches from C API users: I don't have a use case for the C APIs myself, so I'm just guessing as to what you need/want most from these APIs. Other notes from this week: The JITEventListeners support patch in https://reviews.llvm.org/D75838 will be (re)committed along with some example code as soon as I work out the kinks in the object buffer ownership -- Hopefully Monday or Tuesday this week. LLJIT now enables exception handling for MachO by default (7266a8bfeb8). RuntimeDyldCOFF...

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

...e/tools/perf/Documentation/jit-interface.txt A year or so perf also gained the ability to actually see code & debug info. It's even being documented now: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=b3151ea500655f232255ddcdf2bbcf691cb39646 I've a very preliminary JITEventListener using both of this. Is there interest in integrating that into LLVM? If so, I'll try to follow LLVM coding standards and submit it, otherwise I'll keep it somewhere in postgres... If in LLVM, does anybody have preference about how to integrate the two methods above? Because the second...

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

Hi, On 2020-03-09 21:20:44 +0100, Frank Tetzel via llvm-dev wrote: > I think, debugging and profiling support is very important for a JIT > engine. I could never get it to work with older LLVM versions. Is there > example code somewhere available? Since I added the perf listener I probably can help you with that. What exactly was the problem you were hitting? I don't have isolated

Yeah, that's probably how I'd do it. Might be useful if you guys want to contribute that as a command line option Kevin. -eric On Tue, Jun 24, 2014 at 3:03 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > We do this in Pyston using a JITEventListener that just disassembles the > output; it's "it works let's move on"-quality: > https://github.com/dropbox/pyston/blob/master/src/codegen/dis.cpp > > I'm not sure how efficient the disassembling is, but at least the process is > pretty self-contained. > >...

...at 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/llv...

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

...s 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<mailto: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...