search for: rtdyldmemorymanag

Hi, I had similar problems with EH in ELF in RTDyldMemoryManager::registerEHFrames() calling __register_frame(). I'm not sure these problems are related to this problem since your crash happens in RuntimeDyldMachO::registerEHFrames() in its own processFDE (there are two functions named processFDE(), one in RuntimeDyldMachO.cpp and one in RTDyldMemoryMana...

...ystem but I haven't tried to run it on there for a couple of weeks. I'll bring it up to date and try my test case on it and we'll see what happens. Best, .Chris. Yaron Keren <yaron.keren at gmail.com> writes: > Hi, > > I had similar problems with EH in ELF in > RTDyldMemoryManager::registerEHFrames() calling __register_frame(). > > I'm not sure these problems are related to this problem since your > crash happens in  RuntimeDyldMachO::registerEHFrames() in its own > processFDE (there are two functions named processFDE(), one in > RuntimeDyldMachO.cpp and...

Hi folks, I'm still using MCJIT (I know, I know), and I spotted a crash in exception handling when I moved from llvm 3.8 to llvm 3.9. I traced it back to EH frames not being deregistered due to a (typo?) mistake in RTDyldMemoryManager.cpp: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size) override { * registerEHFramesInProcess(Addr, Size);* } ..I overrode the function to call deregister instead of register in my own MemMgr and all's now well. The crash manifests itself as a seg fault when a p...

I've finally managed to extract from Kaleidoscope one particular thing that it seems to me should be working and isn't. Given the global declaration extern "C" void foo() {} within the same program I have RTDyldMemoryManager::getSymbolAddressInProcess("foo") And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160402/4bb593a4/attachment.html>

On 11/11/13 17:42, Kaylor, Andrew wrote: > I've got a number of problems with this patch. > > First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. The direction of LLVM is not something I'm in a position to comment on. The problem of locating these functions is common to the JIT and MCJIT though (and even the interpreter for Linux/x86). > > Second, unless I'm reading it wrong, this relies on static cons...

Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificatio...

...LLVM consumers may be using it for. The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. Is there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? -Andy -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Monday, November 11, 2013 11:13 AM To: Kaylor, Andrew; LLVM Dev Subject: Re: [LLVMdev] Android JIT patch On 11/11/13 17:42, Kaylor, Andrew wrote: >...

...--Original Message----- >> From: James Lyon [mailto:jameslyon0 at gmail.com] >> Sent: Thursday, November 14, 2013 1:25 PM >> To: Kaylor, Andrew; LLVM Dev >> Subject: Re: [LLVMdev] Android JIT patch >> >> Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. >> >> I've also split the original patch up into two parts, to separate the math function fixes from setL...

...> -Andy > > -----Original Message----- > From: James Lyon [mailto:jameslyon0 at gmail.com] > Sent: Thursday, November 14, 2013 1:25 PM > To: Kaylor, Andrew; LLVM Dev > Subject: Re: [LLVMdev] Android JIT patch > > Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. > > I've also split the original patch up into two parts, to separate the math function fixes from setLastModif...

...IC_FUNCTION(__aeabi_d2lz); etc. #endif -Andy -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Thursday, November 14, 2013 1:25 PM To: Kaylor, Andrew; LLVM Dev Subject: Re: [LLVMdev] Android JIT patch Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAn...

I've got a number of problems with this patch. First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. Second, unless I'm reading it wrong, this relies on static constructors. That causes headaches and is against the LLVM coding standards. Third, I don't think sys::DynamicLibrary::AddSymbol() is the right way to go here. I know I have recently suggested using that...

...> -Andy > > -----Original Message----- > From: James Lyon [mailto:jameslyon0 at gmail.com] > Sent: Thursday, November 14, 2013 1:25 PM > To: Kaylor, Andrew; LLVM Dev > Subject: Re: [LLVMdev] Android JIT patch > > Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. > > I've also split the original patch up into two parts, to separate the math function fixes from setLastModif...

...--Original Message----- >> From: James Lyon [mailto:jameslyon0 at gmail.com] >> Sent: Thursday, November 14, 2013 1:25 PM >> To: Kaylor, Andrew; LLVM Dev >> Subject: Re: [LLVMdev] Android JIT patch >> >> Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. >> >> I've also split the original patch up into two parts, to separate the math function fixes from setL...

...com> wrote: > After some fiddling with it, it does in fact look like it works as you > describe Lang. > > The trick was you had to call > > llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); > > to add the currently running process before calling > > llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name);. > > Also, all of the function needs to be declared as extern C to avoid name > mangling. > > I however think that adding the addGlobalMapping/getPointerToGlobalMapping > functions to the ORC kaleidoscope examples is very useful, as for example...

...ymbolInfo(addr, JITSymbolFlags::Exported); >> } >> >> // finally try to look up existing process symbols, note >> // this works for symbols loaded in shared libraries, but >> // does NOT seem to find symbols declared in the executable. >> if (auto Addr = >> RTDyldMemoryManager::getSymbolAddressInProcess(name)) { >> return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported); >> } >> }, >> [](const std::string &S) { return nullptr; } >> ); >> } >> >> Here the getPointerToGlobalMapping function looks in a uint64 Stri...

...ddr = getPointerToGlobalMapping(name)) { return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported); } // finally try to look up existing process symbols, note // this works for symbols loaded in shared libraries, but // does NOT seem to find symbols declared in the executable. if (auto Addr = RTDyldMemoryManager::getSymbolAddressInProcess(name)) { return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported); } }, [](const std::string &S) { return nullptr; } ); } Here the getPointerToGlobalMapping function looks in a uint64 StringMap into which values are added via the addGlobalMapping functions....

...libgcc.a rather than libc.so so are not available unless explicitly linked in, so it's rather similar to the StatSymbols hack. I moved the StatSymbols code into ExecutionEngine.cpp rather than JITMemoryManager.cpp since it's required for both the JIT and MCJIT, and deleted the code in RTDyldMemoryManager.cpp which did the same thing for fewer functions. They should now be picked up through the sys::DynamicLibrary::AddSymbol mechanism in both cases. The symbols required for ARM/Android are then added by an identical hack just below. There's one other minor change since setLastModificationA...

...ddling with it, it does in fact look like it works as you describe Lang. >> >> The trick was you had to call >> >> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr); >> >> to add the currently running process before calling >> >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(name);. >> >> Also, all of the function needs to be declared as extern C to avoid name mangling. >> >> I however think that adding the addGlobalMapping/getPointerToGlobalMapping functions to the ORC kaleidoscope examples is very useful, as for...

....html I think the existing code is correct for OS-X but likely buggy for Linux and Windows systems. Your crash is on OS-X, right? Anyhow, the first problem is very easy to fix. On Linux and Windows (at least) __register_frame should be called once and not called on every FDE as in processFDE in RTDyldMemoryManager,cpp does. So RTDyldMemoryManager::registerEHFrames was modified to: void RTDyldMemoryManager::registerEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size) { __register_frame(Addr); } On Windows 7 / MingW...

...allow you to copy the relocated bytes to remote machines) is three part: (a) Allocate the sections locally (e.g. using malloc, or inheriting from SectionMemoryManager and capturing the allocation details) (b) Override the notifyObjectLoaded method to allocate the final memory locations, then call RTDyldMemoryManager::mapSectionAddress to map each local allocation to its corresponding final address (c) Override finalizeMemory to copy the relocated bytes to their final addresses Hope this helps. Cheers, Lang. On Tue, May 2, 2017 at 10:47 PM, <bjoern.gaier at horiba.com> wrote: > Hello Lang, &...