[LLVMdev] VC++ linking issues, revisited

Chris Lattner sabre at nondot.org
Sat Jan 1 20:21:18 PST 2005


On Sat, 1 Jan 2005, Jeff Cohen wrote:

> No, VC++ has no way to combine multiple .obj files into one.  Nor is there 
> any way to force the entire contents of a .lib file into an executable. 
> Believe me, I looked for a way.  Morten couldn't find one either.  Even 
> Microsoft's command line tools can't do it.  Advantage:  GNU.
>
> DLLs aren't that slow any more.  Windows is so dependent on DLLs (the Win32 
> API itself is implemented as DLLs) that a lot of effort has gone into 
> optimizing them.  You wouldn't believe the number of DLLs that are present in 
> a process for a program that doesn't have any DLLs of its own.  I even found 
> the VC++ 6.0 runtime DLL in LLVM processes, and I haven't a clue how *that* 
> got loaded (must be used by some system-supplied DLL).

Why not just build the optimization libraries as DLLs then?

-Chris

>> 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
>>> 
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/




More information about the llvm-dev mailing list