similar to: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build

Hello, Chuck > Would my life be made fantastically simpler if I were using a different > calling convention for my callback functions on x64 running on Windows? Yes, surely. You can still use 'normal' x86-64 CC if you don't want to call any external functions from code being JITed. Also note a Win64 fixme in the X86CompilationCallback2 function, this can be your case. I think

Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to

> The x86-64 one probably doesn't work for Winodws. That's likely the > issue. Well, x86-64 stub was never ported to intel assembler, I expect to see 32-bit one used on windows64. In general, the whole windows64 support is missed mainly due to crazy calling convetion invented by Microsoft. So, all calls from code being JITed to external functions will be clearly broken (if they

Hello, Evan > I am not sure if it has been tested on x86-64 Windows. > Anton, do you know? I don't think it was ever written (for vcpp). There is 32-bit stub only. -- WBR, Anton Korobeynikov

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going

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

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:

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 is first materialized with a mov instruction which can encode the immediate 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 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:

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

Hello Group, I am trying out RQuantLib on a 64bit Win 7 machine. But running into installation errors install.packages("RQuantLib") Warning in install.packages("RQuantLib") : argument 'lib' is missing: using 'C:\Users\Tester\Documents/R/win64-library/2.11' Warning: unable to access index for repository

These packages were not available. Are these the only places to go for backtesting technical trading systems other than ttrTests pls? > install.packages("quantstrat", repos="http://R-Forge.R-project.org") Warning in install.packages("quantstrat", repos = " http://R-Forge.R-project.org") : argument 'lib' is missing: using

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

2008/9/21 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider

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

my build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) my build steps: open VS2017 x64 developer command prompt cd D:\projects\fun\jit_tests mkdir llvm cd llvm git clone https://github.com/llvm-mirror/llvm mkdir llvm-build cd llvm-build cmake -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON

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

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