search for: x86compilationcallback

I have a question on the LLVM JIT I did some brief memory reading one day and I found that a call to a non-library function is resolved by the X86CompilationCallback, but the X86CompilationCallback is reached through a trampoline. why can not the generated code jump to the X86CompilationCallback function directly ? 0x2b0a6a4d103b: mov $0x2b0a6a561010,%rax 0x2b0a6a4d1045: callq *%rax // call foo > > > ==> > > 0x2b0a6a...

...e and then jumped to through a register. Reid On Tue, Feb 22, 2011 at 12:03 PM, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > I have a question on the LLVM JIT > > I did some brief memory reading one day and I found that a call to a > non-library function is resolved by the X86CompilationCallback, but the > X86CompilationCallback is reached through a trampoline. why can not  the > generated code jump to the X86CompilationCallback function directly ? > >           0x2b0a6a4d103b: mov    $0x2b0a6a561010,%rax >           0x2b0a6a4d1045: callq  *%rax > // call foo >> &gt...

I understand that we need to push the address to a register then branch using the register. But i am asking why there is a trampoline there such that a call to foo is first branched to an snippet and the snippet branches to the X86CompilationCallback. is this snippet necessary ? Thanks Xin On Tue, Feb 22, 2011 at 12:39 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > The address of the callee may be more than 2 GB away in memory, which > cannot be encoded as an immediate offset in the call instruction. So, > the value...

...LVMX86.o: In function `GLOBAL__D__ZN90_GLOBAL__N_c__projects_src_llvm_1_llvm_lib_Target_X86_X86ISelPattern.cpp_3F6EE7DC_DDDFAB8D17X86TargetLowering14LowerArgumentsERN4llvm8FunctionERNS1_12SelectionDAGE': c:/projects/src/llvm-1/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86CompilationCallback2' c:/projects/src/llvm-1/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86CompilationCallback' c:/projects/src/llvm-1/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86CompilationCallback' collect2: ld returned 1 exit status -------------------...

...e. I assume this has to be broken on Linux/x86 at the moment too? I've done up a quick and dirty implementation below for the sake of discussion, which compiles (and doesn't break lli), but hasn't been tested beyond that point as yet. Admittedly this adds even more versions of X86CompilationCallback, but the mixed version with #ifs seemed to be pretty hard to follow. Cheers, Nathan Index: X86/X86JITInfo.cpp =================================================================== --- X86/X86JITInfo.cpp (revision 79974) +++ X86/X86JITInfo.cpp (working copy) @@ -180,15 +181,148 @@ # endif #e...

Hello, Nathan > or if it should be a configure test, which might be safer. Are there > any x86 platforms (other than apple) that don't need PLT-indirect calls? Yes, mingw. However just tweaking the define is not enough - we're not loading address of GOT into ebx before the call (on 32 bit ABIs) thus the call will be to nowhere. -- With best regards, Anton Korobeynikov Faculty of

Hi! We are running llvm jit x86 on MS Visual Studio 2005. It seems there is a bug in asm code in function X86CompilationCallback in file X86JITInfo.cpp. Current code sets stack pointer to invalid value in instruction "and esp, 16". Depending on current stack pointer value it sometimes overwrites ecx and edx registers with next three lines. We have fixed this problem by changing this instruction to "sub esp...

Hi all, I've encountered a couple of minor build issues on Solaris that have crept in since 2.5, fixes below: 1. In lib/Target/X86/X86JITInfo.cpp, there is: // Check if building with -fPIC #if defined(__PIC__) && __PIC__ && defined(__linux__) #define ASMCALLSUFFIX "@PLT" #else #define ASMCALLSUFFIX #endif Which causes a link failure due to the non-PLT

Hello > We are running llvm jit x86 on MS Visual Studio 2005. It seems there > is a bug in asm code in function X86CompilationCallback in file > X86JITInfo.cpp. Current code sets stack pointer to invalid value in > instruction "and   esp,  16". Depending on current stack pointer value > it sometimes overwrites ecx and edx registers with next three lines. How so? The stack grows downwards, thus this realignment j...

Hello again. I still think that you are wrong. Realignement with and esp,-16 not always changes stack poiner. If esp is already aligned to 16 byte boundary, it will not change! Take a look at following example. Assume esp has value 0x000001000 at start of X86CompilationCallback function. Then execution of it will yield following esp values: 0x000000FFC - after push ebp 0x000000FFC - after mov ebp, esp 0x000000FF8 - after push eax 0x000000FF4 - after push edx // edx is pushed to address 0x000000FF4 0x000000FF0 - after push ecx // ecx is pushed to address 0x000000FF0 0x000...

Compiling llvm on a linux/amd64 box produces: home/rafael/dev/llvm/build/Debug/lib/LLVMX86.o: In function `_X86CompilationCallback': (.text+0x316fe): undefined reference to `_X86CompilationCallback2' /home/rafael/dev/llvm/build/Debug/lib/LLVMX86.o: In function `llvm::X86JITInfo::getLazyResolverFunction(void* (*)(void*))': /home/rafael/dev/llvm/cvs/lib/Target/X86/X86JITInfo.cpp:219: undefined reference to `X86Compil...

...abort + 257 4 libc.so.6 0x0013e39e __assert_fail + 238 5 lli 0x08738aa4 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 408 6 lli 0x08738f6d llvm::JIT::getPointerToFunction(llvm::Function*) + 755 7 lli 0x0873f704 8 lli 0x08597416 X86CompilationCallback2 + 166 9 lli 0x08596e08 X86CompilationCallback + 24 10 lli 0x00eebff5 X86CompilationCallback + 4170535429 11 lli 0x0863e13e llvm::CallSDNode::CallSDNode(unsigned int, llvm::DebugLoc, bool, bool, bool, llvm::SDVTList, llvm::SDValue const*, unsigned int, unsigned int) + 90 12 l...

...s MSVC 10 To: cfe-dev at cs.uiuc.edu Hi, I'm trying to build svn LLVM with Visual Studio 2010: cd build cmake .. -G"NMake Makefiles" nmake and several link steps fail due to a missing symbol: > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved external symbol X86CompilationCallback referenced in function "public: virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAXPEAX at Z@Z) What can/should I do? Thanks! Ruben

...isual Studio 2010: >> >> cd build >> cmake .. -G"NMake Makefiles" >> nmake >> >> and several link steps fail due to a missing symbol: >> >> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved >> > external symbol X86CompilationCallback referenced in function "public: >> > virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void >> > * (__cdecl*)(void *)))(void)" >> > (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAXPEAX at Z@Z) >> >> What can/shoul...

...e > this has to be broken on Linux/x86 at the moment too? I've done up a quick > and dirty implementation below for the sake of discussion, which compiles > (and doesn't break lli), but hasn't been tested beyond that point as yet. > Admittedly this adds even more versions of X86CompilationCallback, but the > mixed version with #ifs seemed to be pretty hard to follow. There was some PR wrt this issue (sorry, I remembered about it only now). It was decided that proper way of doing things is just declare the compilation callback as static - then you won't need to assemble call via PLT at...

...>> cd build >>> cmake .. -G"NMake Makefiles" >>> nmake >>> >>> and several link steps fail due to a missing symbol: >>> >>> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved >>> > external symbol X86CompilationCallback referenced in function "public: >>> > virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void >>> > * (__cdecl*)(void *)))(void)" >>> > (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAXPEAX at Z@Z) >>> >&gt...

...; I'm trying to build svn LLVM with Visual Studio 2010: > > cd build > cmake .. -G"NMake Makefiles" > nmake > > and several link steps fail due to a missing symbol: > > > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved > external symbol X86CompilationCallback referenced in function "public: > virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void > * (__cdecl*)(void *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm@ > @UEAAP6AXXZP6APEAXPEAX at Z@Z) > > What can/should I do? > > Thanks! > &gt...

...1>------ Build started: Project: Fibonacci, Configuration: Release x64 ------ 1> Creating library C:/llvm-2.7-src/build/lib/Release/Fibonacci.lib and object C:/llvm-2.7-src/build/lib/Release/Fibonacci.exp 1>LLVMX86CodeGen.lib(X86JITInfo.obj) : error LNK2019: unresolved external symbol X86CompilationCallback referenced in function "public: virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void * (__cdecl*)(void *)))(void)" (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAXPEAX at Z@Z) 1>C:\llvm-2.7-src\build\bin\Release\Fibonacci.exe : fatal error LNK1120...

...ß why did this > become a movaps? > > 15D10021 movups xmmword ptr [esp+28h],xmm0 > > 15D10026 mov esi,dword ptr [esp+58h] > > 15D1002A mov edi,dword ptr [esp+5Ch] > > 15D1002E mov dword ptr [esp],40000000h > > 15D10035 call X86CompilationCallback (1335030h) > > > > Thanks for the help! > > > > Chuck. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ------------...

...ld; > *OldByte++ = 0xE9; // Emit JMP opcode. > @@ -64,9 +69,6 @@ > "popl %ebp\n" > "ret\n"); > #else > - extern "C" void *_AddressOfReturnAddress(void); > - #pragma intrinsic(_AddressOfReturnAddress) > - > void X86CompilationCallback2(void); > > _declspec(naked) void X86CompilationCallback(void) { > -------------------------------------------------------------------------------- > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.c...