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