search for: registerehframes

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 RTDyldMemoryManager.cpp) *before* R...

...to this list, so please add my in CC if you response. Kind regards Björn From: Bjoern Gaier/HE/HORIBA To: Clang Dev <cfe-dev at lists.llvm.org>, "cfe-dev" <cfe-dev-bounces at lists.llvm.org> Date: 19.09.2017 08:05 Subject: Clang/LLVM JIT - When to use "registerEHFrames()" Hello friendly Clang-World, I was experimenting with Clang and the JIT capabilities of LLVM. Most of my attempts were successfully but, I still fail miserably at exceptions. Doing research I found the function "registerEHFrames()" which should assist me supporting exceptions...

Hi Björn To first answer your questionin the subject: For x86 registerEHFrames() is only a stub. For x86_64 registerEHFrames() is implemented properly in RuntimeDyldCOFFX86_64, calling MemMgr.registerEHFrames() for each EH frame section. It should be called and work out of the box without your involvement, but unfortunately it won't solve your issue. All the essential inf...

...I didn't understood much of your mail. I'm a beginner with the JIT - so I will explain what I've done. To manage the memory and resolve symbols, I'm using my own Resolver-Class, which overloads the allocation and the findSymbol functions. I've noticed today, that the "registerEHFrames" function of my class gets called automatically, with correct values. I'm remapping my code and the address are still correct. Great! But, what should I do with it? I pass the values to the original function, but my exception won't be caught! It's an exception raised inside the...

...;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 one in RTDyldMemory...

...tood much of your mail. I'm a beginner with the JIT - > so I will explain what I've done. > > To manage the memory and resolve symbols, I'm using my own > Resolver-Class, which overloads the allocation and the findSymbol > functions. I've noticed today, that the "registerEHFrames" function of > my class gets called automatically, with correct values. I'm remapping > my code and the address are still correct. Great! But, what should I > do with it? I pass the values to the original function, but my > exception won't be caught! It's an exception r...

...tood much of your mail. I'm a beginner with the JIT - so I > will explain what I've done. > > To manage the memory and resolve symbols, I'm using my own Resolver-Class, > which overloads the allocation and the findSymbol functions. I've noticed > today, that the "registerEHFrames" function of my class gets called > automatically, with correct values. I'm remapping my code and the address > are still correct. Great! But, what should I do with it? I pass the values > to the original function, but my exception won't be caught! It's an > exception r...

...frame #0: 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:35 frame #1: 0x0000000107e6df04 libLLVM-3.4svn.dylib`llvm::RuntimeDyldMachO::registerEHFrames() + 356 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:81 frame #2: 0x0000000107e36f39 libLLVM-3.4svn.dylib`llvm::RuntimeDyld::registerEHFrames() + 25 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngin...

...frame #0: 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:35 frame #1: 0x0000000107e6df04 libLLVM-3.4svn.dylib`llvm::RuntimeDyldMachO::registerEHFrames() + 356 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:81 frame #2: 0x0000000107e36f39 libLLVM-3.4svn.dylib`llvm::RuntimeDyld::registerEHFrames() + 25 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngin...

...il. I'm a beginner with the JIT - so I will >> explain what I've done. >> >> To manage the memory and resolve symbols, I'm using my own Resolver-Class, >> which overloads the allocation and the findSymbol functions. I've noticed >> today, that the "registerEHFrames" function of my class gets called >> automatically, with correct values. I'm remapping my code and the address >> are still correct. Great! But, what should I do with it? I pass the values >> to the original function, but my exception won't be caught! It's an >...

...at gmail.com>, > bjoern.gaier at horiba.com > Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>, Stefan > Gränitz <stefan.graenitz at gmail.com> > Date: 16.10.2017 23:04 > Subject: Re: [llvm-dev] Clang/LLVM JIT - When to use > "registerEHFrames()" > ------------------------------ > > > > Historically? I implemented support for exceptions back in LLVM 3.3, > before LLVM had an implementation of a Windows unwinder. > > Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable > of handling...

...#39;ve done. >> >> >> >> To manage the memory and resolve symbols, I'm using my own >> >> Resolver-Class, >> >> which overloads the allocation and the findSymbol functions. I've >> >> noticed >> >> today, that the "registerEHFrames" function of my class gets called >> >> automatically, with correct values. I'm remapping my code and the >> >> address >> >> are still correct. Great! But, what should I do with it? I pass the >> >> values >> >> to the original f...

Hello everyone, I was following the discussion, but I have to admit, that my skills aren't high enough to follow you guys. For my current exception problem, I don't have to stick around with the PECOFF format, so I used clang to don't compile to a PECOFF, but to a ELF file. Interesting, now I'm missing the functions: __cxa_allocate_exception __cxa_throw _ZTI I loaded the DLL

...g finalizeObject more than once would cause a crash. The changes that introduced multiple module support should have fixed that issue. It might be useful to set breakpoints in the memory manager you are using. During finalizeObject you are likely to see calls to finalizeMemory, getSymbolAddress, registerEHFrames and notifyObjectLoaded. I think registerEHFrames is the most likely source of the problem, particularly given that the debugger is also crashing. If that's the problem, you could probably get a little further (for experimental purposes at least) by just having the memory manager do nothing in...

Historically? I implemented support for exceptions back in LLVM 3.3, before LLVM had an implementation of a Windows unwinder. Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable of handling COFF files, and LLVM wouldn't emit the correct sections (with the COFF-formatted unwind tables) when used in ELF mode. The prolog is known to be standard since Julia disables FPO

...ires the jit to notify it of the size of the unwind info descriptors for each function in the module before reserving the memory it will be loaded into. So we need a call (or calls) from the Jit/loader into the MemoryManager that runs at-or-before reserveAllocationSpace, is conceptually similar to registerEHFrames in that it's reserving EH frames, but that additionally needs to separate out the per-function information. A few options come to mind: 1. Add a needsToReserveEHFrames callback on MemoryManager (to parallel needsToReserveAllocationSpace), and a reserveEHFrames callback (parallel to regi...

Hi, I’m looking for advice on how to debug a problem with my exception handling code. I’m asking a specific question here - but general advice on how to debug something like this would be greatly appreciated. Is there any way to get a list of landing pad clauses that are active at a particular point in a program? I'd like to get something like a backtrace but listing all active landing pad

Hi all, In my MSVC-compiled project I am using MCJIT to run some generated code. I faced that in case of Win64 ('x86_64-pc-win32-elf') __try/__except block doesn't work - the stack can not be unwound. I have found that the only way to fix it is implementing my own *registerEHFrames* function of the Memory Manager (but I'm not sure this helps). Maybe someone had a success solving the same problem? What would be the best approach to catch exceptions from dynamically generated code on Win64? Thank you in advance Best regard Alexey -------------- next part -------------- A...

I'm trying to build LLVM on Android rather than the other way around! Really just to see if it can be done. I worked out the first problem (my code was written for the old JIT and I'd missed something in updating to the MCJIT to make it work on ARM). It still doesn't work, but at this point I have no idea why and it'll be a while before I get to look at it again: the Android

We are trying to switch to the new orc v2 lljit engine at my work with hopes of parallel jitting. We are switching from the ExecutionEngine w/ OrcMCJitReplacement. We are having a hard time with global variables. We have found a way to create/emit new globals during jitting by using the old ExecutionEngine::getOrEmitGlobalVariable. Is there an easier way to do this with the new jit engine? We were