similar to: [LLVMdev] Linking problems with llvm-2.7, release 64b build with vs2010

"Bill O'Hara" <billtohara at gmail.com> writes: > 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

I first sent this to the Clang dev list, but they told me to come here: ---------- Forwarded message ---------- From: Ruben Van Boxem <vanboxem.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

2010/12/31 Francois Pichet <pichet2000 at gmail.com>: > I don't normally build using nmake.. but I just tried and it worked 100% > here. > Are you sure you are using the trunk? > > On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com> > wrote: >> >> I first sent this to the Clang dev list, but they told me to come here:

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: >>> 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

I don't normally build using nmake.. but I just tried and it worked 100% here. Are you sure you are using the trunk? On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com>wrote: > I first sent this to the Clang dev list, but they told me to come here: > > > ---------- Forwarded message ---------- > From: Ruben Van Boxem <vanboxem.ruben at

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:

Hi Morten, If you can make the VS2005 project files availiable on the net then I can test them as I have VS2005 now, so then with Chris'es okay then they could be distributed with LLVM. Thanks, Aaron ----- Original Message ----- From: "Morten Ofstad" <morten at hue.no> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, January 26,

The patch I recently attached to bug 2606, reproduced here, is my first attempt to solve this issue as represented by the attached test cases. To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found "external" GlobalVariable. To solve the foreign Module Function problem, I modified both JIT.{h,cpp} and

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

On 02/03/2010 01:08 PM, Kristaps Straupe wrote: > 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

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

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

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.

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

On 19/08/2009, at 4:00 AM, Anton Korobeynikov wrote: > 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 Ok, so configure might be the way to go then, maybe something

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" {

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>

Hi, in the past few weeks we were able to confirm that the LLVM's JIT compiler can be used for our research project. This was confirmed for x86-64 architecture (with very good performance results by the way). Now, one of our real target architecture is the Intel Xeon Phi (KNC) accelerator in a native execution model. When cross-compiling LLVM (3.4 RC1) for Xeon Phi with CMake following

The project files need frequent updating. I cannot maintain VS2005 project files, so while they could be distributed with LLVM, they will become broken fast. Also, VS2003 and VS2005 project and solution files cannot coexist in the same directories, further complicating matters. Aaron Gray wrote: > Hi Morten, > > If you can make the VS2005 project files availiable on the net then I