Aaron Gray wrote:>> GCC is smart enough to realize it doesn't return. That's because the >> declaration of abort() is decorated with __attribute__((__noreturn__)). >> >> So is GCC smarter than VC++? As it turns out, in VC++ the >> declaration of abort() is decorated with __declspec(noreturn). >> >> Whidbey is not stricter than 2003, it is merely buggier. VC++ has >> always complained about functions failing to return a value; this is >> not new in Whidbey. What is new is that it no longer pays attention >> to __declspec(noreturn). > > > Got by a Microsoft bug, sorry about that folks. I should have looked > at abort()'s declaration. > >> That is why it is difficult to justify supporting Whidbey. This bug >> may have been easy to work around. The next one may not be so easy. >> Remember, if Whidbey wasn't buggy and incomplete, you'd be paying >> around $1000 for it instead of downloading it for free. > > > Too earger to get LLVM running. Really I should have checked things > out deeper. > I thought Whidbey would really be upto the job, obviously not.Well, we don't know until someone tries.> > I have ordered a copy of Visual Studio 2003 now anyway so can work > with that. > > The CVS changes may probably want rolling back ?These changes aren't worth rolling back.> > 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. * 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. * 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). So the question is, what would you like to work on? Also, you need to update. The other problems you encountered have already been fixed.> > Sorry again for any confusion caused. > > Aaron > > > >
>> 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
On Thu, 17 Feb 2005, Jeff Cohen wrote:> 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.Another option is just to extend LLC to directly emit Win32 OBJ files directly, so you don't need an assembler... -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
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/