[LLVMdev] Win32 COFF Support

[Nathan Jeffords]

On Sun, Jun 13, 2010 at 2:56 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:

> On Sun, Jun 13, 2010 at 4:43 PM, Nathan Jeffords
> <blunted2night at gmail.com> wrote:
> >> I know some people are working on native linkers for LLVM. It would be
> >> interesting to see an architecture for handling object files that
> >> could be shared between lib/MC and a linker.
> >
> >
> > This would be good I think.
> > If a linker loaded object files into an IR, maybe CAssembler could handle
> > the linking process also. Would it be safe to assume that on a
> > development/build machine, the executable image, and all the object files
> it
> > will be made up of could be loaded into memory in some IR? Or would an
> > architecture where the linker only reads headers and symbol information
> into
> > memory and then copies data sections into the final EXE on the fly?
>
> Considering how large object files can get, I would think it's not a
> good idea to load all the content of all the object files into an IR.
> However, the object file headers could be loaded into an IR that
> references the data still on disk, and then lazily load the data when
> it is time to insert relocations and write out the final executable.
>
> I would also assume that the linker should be able to accept llvm byte
> code and output an executable. In a pure llvm/clang tool chain there
> should be no reason to use native object files other than linking
> against code you only have in native format.
>
> And back to the topic at hand. I have attached tests that work with
> the changes Daniel made to lit. I switched to using llc and .ll files
> instead of llvm-mc and .s files due to the lack of COFF support in
> llvm-mc.
>
> - Michael Spencer
>

Nice, is their any dependencies besides python and a LLVM build enviroment?
cygwin? MinGW?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100613/145f00ee/attachment.html>