similar to: [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

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

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

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, 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

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

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

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

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>

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

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()) >

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

I don’t follow. Why are we looking at the module at all? That query should work even (especially) after the Module is deleted. We should be able to have a local symbol table that’s a DenseMap or something similar to resolve from names to target addresses. That map would be updated as part of the compilation when the object’s symbol table gets read. -Jim On Oct 21, 2013, at 4:55 PM, Kaylor,

Hi Jim, Clearly searching for name should not be linear in modules but with a map of some kind. After compilation to IR each module has a StringMap symbol table. After compiling to MC and loading the object file, the dynamic linker has a StringMap symbol table for all loaded modules. In the usual use case you'll load module(s) into MCJIT and then compile / link them and all is well, no

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

The pass manager is re-created in emitObject on every call. Andy, is that needed or can we create the PM in MCJIT constructor and keep it around? Yaron 2013/11/19 Kevin Modzelewski <kmod at dropbox.com> > So I finally took the plunge and switched to MCJIT (wasn't too bad, as > long as you remember to call InitializeNativeTargetDisassembler if you want > disassembly...),

So I finally took the plunge and switched to MCJIT (wasn't too bad, as long as you remember to call InitializeNativeTargetDisassembler if you want disassembly...), and I got the functionality to a point I was happy with so I wanted to test perf of the system. I created a simple benchmark and I'd thought I'd share the results, both because I know I personally had no idea what the

The search is linear? If that’s really true, we should fix that. On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I should have read this before sending my previous reply. :-) > > I’m not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply. > >

In MCJIT, the old JIT functions are deprecated in favor of getFunctionAddress. Code like: llvm::Function *F = M->getFunction(FuncName); void *FN = EE->getPointerToFunction(F); should be rewritten as uint64_t FN = EE->getFunctionAddress(FuncName); While functionally identical, in case the correct module is known the new version will be much slower, linear with the number of added

Correct or no I don't know, but this change will affect all x86-64 targets including Linux and Windows as getMaxStubSize() is called from the ELF linker as well as the Mach-O linker. 2013/10/15 Christian Schafmeister <chris.schaf at verizon.net> > > With the help of iain at codesourcery.com and andrew.kaylor at intel.com we > tracked the problem down to a bad relocation that

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