Óscar Fuentes wrote:> srs <skaflotten at gmail.com> writes: > > >>>> While testing my compiler on win32 in JIT mode, I ran into a couple of >>>> issues: >>>> >>>> 1. I linked the compiler with the lib files resulting from the cmake >>>> created VS.NET build. While everything built just fine, the >>>> ExecutionEngine::create call always returned NULL. The fix was to also >>>> link with JIT.obj (thanks aKor for pointing me in the right direction). >>>> I would have thought that linking with LLVMJIT.lib should suffice... a >>>> VC++ linker issue? >>>> >>>> >>> Try adding this to the link command of your executable: >>> >>> /INCLUDE:_X86TargetMachineModule >>> >>> I should document this somehow. >>> >> Yeah, this is necessary, but not sufficient. I also had to link with >> ExecutionEngineBindings.obj (not JIT.obj as first stated) >> > > So you are using the C bindings. Okay, could someone advise what to do > here? Something like the _X86TargetMachineModule trick on > lib/Target/X86/X86TargetMachine.cpp line 26, but on > lib/ExecutionEngine/ExecutionEngineBindings.cpp? > > Why is not the linker automatically pulling that code? If you are using > the C bindings, I suppose that your executable refers to the functions > defined on ExecutionEngineBindings.cpp. It is not the same case as > X86TargetMachine.cpp, which has a self-registering static C++ object and > nothing refers to it from the user's codeI'm actually not using C bindings; I'm using the C++ API directly. I have no idea why I have to link that object file. /Stein Roger
Misha Brukman
2008-Dec-31 02:10 UTC
[LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?
2008/12/30 srs <skaflotten at gmail.com>> Óscar Fuentes wrote: > > srs <skaflotten at gmail.com> writes: > > > > > >>>> While testing my compiler on win32 in JIT mode, I ran into a couple of > >>>> issues: > >>>> > >>>> 1. I linked the compiler with the lib files resulting from the cmake > >>>> created VS.NET build. While everything built just fine, the > >>>> ExecutionEngine::create call always returned NULL. The fix was to also > >>>> link with JIT.obj (thanks aKor for pointing me in the right > direction). > >>>> I would have thought that linking with LLVMJIT.lib should suffice... a > >>>> VC++ linker issue? > >>>> > >>>> > >>> Try adding this to the link command of your executable: > >>> > >>> /INCLUDE:_X86TargetMachineModule > >>> > >>> I should document this somehow. > >>> > >> Yeah, this is necessary, but not sufficient. I also had to link with > >> ExecutionEngineBindings.obj (not JIT.obj as first stated) > >> > > > > So you are using the C bindings. Okay, could someone advise what to do > > here? Something like the _X86TargetMachineModule trick on > > lib/Target/X86/X86TargetMachine.cpp line 26, but on > > lib/ExecutionEngine/ExecutionEngineBindings.cpp? > > > > Why is not the linker automatically pulling that code? If you are using > > the C bindings, I suppose that your executable refers to the functions > > defined on ExecutionEngineBindings.cpp. It is not the same case as > > X86TargetMachine.cpp, which has a self-registering static C++ object and > > nothing refers to it from the user's code > > I'm actually not using C bindings; I'm using the C++ API directly. I > have no idea why I have to link that object file.Would either of you be willing to prepare a patch for this document once you've settled on the proper way to get JIT to work on Visual Studio? http://llvm.org/docs/GettingStartedVS.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/2379742d/attachment.html>
Óscar Fuentes
2008-Dec-31 02:13 UTC
[LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?
srs <skaflotten at gmail.com> writes:>>>> Try adding this to the link command of your executable: >>>> >>>> /INCLUDE:_X86TargetMachineModule >>>> >>>> I should document this somehow. >>>> >>> Yeah, this is necessary, but not sufficient. I also had to link with >>> ExecutionEngineBindings.obj (not JIT.obj as first stated) >>> >> >> So you are using the C bindings. Okay, could someone advise what to do >> here? Something like the _X86TargetMachineModule trick on >> lib/Target/X86/X86TargetMachine.cpp line 26, but on >> lib/ExecutionEngine/ExecutionEngineBindings.cpp? >> >> Why is not the linker automatically pulling that code? If you are using >> the C bindings, I suppose that your executable refers to the functions >> defined on ExecutionEngineBindings.cpp. It is not the same case as >> X86TargetMachine.cpp, which has a self-registering static C++ object and >> nothing refers to it from the user's code > > I'm actually not using C bindings; I'm using the C++ API directly. I > have no idea why I have to link that object file.This is very strange. Can you test if the Fibonacci.exe example runs quick? (It should show the result almost instantaneously. Discard the first run: most of that time is the OS loading the executable from disk) If the Fibonacci example works, please compare its link command options with your compiler's. -- Oscar
Óscar Fuentes
2008-Dec-31 02:19 UTC
[LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?
"Misha Brukman" <brukman at gmail.com> writes:>> >>> Try adding this to the link command of your executable: >> >>> >> >>> /INCLUDE:_X86TargetMachineModule >> >>> >> >>> I should document this somehow. > > Would either of you be willing to prepare a patch for this document once > you've settled on the proper way to get JIT to work on Visual Studio? > > http://llvm.org/docs/GettingStartedVS.htmlI'm documenting it on http://llvm.org/docs/CMake.html. I'll commit the changes once this issue is settled. IMO, the document you mention shouldn't mention build instructions, just refer to the CMake doc. I plan to make this and other cmake-related changes to the LLVM docs ASAP (read: after a few weeks from now). -- Oscar
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Óscar Fuentes wrote: <blockquote cite="mid:m3myedum6e.fsf@telefonica.net" type="cite"> <pre wrap="">srs <a class="moz-txt-link-rfc2396E" href="mailto:skaflotten@gmail.com"><skaflotten@gmail.com></a> writes: </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Try adding this to the link command of your executable: /INCLUDE:_X86TargetMachineModule I should document this somehow. </pre> </blockquote> <pre wrap="">Yeah, this is necessary, but not sufficient. I also had to link with ExecutionEngineBindings.obj (not JIT.obj as first stated) </pre> </blockquote> <pre wrap="">So you are using the C bindings. Okay, could someone advise what to do here? Something like the _X86TargetMachineModule trick on lib/Target/X86/X86TargetMachine.cpp line 26, but on lib/ExecutionEngine/ExecutionEngineBindings.cpp? Why is not the linker automatically pulling that code? If you are using the C bindings, I suppose that your executable refers to the functions defined on ExecutionEngineBindings.cpp. It is not the same case as X86TargetMachine.cpp, which has a self-registering static C++ object and nothing refers to it from the user's code </pre> </blockquote> <pre wrap="">I'm actually not using C bindings; I'm using the C++ API directly. I have no idea why I have to link that object file. </pre> </blockquote> <pre wrap=""><!----> This is very strange. Can you test if the Fibonacci.exe example runs quick? (It should show the result almost instantaneously. Discard the first run: most of that time is the OS loading the executable from disk) If the Fibonacci example works, please compare its link command options with your compiler's</pre> </blockquote> <br> The Fibonacci example works just fine; results appear quickly. The link options are the same AFAICT (except for the addition of ExecutionEngineBindings.obj...)<br> <br> /Stein Roger<br> <br> </body> </html>
Óscar Fuentes wrote:> srs <skaflotten at gmail.com> writes: > > >>>>> Try adding this to the link command of your executable: >>>>> >>>>> /INCLUDE:_X86TargetMachineModule >>>>> >>>>> I should document this somehow. >>>>> >>>>> >>>> Yeah, this is necessary, but not sufficient. I also had to link with >>>> ExecutionEngineBindings.obj (not JIT.obj as first stated) >>>> >>>> >>> So you are using the C bindings. Okay, could someone advise what to do >>> here? Something like the _X86TargetMachineModule trick on >>> lib/Target/X86/X86TargetMachine.cpp line 26, but on >>> lib/ExecutionEngine/ExecutionEngineBindings.cpp? >>> >>> Why is not the linker automatically pulling that code? If you are using >>> the C bindings, I suppose that your executable refers to the functions >>> defined on ExecutionEngineBindings.cpp. It is not the same case as >>> X86TargetMachine.cpp, which has a self-registering static C++ object and >>> nothing refers to it from the user's code >>> >> I'm actually not using C bindings; I'm using the C++ API directly. I >> have no idea why I have to link that object file. >> > > This is very strange. Can you test if the Fibonacci.exe example runs > quick? (It should show the result almost instantaneously. Discard the > first run: most of that time is the OS loading the executable from disk) > > If the Fibonacci example works, please compare its link command options > with your compiler's. >(Resending... was scrubbed due to html) The Fibonacci example works just fine; results appear quickly. The link options are the same AFAICT (except for the addition of ExecutionEngineBindings.obj...) /Stein Roger
Maybe Matching Threads
- [LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?
- [LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?
- [LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?
- [LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?
- [LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?