llvm dev - Feb 2005 - [LLVMdev] LLVM built on VS C++ 2005

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/

On Friday 18 February 2005 11:19 am, Chris Lattner
wrote:
> 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.
It does indeed.  You can even use mingw/g++ to cross-compile Windows exe under 
Linux.

Chris Lattner wrote:
> On Fri, 18 Feb 2005, Aaron Gray wrote:
>
>> 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.
The problem is that gcc cannot be built using VC++.  You'll have to ask 
the gcc project as to why, but they've made it clear they have no 
intention of supporting this.  Even if it could, a gcc build would still 
require a complete unix emulation environment.

I'm not sure you understand the problem.  Are you saying that a file 
compiled with mingw can catch an exception thrown by a file compiled 
with VC++ when the two are linked into a single program?  That a program 
compiled with mingw can be linked against the VC++ runtime and *not* the 
mingw/gcc runtime?

Linking against system DLLs is very different from what I'm talking about.

Adam Treat wrote:
>On Friday 18 February 2005 11:19 am, Chris Lattner wrote:
>  
>
>>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.
>>    
>>
>
>It does indeed.  You can even use mingw/g++ to cross-compile Windows exe
under
>Linux.
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>  
>

>> 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.
If both you and Jeff are okay with still implementing a VC2005 version 
spawning off changes to the VC2003 port then I am happy to do that.
>> 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.
I should have caught that abort() no return :(
> 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.
Nice, I really need to familiarize myself with LLVM's documentation before 
tackelling
any real programming as such. Porting from 2003 to 2005 was not really that 
deeper problem.
> 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.
Nice, that is encouraging, good old MinGW. It should then be able to compile 
C generated
from LLVM (yes?) and be a Free(dom) alternative to VC++ for Win32.
>> 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.
I would like to tackel this area if no one else does, by the time I am 
ready. The only thing is the ABI calling conventions issue, that goes for 
NASM generated code too, yes ? I don't know LLVM's ABI calling
convention
capabilities :(
>>> 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. :)
Okay when I have got familular with LLVM enough if no one else has done it 
by then I will take it as first programming task, as it seems quite self 
contained. But I would like to familurize myself with NASM properly first so 
as to no slip on step #2 :)
Sound like fun learning NASM and generating tailored code for it. Is there a 
test set that would be appropriate or adaptable for testing 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 am having problems installing GCC 3.4.3 under CygWin, got the path (the 
easy bit) but not the include and library directory paths, having problems 
knowing how to install it over 3.3.3. Any clues welcome. Anyway I put a Q on 
the gcc.help newsgroup.

This *should* be easy. Unfortunately my GNU is a bit on the limited side, 
still really a WindoZer as they say.

If I can get LLVM compiled under CygWin and MinGW then I can 'play' with
LLVM a bit and get to know its tools.

Cheers,

Aaron

>From: Chris Lattner
>Date: Fri, 18 Feb 2005 10:19:56 -0600 (CST)
>I think that G++ has some support for linking to native windows libraries, 
>using by MingW?
Yes, it does. No problem.

Henrik.

_________________________________________________________________
F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/

>From: Jeff Cohen Date: Fri, 18 Feb 2005 08:37:25 -0800
>The problem is that gcc cannot be built using VC++.  You'll have to ask
the
>gcc project as to why, but they've made it clear they have no intention
of
>supporting this.  Even if it could, a gcc build would still require a 
>complete unix emulation environment.
However, we could provide a binary version from MinGW.

Henrik.

_________________________________________________________________
Find det, du s�ger p� MSN S�g http://search.msn.dk

Aaron Gray wrote:
>>> 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.
>
>
> If both you and Jeff are okay with still implementing a VC2005 version 
> spawning off changes to the VC2003 port then I am happy to do that.
I don't have a problem with it so long as Whidbey reasonably behaves itself.