search for: x86jitinfo

Thanks, now it links. If nobody objects, I will commit the following patch: diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp index 44d8cce..8acc220 100644 --- a/lib/Target/X86/X86JITInfo.cpp +++ b/lib/Target/X86/X86JITInfo.cpp @@ -339,6 +339,8 @@ extern "C" { /// must locate the start of the stub or call site and pass it into the JIT /// compiler function. extern "C&q...

...t: Thursday, January 26, 2006 3:31 PM Subject: [LLVMdev] VS2005 patch > OK, fixed the problem with the intrin.h header that doesn't exist in > previous versions of VS... > -------------------------------------------------------------------------------- > Index: lib/Target/X86/X86JITInfo.cpp > =================================================================== > RCS file: /var/cvs/llvm/llvm/lib/Target/X86/X86JITInfo.cpp,v > retrieving revision 1.14 > diff -u -r1.14 X86JITInfo.cpp > --- lib/Target/X86/X86JITInfo.cpp 22 Jul 2005 20:49:37 -0000 1.14 > +++ lib/Target/...

OK, fixed the problem with the intrin.h header that doesn't exist in previous versions of VS... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JIT.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060126/7e55b0d0/attachment.ksh>

....ruben at gmail.com> Date: 2010/12/31 Subject: LLVM on Windows 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...

...gt;> >> 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)" >> > (?getLazyResolverF...

Hi Patrik, On 12/06/13 09:48, Patrik Hägglund H wrote: > Thanks, now it links. > > If nobody objects, I will commit the following patch: > > diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp > index 44d8cce..8acc220 100644 > --- a/lib/Target/X86/X86JITInfo.cpp > +++ b/lib/Target/X86/X86JITInfo.cpp > @@ -339,6 +339,8 @@ extern "C" { > /// must locate the start of the stub or call site and pass it into the JIT > /// comp...

...t;> 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)" >>> > (?...

...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@ > @UEAAP6A...

...at the last hurdle though when it comes to the final link: 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&...

...6, %esp\n" That would be the correct thing to do on the MSVC version too I think. "and esp, -16" aligns the stack, and "sub esp, -16" makes room for 8 bytes + padding to keep the 16 byte alignment of the stack. This patch should fix the issue: diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp index f363903..d297d24 100644 --- a/lib/Target/X86/X86JITInfo.cpp +++ b/lib/Target/X86/X86JITInfo.cpp @@ -297,6 +297,7 @@ extern "C" { push edx push ecx and esp, -16 + sub esp, 16 mov eax, dword ptr [ebp+4]...

...is in trunk also. Kristaps. On Tue, Feb 2, 2010 at 7:12 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > 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 just equival...

...Mdev] VS2005 patch > > >> OK, fixed the problem with the intrin.h header that doesn't exist in >> previous versions of VS... >> > > > -------------------------------------------------------------------------------- > > > >> Index: lib/Target/X86/X86JITInfo.cpp >> =================================================================== >> RCS file: /var/cvs/llvm/llvm/lib/Target/X86/X86JITInfo.cpp,v >> retrieving revision 1.14 >> diff -u -r1.14 X86JITInfo.cpp >> --- lib/Target/X86/X86JITInfo.cpp 22 Jul 2005 20:49:37 -0000 1.14...

BTW: I've also had to make this change when building tools. (I'm building right now and noticed that it doesn't come up anymore, maybe someone checked it in in the last week or so) On Sat, 29 Apr 2006, Anton Korobeynikov wrote: > Hello, Jeff. > > You wrote Saturday, April 29, 2006, 10:45:02 PM: > > JC> Yes, I know mingw doesn't support dbghelp. I can still rant

Hello, Jeff. You wrote Saturday, April 29, 2006, 10:45:02 PM: JC> Yes, I know mingw doesn't support dbghelp. I can still rant about it :) ;) Well. Maybe this library will be included in some next versions of mingw's win32api package. Anyway, we can make such library just "on-fly" from the corresponding .dll. JC> This is what's already there. What changed? Maybe

If you look in X86JITInfo.cpp, you'll find CompilationCallback. I'm not sure about CompilationCallback2. In any event, the code is conditionally compiled and that might be tripping things up on Cygwin. Reid. On Mon, 2005-05-30 at 17:17 +0100, Aaron Gray wrote: > Consistant error building LLVM on Cygwin from CV...

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

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 `X86CompilationCallback' /home/rafael/dev/llvm/build/Debug/lib/LLVMX86.o: In function `llvm::X86JITInfo::emitFunctionStub(void*, llvm::MachineCodeEmitter&)...

...nt $0x0 > > But that clobbers r10 which loop1 needs. According to the x86-64 ABI, r10 > isn't preserved across functions, but here it needs to be. Is there anyway > to force LLVM to do that? you must be the first person to try using nest functions with the JIT :) If you look in X86JITInfo.cpp, in the function X86JITInfo::emitFunctionStub, you will see the code generating the stub and using r10. I think the right solution is to change r10 to a different call clobbered register. It would also be possible to have the trampoline use a different register, but since the x86-64 ABI expli...

Consistant error building LLVM on Cygwin from CVS :- make[2]: Entering directory `/usr/build/llvm/tools/llc' llvm[2]: Compiling llc.cpp for Debug build llvm[2]: Linking Debug executable llc /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30506): In function `_GLOBAL__D__ZN7 6_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_DD38501517X

...agma's of form: #pragma comment(lib, "dbghelp.lib") 2.2 CopyFile Patch lib/System/Win32/Path.inc in such way, that declaration of CopyFile will look like: void CopyFile(const sys::Path &Dest, const sys::Path &Src) { 2.3 X86 stuff Patch lib/Target/X86/X86SubTarget.cpp & X86JITInfo.cpp in such way: X86SubTarget.cpp: #if defined(__CYGWIN__) || defined(__MINGW32__) TargetType = isCygwin; #elif defined(__APPLE__) TargetType = isDarwin; #elif defined(_WIN32) TargetType = isWindows; #endif X86JITInfo.cpp: #if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MIN...