similar to: [ORC JIT][MLIR] GDBRegistrationListener "second attempt to perform debug registration" assert

Hi Adam, Calls to the listeners should be protected by the RTDyldLayerMutex. Could you apply the attached patch and share the debugging output from one of the failing runs? Regards, Lang. On Wed, May 20, 2020 at 8:00 PM David Blaikie <dblaikie at gmail.com> wrote: > +Lang > > On Wed, May 20, 2020 at 4:44 PM Straw, Adam D via llvm-dev < > llvm-dev at lists.llvm.org>

Referring to the log messages from my previous mail… I confused myself (and probably others) by reading the “Adding MemMgr 0x55555959f440“ message as “Registering MemMgr 0x55555959f440”. Thus the address mismatch made no sense. How could we be registering a `MemMgr` address/key that does not match once we arrive in `notifyObjectLoaded` method? Answer: Because the registrations is NOT coming

HI Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it personally.

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

Hi Lang, LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. That breaks if the object file has multiple sections with the same name. I made a change to add an overload that takes a SectionRef&. Can you please take a look? https://github.com/erozenfeld/llvm/commit/65f635e426bdc8e80a29ed370a78f0c0a282f265 Thanks, Eugene -------------- next part -------------- An HTML

On Wed, Jul 22, 2015 at 9:41 PM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> wrote: > Hi Lang, > > > > LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. That > breaks if the object file has multiple sections with the same name. I made a > change to add an overload that takes a SectionRef&. Can you please take a > look? > > >

Hi, I have a debug build with shared libraries (to reduce compilation time), but since yesterday, it's failing with an ExecutionEngine error: FAILED: : && /usr/lib/ccache/bin/c++ -fPIC -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11

Hi all, I'm trying to add pre-compiled object cache to my run-time. I've implemented the object cache as follow: class EngineObjectCache : public llvm::ObjectCache { private: std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>> CachedObjs; public: virtual void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef Obj) { auto id =

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

Hi Andres, I also want to highlight the necessity of some form of C API, that others > already have. > <snip> > It's fine if the set of "somewhat stable" C APIs doesn't provide all the > possible features, though. Ok. This got me thinking about what a simple LLJIT API should look like. I have posted a sketch of a possible API on http://llvm.org/PR31103 . I

No real reason, just wanted to get an informal opinion first. Submitted via Phabricator now. http://reviews.llvm.org/D11474 Eugene -----Original Message----- From: Meador Inge [mailto:meadori at gmail.com] Sent: Thursday, July 23, 2015 8:45 AM To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> Cc: Lang Hames <lhames at gmail.com>; llvmdev at cs.uiuc.edu Subject: Re:

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

Hi Bjoern, CCing cfg-dev (since that's where the conversation started) and llvm-dev (since it's relevant there). Do you know if there is a way to obtain the fully resolved obj-code? I > wanted to load the functions into a shared memory, but how? The only thing > I receive is a function pointer, but I don't know how large the function > 'behind' is. Even a call to

Hello everyone, I want to use the LLVM to write a JIT client, that works with shared memory. Currently I proceed as following: I wrote an own class that inherits "RTDyldMemoryManager". The functions "allocateCodeSection" and "allocateDataSection" are allocating local non-shared memory. I store there addresses in a std::vector. When the function

Hi Lang, I'm using Windows. I was parsing an IR-File and added the Module to the ExectuionEngine. If I than searched for a function, I just got 0. But when the module had a main, I got an address. I solved the problem via a call to "generateCodeForModule". The JIT didn't even called my SymbolResolver in this special case. Could you please tell me, if there is a way to

Hi Bekket, Thank you for your reply. Earlier I came across a paper called "Dynamic Look Ahead Compilation: Hide JIT compilation latencies", it devised some methods for JIT compilation of functions before the actual call takes place by using call graph analysis, branch probabilities to generate a list of functions with high likelihood of execution in near future. In my opinion it

Hello Lang, so you are part of the "Jitter-Team"? I'm really interested in this whole jitting-process. I wanted to know, is there a way to load other obj-files, than the one created with clang? Could I load - for example - a obj-File from VisualStudio? Or will the namemangeling fail? Kind regards Björn From: Lang Hames <lhames at gmail.com> To: bjoern.gaier at