I'm trying to add an object file created with object::ObjectFile::createObjectFile to MCJIT using addObjectFile the same way lli is doing it. I found that if file size is > 4*PageSize MCJIT crashes with seg. fault trying to load it. The problem is that if object file exceeds 4*PageSize MemoryBufferMMapFile is used to allocate memory and it marks allocated memory as read-only. MCJIT creates ObjectImage from ObjectFile, but it simply sets internal pointers to the memory allocated for ObjectFile. The crash happens during the ObjectImage loading when loader tries to update emitted ELF section address, which resides in read-only memory. In order to reproduce the issue almost any ELF object is enough. For instance lli.o can be used: bin/lli -use-mcjit -extra-object=./tools/lli/CMakeFiles/lli.dir/lli.cpp.o < ../llvm/test/ExecutionEngine/Interpreter/intrinsics.ll 0 lli 0x0000000000a088e2 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 lli 0x0000000000a08494 2 libpthread.so.0 0x00007fd0b2f03340 3 lli 0x0000000000b61365 4 lli 0x0000000000b524e3 llvm::RuntimeDyldImpl::emitSection(llvm::ObjectImage&, llvm::object::SectionRef const&, bool) + 627 5 lli 0x0000000000b52bc0 llvm::RuntimeDyldImpl::findOrEmitSection(llvm::ObjectImage&, llvm::object::SectionRef const&, bool, std::map<llvm::object::SectionRef, unsigned int, std::less<llvm::object::SectionRef>, std::allocator<std::pair<llvm::object::SectionRef const, unsigned int> > >&) + 176 6 lli 0x0000000000b53674 llvm::RuntimeDyldImpl::loadObject(llvm::ObjectImage*) + 2452 7 lli 0x0000000000b53af3 llvm::RuntimeDyld::loadObject(std::unique_ptr<llvm::object::ObjectFile, std::default_delete<llvm::object::ObjectFile> >) + 131 8 lli 0x0000000000841bab llvm::MCJIT::addObjectFile(std::unique_ptr<llvm::object::ObjectFile, std::default_delete<llvm::object::ObjectFile> >) + 43 9 lli 0x0000000000516a29 main + 2489 10 libc.so.6 0x00007fd0b232eec5 __libc_start_main + 245 11 lli 0x0000000000527230 Stack dump: 0. Program arguments: bin/lli -use-mcjit -extra-object=./tools/lli/CMakeFiles/lli.dir/lli.cpp.o zsh: segmentation fault (core dumped) bin/lli -use-mcjit -extra-object=./tools/lli/CMakeFiles/lli.dir/lli.cpp.o <
Hi Bader, Sorry - it has taken a while for me to get back to this. I haven't tried this myself yet, but I suspect I know the cause: RuntimeDlydELF always tries to fix up the object image for the debugger (regardless of whether there's actually a debugger attached). When the object is backed by an ordinary memory buffer (true for all objects spat out from the JIT) this just works, but when an object file is loaded from disk it can (as you saw) be backed by a read-only mmapped buffer. We ran in to this exact problem with on the MachO side of RuntimeDyld and decided to remove the debugger registration system for this reason (there are plans to re-introduce a more sane implementation). I think this makes a good case for removing debugger registration from RuntimeDyldELF as soon as reasonably possible. Cheers, Lang.
Hi Lang, Thanks for the hint. Does it mean that I won't be able to debug JIT-ed code? If so I'm afraid this workaround won't work for me. I need debugger support. Currently I just do not use setObjectCache EE API and recompile the object each time. This approach introduce additional overhead that I would like to avoid. I'm going to try using ordinary memory buffer for object files loaded from disk. BTW, setObjectCache works fine with LLVM 3.3 and doesn't work with LLVM 3.4+. Thanks again, Alexey
Hi Bader, Sorry, I should have gone in to slightly more detail: What I mean is that we want to remove the current debugger registration system and replace it with something better. For now I'm working on a work-around: The RuntimeDyldELF debugger registration system will duplicate objects before registering them with the debugger. This means higher memory consumption for the JIT, but at least everything will keep working. It will also provide a good motivation for us to get to work on the new registration system. I'll update this bug when my fix goes in. - Lang.
(In reply to comment #2) > Hi Lang, > > Thanks for the hint. > Does it mean that I won't be able to debug JIT-ed code? > If so I'm afraid this workaround won't work for me. I need debugger support. > > Currently I just do not use setObjectCache EE API and recompile the object > each time. This approach introduce additional overhead that I would like to > avoid. > I'm going to try using ordinary memory buffer for object files loaded from > disk. > > BTW, setObjectCache works fine with LLVM 3.3 and doesn't work with LLVM > 3.4+. > > Thanks again, > Alexey Hi. I made a really ugly workaround. I just switched off using mmap in lib/Support/MemoryBuffer.cpp. It seems to work fine. Regards.
Hi Alexey, Radek, This should be fixed as of r222841. It works for me on the suggested test case. Can you confirm that it has fixed your issues? Radek - You should be able to remove your workaround in lib/Support/MemoryBuffer.cpp now. Cheers, Lang.
Yep - r222841 seems to have fixed this.