search for: jiteventlisteners

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

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

Ack, sorry. I should have sent this to llvm-commits instead. :-P Followups there please. On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey Yasskin<jyasskin at google.com> wrote: > 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

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

On Wed, Jun 24, 2009 at 2:43 PM, Evan Cheng<evan.cheng at apple.com> wrote: > Hi Jeffrey, > > This looks very good. Thanks. Some comments: > > +/// JitSymbolEntry - Each function that is JIT compiled results in > one of these > +/// being added to an array of symbols.  This indicates the name of > the function > +/// as well as the address range it occupies.  This

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

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. 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

Hi Jeffrey, This looks very good. Thanks. Some comments: +/// JitSymbolEntry - Each function that is JIT compiled results in one of these +/// being added to an array of symbols. This indicates the name of the function +/// as well as the address range it occupies. This allows the client to map +/// from a PC value to the name of the function. +struct JitSymbolEntry { A nitpick. Please

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

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

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, Under linux a large portion of the profiling these days happens with perf, but there's no support for it from LLVM's JITs. For a while perf could associate address+size to symbols by writing a /tmp/perf-$pid.map file: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/Documentation/jit-interface.txt A year or so perf also gained the ability to actually

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

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: >

[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

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

>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: