LLVM Win32 Issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM Win32 Issue

Aaron Aaron
Thanks for your response Chuck.

>From this and the other responses to my question, it looks like I'm
including all the right object files, so it must be something with
Visual Studio stripping "dead" code.

So, given your response Chuck, I have a few questions.

First, what exactly is the code that VStudio seems to be stripping?  I
might be able to figure out how to prevent it from being overzealous.

Second, I tried putting the code you gave in my app, and I got into a
wild goose chase of include files not being found.  Finally ended
with:

<myabsolutepathroot>\llvm\target\x86\x86instrinfo.h(225) : error
C2504: 'TargetInstrInfoImpl' : base class undefined

   Did you put that code into LLVM itself and then call it from your app?

Lastly, what do you mean by "somewhere real"?

Thanks again,

Aaron


> You'll need to link in x86.lib as generated from the VStudio project.
>
> I had trouble convincing VStudio's linker to keep the relevant code
> around, so did this in the app I work on:
>
> void
> LLVMCompiledProgram::linkerTrick()
> {
>     llvm::Module staticModule("staticModule");
>     std::string staticString;
>     llvm::X86_32TargetMachine staticMachine(staticModule, staticString);
> }
>
> Which I called from somewhere real.
>
> Chuck.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Win32 Issue

Chuck Rose III
Hola Aaron,

Just having that code didn't work since the linker still stripped it
out, so I have that function called from the code in the system that
actually is being used by our app.  

Kinda grubby, but I include:

  #include "llvm/lib/Target/X86/X86TargetMachine.h"

Which is in the LLVM lib, not the LLVM inc directory.  This little
maneuver made our Mac builds really unhappy, so we conditionally compile
all this goo.

I don't remember needing to do anything other than include the lib, the
header above, and the bit of code I sent around.

I'm sure there are better ways to do this and I'd love to hear about
them if you discover something cool.

Chuck.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Aaron Dwyer
Sent: Wednesday, February 20, 2008 7:16 PM
To: [hidden email]
Subject: [LLVMdev] LLVM Win32 Issue

Thanks for your response Chuck.

>From this and the other responses to my question, it looks like I'm
including all the right object files, so it must be something with
Visual Studio stripping "dead" code.

So, given your response Chuck, I have a few questions.

First, what exactly is the code that VStudio seems to be stripping?  I
might be able to figure out how to prevent it from being overzealous.

Second, I tried putting the code you gave in my app, and I got into a
wild goose chase of include files not being found.  Finally ended
with:

<myabsolutepathroot>\llvm\target\x86\x86instrinfo.h(225) : error
C2504: 'TargetInstrInfoImpl' : base class undefined

   Did you put that code into LLVM itself and then call it from your
app?

Lastly, what do you mean by "somewhere real"?

Thanks again,

Aaron


> You'll need to link in x86.lib as generated from the VStudio project.
>
> I had trouble convincing VStudio's linker to keep the relevant code
> around, so did this in the app I work on:
>
> void
> LLVMCompiledProgram::linkerTrick()
> {
>     llvm::Module staticModule("staticModule");
>     std::string staticString;
>     llvm::X86_32TargetMachine staticMachine(staticModule,
staticString);
> }
>
> Which I called from somewhere real.
>
> Chuck.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Win32 Issue

Aaron Aaron
Hey there Chuck,

My first attempt at what you describe led to bad build errors on
Windows as well, but I will keep trying, as my first attempt had a lot
of shooting from the hip involved.  I will definitely let you know if
I figure out a way to have Visual Studio leave our precious static
initialization foo alone.

I did find the function LinkInJIT() which at least sets JITCtor, and
call it from my client app, but now deeper inside
ExecutionEngine::create I run into the problem that the
X86TargetMachine isn't being registered in the TargetMachineRegistry.
I presume this is because lines 33-39 of X86TargetMachine.cpp are
being "optimized" out.  I have to say, I miss that code.  Sorely.  I
also presume this is what your trick attempts to patch up.  Is that
so?

I wonder how big a change it would be to provide a single "llvm init"
sort of entry point which performs all the same operations that we are
currently relying on static initialization and global instantiation
for, so that the compiler simply couldn't drop stuff on the floor.  It
would mean clients of LLVM would have to make some sort of "Init"
call.  Actually no it wouldn't, the init function could have a flag
which it sets, and leave some sort of thing like:

static struct LLVMInitializer {LLVMInitializer() {InitializeLLVM();}}
initializer;

That way on systems where global instantiation is reliable, it would
still happen implicitly, but for projects which need to work on
Windows, the client code could simply call InitializeLLVM() directly.
Big Giant Uber Initialization Functions kind of give me the creeps,
admittedly, but I think one is appropriate here, because there really
is a lot of large scale initialization going on in LLVM.

Meantime I'll try to get your approach working and simultaneously look
for magic Visual Studio foo to tell it not to get rid of those global
initializers.

Aaron


On Thu, Feb 21, 2008 at 11:15 AM, Chuck Rose III <[hidden email]> wrote:

> Hola Aaron,
>
>  Just having that code didn't work since the linker still stripped it
>  out, so I have that function called from the code in the system that
>  actually is being used by our app.
>
>  Kinda grubby, but I include:
>
>   #include "llvm/lib/Target/X86/X86TargetMachine.h"
>
>  Which is in the LLVM lib, not the LLVM inc directory.  This little
>  maneuver made our Mac builds really unhappy, so we conditionally compile
>  all this goo.
>
>  I don't remember needing to do anything other than include the lib, the
>  header above, and the bit of code I sent around.
>
>  I'm sure there are better ways to do this and I'd love to hear about
>  them if you discover something cool.
>
>  Chuck.
>
>
>
>
>  -----Original Message-----
>  From: [hidden email] [mailto:[hidden email]]
>  On Behalf Of Aaron Dwyer
>  Sent: Wednesday, February 20, 2008 7:16 PM
>  To: [hidden email]
>  Subject: [LLVMdev] LLVM Win32 Issue
>
>  Thanks for your response Chuck.
>
>  >From this and the other responses to my question, it looks like I'm
>  including all the right object files, so it must be something with
>  Visual Studio stripping "dead" code.
>
>  So, given your response Chuck, I have a few questions.
>
>  First, what exactly is the code that VStudio seems to be stripping?  I
>  might be able to figure out how to prevent it from being overzealous.
>
>  Second, I tried putting the code you gave in my app, and I got into a
>  wild goose chase of include files not being found.  Finally ended
>  with:
>
>  <myabsolutepathroot>\llvm\target\x86\x86instrinfo.h(225) : error
>  C2504: 'TargetInstrInfoImpl' : base class undefined
>
>    Did you put that code into LLVM itself and then call it from your
>  app?
>
>  Lastly, what do you mean by "somewhere real"?
>
>  Thanks again,
>
>  Aaron
>
>
>  > You'll need to link in x86.lib as generated from the VStudio project.
>  >
>  > I had trouble convincing VStudio's linker to keep the relevant code
>  > around, so did this in the app I work on:
>  >
>  > void
>  > LLVMCompiledProgram::linkerTrick()
>  > {
>  >     llvm::Module staticModule("staticModule");
>  >     std::string staticString;
>  >     llvm::X86_32TargetMachine staticMachine(staticModule,
>  staticString);
>  > }
>  >
>  > Which I called from somewhere real.
>  >
>  > Chuck.
>  _______________________________________________
>  LLVM Developers mailing list
>  [hidden email]         http://llvm.cs.uiuc.edu
>  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>  _______________________________________________
>  LLVM Developers mailing list
>  [hidden email]         http://llvm.cs.uiuc.edu
>  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Win32 Issue

Morten Ofstad
In reply to this post by Chuck Rose III
Chuck Rose III wrote:

> Hola Aaron,
>
> Just having that code didn't work since the linker still stripped it
> out, so I have that function called from the code in the system that
> actually is being used by our app.  
>
> Kinda grubby, but I include:
>
>   #include "llvm/lib/Target/X86/X86TargetMachine.h"
>
> Which is in the LLVM lib, not the LLVM inc directory.  This little
> maneuver made our Mac builds really unhappy, so we conditionally compile
> all this goo.
>
> I don't remember needing to do anything other than include the lib, the
> header above, and the bit of code I sent around.
>
> I'm sure there are better ways to do this and I'd love to hear about
> them if you discover something cool.

If you have a look in X86TargetMachine.cpp you should find the following (unless someone removed it, I put it there
around the time of LLVM 1.5):

/// X86TargetMachineModule - Note that this is used on hosts that cannot link
/// in a library unless there are references into the library.  In particular,
/// it seems that it is not possible to get things to work on Win32 without
/// this.  Though it is unused, do not remove it.
extern "C" int X86TargetMachineModule;
int X86TargetMachineModule = 0;

... combined with the Linker->Input->Force Symbol References field in the visual studio project property pages of your
project you will get the desired effect. Nnote that the symbol is named _X86TargetMachineModule when you look at it from
the outside, so you need to put this in the Force Symbol References.

m.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev