[LLVMdev] LLVM Win32 Issue

[Aaron Dwyer]

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 <cfr at adobe.com> 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: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
>  On Behalf Of Aaron Dwyer
>  Sent: Wednesday, February 20, 2008 7:16 PM
>  To: llvmdev at cs.uiuc.edu
>  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
>  LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>  _______________________________________________
>  LLVM Developers mailing list
>  LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>