search for: runtimedyldmacho

...been corrupted. Here is the top of the backtrace from lldb: ---------------------- * thread #1: tid = 0x557509, 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, stop reason = EXC_BAD_ACCESS (code=2, address=0x1102adad1) 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 #...

...been corrupted. Here is the top of the backtrace from lldb: ---------------------- * thread #1: tid = 0x557509, 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, stop reason = EXC_BAD_ACCESS (code=2, address=0x1102adad1) 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 #...

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* RTDyldMemoryManager::registerEHFrames() and __register_frame() are called. It would seem that even if RTDyldMemoryManager::registerEHFra...

Thank you for the help. The relocation type value is anded with 0xffffffffL. (RuntimeDyldMachO.cpp:214) Maybe this mask should be different? Anyway, it seems like this relocation isn't implemented. (RuntimeDyldMachO.cpp:104) From: Jiong Wang <jiwang at tilera.com<mailto:jiwang at tilera.com>> Date: Tue, 9 Apr 2013 09:42:03 -0400 To: Eran Weiss <eran.weiss at emc.com<ma...

The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. The fact that this relocation type isn’t handled is, of course, the root of your problem. MCJIT has grown on an as-needed basis up to now,...

...aylor, Andrew" <andrew.kaylor at intel.com> wrote: > The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. > > The fact that this relocation type isn’t handled is, of course, the root of your problem. > > MCJIT has grown on an as-n...

...at intel.com<mailto:andrew.kaylor at intel.com>> wrote: The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. The fact that this relocation type isn’t handled is, of course, the root of your problem. MCJIT has grown on an as-needed basis up to now,...

...at intel.com<mailto:andrew.kaylor at intel.com>> wrote: The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. The fact that this relocation type isn’t handled is, of course, the root of your problem. MCJIT has grown on an as-needed basis up to now,...

...at intel.com<mailto:andrew.kaylor at intel.com>> wrote: The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. The fact that this relocation type isn’t handled is, of course, the root of your problem. MCJIT has grown on an as-needed basis up to now,...

...runs the generated code. When I try to use MCJIT I encounter a problem with relocations of external symbols – functions compiled statically beforehand with gcc. I get the following error: Invalid relocation type! UNREACHABLE executed at /Users/weisse4/dev/llvm/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:89 While debugging, I see that the relocation type read in RuntimeDyldImpl::loadObject is 218103811, which seems corrupt to me. Did someone encounter a similar error? Or can direct me to changes that I need to do while migrating from JIT to MCJIT? Thanks. -------------- next part ------------...

...to use MCJIT I encounter a problem with relocations of > external symbols -- functions compiled statically beforehand with gcc. > > I get the following error: > > Invalid relocation type! > UNREACHABLE executed at > /Users/weisse4/dev/llvm/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:89 > > While debugging, I see that the relocation type read in > RuntimeDyldImpl::loadObject is 218103811, which seems corrupt to me. Hi Weiss, I do not have any experience on Mach binary format, but the hex value of 218103811 is 0xd000003 (maybe the relocation type is RIT_G...

...at intel.com<mailto:andrew.kaylor at intel.com>> wrote: The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. The fact that this relocation type isn’t handled is, of course, the root of your problem. MCJIT has grown on an as-needed basis up to now,...

...best way of doing this is to add a new subclass of CGObjCRuntime that generates the code using the public APIs. > > Let me get this right. What clang::CodeGen:: CGObjCRuntime has to do > with this? My understanding of Lang's hint was that one has to extend > llvm's classes like RuntimeDyldMachO to parse Mach-O, find classes, > selectors, categories etc and register them all manually. Are you > saying that something has to be be added to CodeGen/*? You have two options: 1) Hack up something in RuntimeDyldMachO to handle the data structures currently generated by clang. This is fra...

Hi David, Stanislav, Sorry for the delayed reply. Short version: There hasn't been any progress on this just yet, as I have been busy with an overhaul of the underlying ORC APIs. 1) Hack up something in RuntimeDyldMachO to handle the data structures > currently generated by clang. This is fragile, because the interface > between the compiler and the runtime is not documented, and is unique to > each runtime. This code will be different on i386 and ARM, for example. > 2) Create a new CGObjCRuntime s...

...NVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () (gdb) where #0 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () #1 0x0000000100003ea0 in llvm::RuntimeDyldImpl::extractFunction () #2 0x00000001000059a5 in llvm::RuntimeDyldMachO::loadSegment64 () #3 0x000000010000493d in llvm::RuntimeDyldMachO::loadObject () #4 0x0000000100003cf9 in llvm::RuntimeDyld::loadObject () #5 0x00000001000032e5 in llvm::MCJIT::MCJIT () #6 0x00000001000021c2 in llvm::MCJIT::createJIT () #7 0x0000000100023274 in llvm::EngineBuilder::create () #...

...hris. 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 RTDyldMemoryManager.cpp) >  before RTDyldMemoryManager::registerEHFrames() and __register_frame() > are called. > > It would seem that even if  RTDyldM...

...M, Lang Hames <lhames at gmail.com> wrote: > Hi David, Stanislav, > > Sorry for the delayed reply. > > Short version: There hasn't been any progress on this just yet, as I have > been busy with an overhaul of the underlying ORC APIs. > >> 1) Hack up something in RuntimeDyldMachO to handle the data structures >> currently generated by clang. This is fragile, because the interface >> between the compiler and the runtime is not documented, and is unique to >> each runtime. This code will be different on i386 and ARM, for example. >> >> >>...

...earlier thread, the best way of doing this is to add a new subclass of CGObjCRuntime that generates the code using the public APIs. Let me get this right. What clang::CodeGen:: CGObjCRuntime has to do with this? My understanding of Lang's hint was that one has to extend llvm's classes like RuntimeDyldMachO to parse Mach-O, find classes, selectors, categories etc and register them all manually. Are you saying that something has to be be added to CodeGen/*? > If you’re running in the same process as the JIT, you could register the selectors in the host environment and just inject the values as symb...

...: 0x0000000000000000 > 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () > (gdb) where > #0 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () > #1 0x0000000100003ea0 in llvm::RuntimeDyldImpl::extractFunction () > #2 0x00000001000059a5 in llvm::RuntimeDyldMachO::loadSegment64 () > #3 0x000000010000493d in llvm::RuntimeDyldMachO::loadObject () > #4 0x0000000100003cf9 in llvm::RuntimeDyld::loadObject () > #5 0x00000001000032e5 in llvm::MCJIT::MCJIT () > #6 0x00000001000021c2 in llvm::MCJIT::createJIT () > #7 0x0000000100023274 in llvm::E...

...; wrote: > > Hi David, Stanislav, > > > > Sorry for the delayed reply. > > > > Short version: There hasn't been any progress on this just yet, as I have > > been busy with an overhaul of the underlying ORC APIs. > > > >> 1) Hack up something in RuntimeDyldMachO to handle the data structures > >> currently generated by clang. This is fragile, because the interface > >> between the compiler and the runtime is not documented, and is unique to > >> each runtime. This code will be different on i386 and ARM, for example. > >&g...