search for: deregisterehframes

...nkingLayer.h (working copy) @@ -175,7 +175,7 @@ } ~ConcreteLinkedObject() override { - if (this->Parent.NotifyFreed) + if (this->Parent.NotifyFreed && ObjForNotify.getBinary()) this->Parent.NotifyFreed(K, *ObjForNotify.getBinary()); MemMgr->deregisterEHFrames();

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 process causes an exception after J...

...familiar with Windows at all, but I assume you can't mix 64-bit > and 32-bit code in the one process. > > Reid - Are we generating correct call frame information for windows yet ( > https://llvm.org/PR24233) ? If so, I think Dibyendu would just have to > override registerEHFrames/deregisterEHFrames and have them call > RtlInstallFunctionTableCallback/RtlAddFunctionTable, right? > > - Lang. > > On Sun, Oct 25, 2015 at 5:30 AM, Dibyendu Majumdar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi >> >> On 64-bit Windows the lack of proper sta...

Hi On 64-bit Windows the lack of proper stack unwinding support causes crashes in JIT code generated by LLVM. I was wondering if it is possible to ask LLVM to generate 32-bit code - and if that would work within a 64-bit Windows application - i.e. the rest of the system will be 64-bit only the generated code will be 32-bit. I was also wondering if this would allow me to workaround the crashes due

...symbols that might have been found via findSymbol. It is unlikely that anyone is relying on non-shadowing so I don't expect any trouble here, but if you do see any changes in symbol resolution after this change (which I expect to land today) this is something to have in mind. 2) MemoryManager deregisterEHFrames will be removed. Memory managers should own their registered EH frames and deregister them on destruction. This will bring EH frame ownership in line with memory ownership: memory managers are already responsible for freeing the memory that they've allocated when they are destructed. To trans...

...been found via findSymbol. It is unlikely that anyone is relying > on non-shadowing so I don't expect any trouble here, but if you do see > any changes in symbol resolution after this change (which I expect to > land today) this is something to have in mind. > > 2) MemoryManager deregisterEHFrames will be removed. > > Memory managers should own their registered EH frames and deregister > them on destruction. This will bring EH frame ownership in line with > memory ownership: memory managers are already responsible for freeing > the memory that they've allocated when they a...

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74