[LLVMdev] LLVM built on VS C++ 2005

[Aaron Gray]

>> I thought Whidbey would really be upto the job, obviously not.
>
> Well, we don't know until someone tries.

Oh, well we have got a bug to report to Microsoft then !

I still may carry on implementing any mods on the VS2003 port over to 2005
so we know where we are with that. There may well be a second beta so it
would be good to get any problems in and reported to Microsoft in lue of
that.

Q. Is abort() used rather than C++ exception handling for compatibility
reasons with older C++ compilers ?

> These changes aren't worth rolling back.

Also they stand for any c++ compilers that do not implement a noreturn
attribute, if there are any. And any that do will likely optimise the
constructors and return out anyway.

>> Jeff, as I say if I can work with/under you on the Visual C++ 2003 port
>> then maybe we can get some real work done.
>
> Reid gave a good summary of what needs to be done.  To that list I would
> add:
>
>    * The X86 assembler printer needs to be modified to generate
>      assembler code that works with NASMW.  It currently generates
>      assembler for the GNU assembler, gas.  The goal is to use the GNU
>      tool chain as little as possible when using VC++ for native
>      builds.  Microsoft's MASM isn't really an option because Microsoft
>      stopped distributing it as part of Visual Studio a long time ago.

Okay, sounds interesting, but I am not familiar with GAS and NASM syntax,
only MASM. Never fond of AT&T syntax.

>    * There is no language front end that can be used with native builds
>      at this time.  The GNU C/C++/Java front ends cannot be built
>      natively with VC++.  This isn't strictly necessary as the front
>      ends do not directly link against LLVM anyway.  Nonetheless, we
>      don't have binaries built with cygwin or mingw that can be
>      distributed for use with a natively built LLVM.

GNU's frontends are in C is that the problem ? I do not see the area
properly. Please can you explain thurther.

>    * Even when front ends become available, there are still issues with
>      linking, especially for C++.  As the front end is based on g++, it
>      wants g++ header files and it emits code that needs to link
>      against g++ runtime libraries.  That sort of defeats the point of
>      a native Windows LLVM.  It's not yet clear how well C code can
>      link against MS C's libraries, though it ought to work (and does
>      for simple cases).

Difficult one, ABI compatibility problems ? Maybe we need to support
different ABI's, either that, or LLVM needs its own runtime libraries for C
and C++ ? Runtime libraries are not really one area I have studied much
apart from minimizing them.

One thing I have been thinking of is direct generation of Windows PE
(Portable Executable) EXE and DLL files from ahead of time machine code
generation which I believe LLVM can generate ? Also possibly of Microsoft
OBJ and LIB files.

Again ABI's rear their head again, maybe we go for a native format that will
link with Win32 C for Win32 API support. Then look at full MS C/C++ ABI
support later. We could create and compile a runtime once we a frontend.

This is an area I am reasonably familiar with and would like to tackel. It
will take me a while studying LLVM's interfaces and code to get into a
position to be able to code this.

Anyway get NASMW generation first as a baseline for Win32. LLVM can generate
C to be compiled with MinGW or VC at the moment presumably.

> So the question is, what would you like to work on?

Really I will have to think about it when I am more familiar with LLVM and
know the ground better. But if you have any reasonably small/incremental
tasks that need doing then I am open to that.

Anyway I will take a couple of weeks to a month to study LLVM properly and
have a play with what is availiable on the Win32 platforms. I have yet to
build LLVM properly under Cygwin and will also try MinGW. This is what I'll
do next.

I hope to use LLVM in my own language project when it is ported to Windows
properly. I was hoping porting would have been a little quicker time scale,
I was a bit too quick off the mark, but I have the time to spend on LLVM now
so am committed to what looks a great project.

Thanks for bearing with me,

Aaron