[LLVMdev] LLVM built on VS C++ 2005

[Chris Lattner]

On Fri, 18 Feb 2005, Aaron Gray wrote:
>>> 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.

ok.

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

These aren't recoverable errors: These abort calls are really put in for 
the moral equivalent of "assert(0);": in cases where we expect control not 
to reach.  EH is used when there is some recovery action that can be done 
to repair the situation.

>> 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.

Indeed.

>>> 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
...
> Okay, sounds interesting, but I am not familiar with GAS and NASM syntax,
> only MASM. Never fond of AT&T syntax.

Actually, AT&T vs Intel syntax is not the issue.  LLC can already emit 
either syntax (-x86-asm-syntax={intel|att}).  The missing pieces are the 
various assembler directives that need to be tweaked.  Making this change 
is much less involved than changing the syntax of the instructions.

>>    * 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.

I'll let Jeff explain this one.

>>    * 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.

I think that G++ has some support for linking to native windows libraries, 
using by MingW?  We should eventually be able to do as well as it does. 
Note that for non C/C++ compilers, this is not an issue.

> 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.

Yes, this would be very valuable.

> 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.

I would suggest working on the AsmWriter to get it to emit directives that 
NASMW likes.  This should just be a matter of doing the following steps:

1. Define a new subclass of X86IntelAsmPrinter in the
    lib/Target/X86/X86AsmPrinter class, name it X86NASMAsmPrinter or
    something.
2. In the subclass, change any behaviors that you don't like (e.g.
    change it to use the appropriate directives for NASM).
3. Add this option to the AsmWriterFlavor variable at the top of the file,
    so we can say "-x86-asm-syntax=nasm"
4. Modify X86TargetMachine.cpp so that addPassesToEmitAssembly() create a
    NASM target machine if the target triple stored in the module is set to
    something windows like.  I don't know what the standard target triples
    are for windows.

Once that's done, everything should work. :)  To figure out what you need 
to change for #2, just compile a .bc file with '-x86-asm-syntax=intel' and 
try compiling it with NASM, keep fixing stuff until it takes it. :)

> 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.

Ok

> 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.

Cool.

> Thanks for bearing with me,

No problem at all, thanks for the patches!

-Chris

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