[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