similar to: [LLVMdev] MCJit interface question

Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Friday, May 29, 2015 2:23 PM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJit interface

Hi Joseph, There are several reasons that a client might want to access the object before it's loaded, so a general API like #2 seems like the way to go. To support this in MCJIT you can add this to the event listener API. Orc clients can already do this by adding a custom object-file layer. - Lang. On Fri, May 29, 2015 at 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com> wrote:

Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks,

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

When we were using MCJIT, I could do this: // Attach the event listener Context.EE->RegisterJITEventListener( LLILCJitEventListener::createLLILCJitEventListener( new LLILCJitEventWrapper(&Context))); The event listeners listened for when an object is emitted (NotifyObjectEmitted), and that’s when we’d go through and extract debug info from the ObjectFile. Now, I imagine

I work on the LLILC team, and we are trying to send debug line info through to the CoreCLR EE without using an EventListener because we need to send extra info (more than just available in DebugLoc) like if it’s a call instruction, a call site, etc. We thought extending AsmPrinterHandler would be useful since it seems to have information about debug locations, label offsets, and instruction

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of

Hi Bjoern, For single object files you can override the needsToReserveAllocationSpace method that is inherited from llvm::RuntimeDyld::MemoryManager (make it return true) and then implement the reserveAllocationSpace method to allocate memory for all sections up front. There is no easy way to do this for multiple object files. I think you would have to mimic the memory size calculations

The LLILC project does not require direct interaction with the PDB, so it’s not part of our plans. The JIT uses a special reporting format to communicate debug info (frame info and machine->IL mappings) back to the CoreCLR EE. The debugger joins this with the frontend-produced debug information (IL->source and logical frame offset->local, which is in a PDB) to complete the picture.

I'm catching up on this. Does this mean LLVM x64 JITTed code is not exception friendly or you can't catch exceptions inside LLVM JITTed code. The first one seems to indicate that the code is not ABI friendly or that not enough information is present to notify Windows of unwind tables. I'll ask the question another way: Does LLVM emit enough information so that RtlAddFunctionTable can

Thanks for the pointer, it's always helpful to be able to see how another project solved similar problems. > On Mar 8, 2016, at 11:24 AM, Andy Ayers <andya at microsoft.com> wrote: > > FWIW, LLILC (https://github.com/dotnet/llilc) uses MCJIT with a custom memory manager to hold onto the binary bits and discard the rest. > > As far as I know it doesn't leak, though

Hi Bjoern, I'm trying to make exceptions run. I have an Object file with a function, > throwing a 1 and a second function which should catch the 1. Normal JITTING > under Windows showed me, that I have an unresolved reference to the virtual > table of type_info. Some experiments later I was able to load "msvcrt.lib" > as an archive and could resolve the reference. Nice -

(background) The CoreCLR expects a JIT to produce a MSIL bytecode offset to code offset mapping annotated with a few extra bits denoting if it’s prolog/epilog, or it’s a call, or if there’s operands remaining on the MSIL virtual stack in some cases. Our initial prototype has the MSIL offset stashed in the line number field. We could stash the extra bits in the column info but that’s starting to

That's encouraging. Assuming that all access to the JITted code is going to be done through a function pointer, and all JIT code is ephemeral, why is the object container format important? In fact, why is it even needed? I found it somewhat odd that MCJIT generates an object file for even the JIT case. To answer my own question, could it be that advanced JIT's may need/want to use things

YES. My use of LLVM involves an app that JITs program after program and will quickly swamp memory if everything is retained. It is crucial to aggressively throw everything away but the functions we still need to execute. I've been faking it with old JIT (llvm 3.4/3.5) by using a custom subclass of JITMemoryManager that squirrels away the jitted binary code so that when I free the Modules,

Hi Lang, Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me: void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero.

Hey everyone, I'm looking into extending AsmPrinterHandler out of tree, to communicate information back to the CoreCLR EE, but all of the headers are in the lib directory. Is there any way to extend it out of tree, or is that not supported? The reason I'd like to do this out of tree is because we want to include clr headers as well, and we don't want to introduce that into llvm

> I tried loading the "msvcrt.lib" as a archive. That was... a bad idea! > I get a Exception while loading: > Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation > overflow", file > \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81 It's a limitation of the COFF/PE format and unrelated to exceptions. This patch

Chandler has it right. Our intent is to upstream everything. The MS fork will be used as a staging area for LLVM changes as we work to get them upstreamed. Tactically we're merging the MS fork everyday with mainline to try and stay close. We're still ramping up right now, and trying to figure out how best to work day to day, but our over arching goal is to enable (mainline) LLVM to be