[LLVMdev] VC++ linking issues, revisited

[Reid Spencer]

Jeff,

There should be a way to do what we do with the Unix Makefiles and build
re-linked object modules. That is, when we build an analysis or
transform pass, we create two things: a .o file and a .a file. They
contain the same code but the latter is searchable while the former is
not.

Can you not "pre-link" a bunch of .obj files together with VC++ to
produce a new .obj file? And, when linking something like opt, will it
not just put all .obj files that you specify into the executable? I
think this is the best approach as it avoids some slowness in start up
of the tool if the equivalent DLL approach was taken.

Reid.

On Sat, 2005-01-01 at 17:05, Jeff Cohen wrote:
> I've gone about as far as I can in building executables with VC++.  The 
> problem with the remaining ones is that they rely on the static 
> constructor trick to register various modules.  This doesn't work with 
> VC++ because without an explicit external reference to these modules 
> they simply can't be linked in to an executable.
> 
> This isn't a new problem, of course.  Morten originally ran into this 
> getting the X86 backend to link in, and solved it by introducing a 
> global variable that could be used as the external reference.  The 
> problem is, this doesn't scale.  There are few code generator targets, 
> and fewer still that one would care to use on Windows.  But there are 
> dozens of optimizations and analyses.  It's not practical or 
> maintainable to give each one a global variable and then reference it 
> from each affected executable.
> 
> So I can (and have, actually) build "opt", but it's just a big waste of 
> bytes as it has no optimizations available to it.  And if I understand 
> things correctly, it means that the JIT can't do any optimizations either.
> 
> I'm not really sure how to deal with this.  The best solution I can come 
> up with is to put all of these modules into DLLs.  When a DLL is loaded, 
> all of its static constructors are executed, regardless of which modules 
> are externally referenced.  Nonetheless, there must be at least *one* 
> external reference, or else the DLL wouldn't be loaded automatically in 
> the first place.  The DLL could be manually loaded, but that would be 
> introducing Windows-specific code in places you probably don't want it.  
> However, one global (or dummy function) for all optimizations or all 
> code generator targets or all analyses is much better than one for each 
> optimization or target or analysis.
> 
> I think this will work, but it does represent a major change in how the 
> VC++ build is conducted and I want to get feedback first, especially 
> from Morten.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050101/ed471eca/attachment.sig>