search for: objectimag

...nyway. The place where I'm handling the debug information is outside MCJIT and the MCJIT relocation code isn't really accessible at that point. Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing an ObjectImage reference as the parameter to the listener. The only current listener I'm aware of is the IntelJITEventListener, which wants to notify the Intel VTune Amplifier (if present) about the newly JITed functions. The listener uses the ObjectImage interface (which is modeled after the ObjectFile in...

...have to map the program counter to a function name. So we need a simple symbol info that maps from address ranges to function names. When we implemented this functionality, there was no method in the RuntimeDyld to iterate over all loaded functions. In LLVM3.3, though, I see that loadModule returns ObjectImage. So maybe now I could access the symbols directly from ObjectImage, without patching RuntimeDyld. I will try that. > Are you considering submitting your patches for incorporation into LLVM trunk? Yes, we would be glad to contribute our patches. I have to retest everything on trunk, because un...

...ormat generated by llc. It is properly loaded by mcjit. I noticed that the reason is probably in lack of calling "registerWithDebugger()" after object loading. Adding this registration to the addObjectFile function body causes crash in runtime, probably because the Buffer member in loaded ObjectImage is null. Am I right? Do you have any idea how it can be fixed without reimplementation od loading objects in RuntimeDyld? Regards. rodia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141120/c8913485/attac...

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something? If this isn't what

I'm working on adding source-based profiling support for MCJIT and in the process of implementing this, I came across a test case where an object is being generated that wants to have relocations applied to the .debug_line section. I see in the DebugInfo code that it currently only supports relocations applied to either the .debug_info or the .debug_info.dwo section. Can anyone give me an

...references both of these buffers. The situation is further compilicated in the case where the RuntimeDyldELF object attempts to register the generated object with GDB, because the GDB-interface requires a reference to both memory buffers. The GDB_required references are currently maintained in an ObjectImage instance which is held by RuntimeDyldELF. For those who are visually oriented, I am attaching a diagram which shows the object relationships. I would like to change this by introducing an ObjectBuffer which would be allocated by the MCJIT object at compilation time and then passed to the Runtime...

...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 > execution involved these. If there's a way around it tha...

...references both of these buffers. The situation is further compilicated in the case where the RuntimeDyldELF object attempts to register the generated object with GDB, because the GDB-interface requires a reference to both memory buffers. The GDB_required references are currently maintained in an ObjectImage instance which is held by RuntimeDyldELF. For those who are visually oriented, I am attaching a diagram which shows the object relationships. I would like to change this by introducing an ObjectBuffer which would be allocated by the MCJIT object at compilation time and then passed to the Runtime...

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

...references both of these buffers. The situation is further compilicated in the case where the RuntimeDyldELF object attempts to register the generated object with GDB, because the GDB-interface requires a reference to both memory buffers. The GDB_required references are currently maintained in an ObjectImage instance which is held by RuntimeDyldELF. > > For those who are visually oriented, I am attaching a diagram which shows the object relationships. > > I would like to change this by introducing an ObjectBuffer which would be allocated by the MCJIT object at compilation time and then...

> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else? IIRC, this error might be due to not linking against the MCJIT library component. Add the

...du<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 execution involved these. If there's a way around it that would be great, ot...

...le at that point.**** > > ** > I know it doesn't, that's why I made the "non-alloc" comment. :) > ** > > Right now, when MCJIT emits an object image, it broadcasts an event to any > registered listeners indicating that an object was emitted, passing an > ObjectImage reference as the parameter to the listener. The only current > listener I’m aware of is the IntelJITEventListener, which wants to notify > the Intel VTune Amplifier (if present) about the newly JITed functions.*** > * > > ** > OK. > ** > > > > The problem is th...

...a function that exists in the cache. I've traced into the cache call, and could see that my getObject() returned the right object. The object is loaded and no error was reported by ( MCJIT::generateCodeForModule(Module *M)): // Load the object into the dynamic linker. // MCJIT now owns the ObjectImage pointer (via its LoadedObjects list). ErrorOr<std::unique_ptr<object::ObjectFile>> LoadedObject = object::ObjectFile::createObjectFile(ObjectToLoad->getMemBufferRef()); std::unique_ptr<RuntimeDyld::LoadedObjectInfo> L = Dyld.loadObject(*LoadedObject.get()); if (...

...;r1=188725&r2=188726&view=diff ============================================================================== --- llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp (original) +++ llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp Mon Aug 19 18:27:43 2013 @@ -169,6 +169,9 @@ ObjectImage *RuntimeDyldImpl::loadObject } } + // Give the subclasses a chance to tie-up any loose ends. + finalizeLoad(); + return obj.take(); } @@ -424,6 +427,10 @@ uint8_t *RuntimeDyldImpl::createStubFunc writeInt16BE(Addr+6, 0x07F1); // brc 15,%r1 // 8-byte address stored at...

...eid 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 execution involved these. If there's a way around it that would be great, ot...

>> To increase stability for us we have already moved the main part of the compilation to a separate process that may crash in case of an error without doing much harm, i.e. does not crash the database. > Were there any interesting challenges that arose during this process? > This seems to be an approach many folks are either taking or > considering. If there are things we could

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

[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

...he MCJIT relocation code isn't really accessible at that point. I know it doesn't, that's why I made the "non-alloc" comment. :) Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing an ObjectImage reference as the parameter to the listener. The only current listener I'm aware of is the IntelJITEventListener, which wants to notify the Intel VTune Amplifier (if present) about the newly JITed functions. OK. The problem is that I have a test case that is trying to reference an inlined...