similar to: [LLVMdev] ExecutionEngine should have a non-Module creator

I agree that this would be useful. One minor stumbling block is that the EngineBuilder uses the supplied Module to determine the target triple when creating the TargetMachine. Obviously that could be handled with different EngineBuilder usage (the API may even already be there for that). It's just something to consider. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent:

I am currently setting up my Module with module->setTargetTriple(llvm::sys::getProcessTriple() #ifdef _WIN32 + "-elf" #endif ); And my ExecutionEngine with llvm::EngineBuilder(std::move(module)) .setErrorStr(&err) .setMCPU(llvm::sys::getHostCPUName())

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT

OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit. The target which is i686-pc-mingw32-elf so I can use the ELF dynamic loader. Code model, relocation model and and memory manager are whatever default for this - did not modify. The Module comes from clang. The source is 1000 or more lines repeating C++ code in one big function: A+1; A*B.t(); where A and B are

Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have

YES, this is the problem! The program work ok, even a 5x larger version works well. Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not? I'd like to make a patch and fix this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not

Hi Andy, I added the runStaticConstructorsDestructors and FindFunctionNamed functions. This also required making them virtual in EE.h. I'm not sure about FindFunctionNamed: In addition to searching finalized modules, should it search Added and Loaded modules? If it finds a Function in these, should it compile and finalize it before returning the Function* ? I modified the implementation

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows

Yes, this is correct code address accessing bad data address. However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something. The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now. I need to debug and see

That makes it more mysterious then since I am indeed only calling a main function. Perhaps I have to invoke it a different way. Here's my call I have now: auto main = linker->getModule()->getFunction( "main" ); std::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =

Dear LLVM-Mailing-List, I'm using the llvm::EngineBuilder to create an instance of the llvm::ExecutionEngine, I then JIT my code, take the addresses I need and delete the llvm::ExecutionEngine. But now I started to wonder, if I could reuse that instance for a new module again? I first tried calling llvm::EngineBuilder without setting a Module, I planned to add it later - but when I do this

I'm running in MCJIT a module generated from one C++ function. Every line of the source function uses C++ classes and may throw an exception. As long as there are less than (about) 1000 lines, everything works. With more lines the compiled code crashes when running it, with no sensible stack trace. Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic Linker / ELF codegen /

I would guess that it's crashing somewhere in the generated code. On Windows we don't have a way to get call stacks to the generated code (though if you want to try it on Linux, that should work). You can probably look at the address where the crash is occurring and verify that it is in the generated code. There are a couple of things I would look for. First, I'd take a look at the

Hi Yaron, Overall this looks great. There are a couple of remaining holes. Specifically, MCJIT inherits implementations of the FindFunctionNamed and runStaticConstructorsDestructors methods from ExecutionEngine which use the old Modules vector, so you'll need to override these in MCJIT. (The implementations are fairly trivial.) Beyond that I just have a couple of questions. First,

This is the right fix if Cygwin wants calls to __chkstk. Otherwise you'll want TargetTriple.isOSMSVCRT(). On Wed, Oct 23, 2013 at 2:50 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > If it's a Windows-only thing the correct tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > > if (Subtarget->isTargetWindows()) >

Glad that helped! As I understand it __chkstk is always required on Windows regardless of output type, I had meant to file a bug about this but had apparently forgotten to do so. I think the check needs to be that the target is Windows and ignore the output type, Linux and OSX don't use this. Cheers, Andrew On Wed, Oct 23, 2013 at 11:32 AM, Yaron Keren <yaron.keren at gmail.com>

So it looks like 0x0A3600D1 is a good code address and there's no problem executing the code there, but 0x00BC7680 is a bad data address. Is that correct? If so, this is almost certainly a relocation problem. You just need to find a relocation that writes an entry (probably a relative offset) at 0x0A3600D1+the size of the instruction at that address. BTW, what I said before about not being

I'm not aware of such a limitation. What architecture, code model and relocation model are you using? Are you using the SectionMemoryManager? -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Tuesday, October 22, 2013 8:12 AM To: <llvmdev at cs.uiuc.edu>; Kaylor, Andrew Subject: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? I'm running in MCJIT a

Hi Yaron, If you're outputting ELF on Windows this sounds like an issue we ran into where __chkstk calls weren't being output in the assembly due to an explicit check for COFF output. Once stack allocations in a given function exceeded some amount we'd get exactly this kind of crash in the function initialization. If you take a look for isTargetCOFF() in

Heyho, I can only provide you with a screenshot for the first problem I noticed: [https://media.discordapp.net/attachments/534012750045642783/575369402195640321/unknown.png] This code will crash when calling "eeBuilder.create". But I also looked at what happens if I do reuse the llvm::ExecutionEngine. After the call to "finalizeObject" I use "removeModule" for the