llvm dev - Dec 2008 - [LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?

Ó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.

/Stein Roger

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>

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

"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.html
I'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