Thanks for your response Chuck.>From this and the other responses to my question, it looks like I'mincluding 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.
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'mincluding 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
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
>
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.