LLVM built on VS C++ 2005

Project Infrastructure LLVM Dev List Archives
1

Hi,

I have built yesterdays CVS download of LLVM on Whidbey (Microsoft Visual Studio 2005).

LLVM built with trivial mods due to VS strictness compared to GCC. Basically there are missing return statement/values where Abort() is called, I replaced these with dummy constructors to get them to compile.

I do not have 2003. 2005 is much stricter than 2003 and there are quite alot of warnings on certain files.

There where also path differences between VS 2003 and 2005.

Anyway it builds but I have not tested it yet, Fibonacci assembles and runs though.

If you want detailed mods/files/diffs for LLVM on 2005 then please do ask.

Trivial but good news,

Aaron

2

Trivial? That's GREAT news! Nice job.

Yes, we would be interested in the patches to get it to run.

Thanks for letting us know!

Reid.

3

I have built yesterdays CVS download of LLVM on Whidbey (Microsoft Visual Studio 2005).

Thats actually the CVS download from 15th of this month.

Sorry about that,

Aaron

4

Hi Reid,

I'll send a complete report tommorow, its getting late.

It looks like there is alot of work to do to get the MS VC version in line with the Unix release. I am very willing to help out with porting.

The tests and regression tests look a biggy maybe they would be better done on the command line using make rather than separate Visual Studio projects.

As I say I am willing to help out porting so maybe to avoid duplication if someone takes charge and points to what needs doing then it would be easier than me just going blind at the problem.

Aaron

5

Hi Reid,

I'll send a complete report tommorow, its getting late.

Great!

It looks like there is alot of work to do to get the MS VC version in line
with the Unix release. I am very willing to help out with porting.

Yes, there are several well known issues remaining. The bugpoint tool
and the debugger use unix specific function calls. Unfortunately,
replacing them means doing a little re-design work. In general I've been
responsible for overall portability but Jeff Cohen has done the bulk of
the legwork for VC++ and Win32. Henrik Bach has also got things running
under mingw compiler. Any expertise/help you can provide in these areas
would be very welcome (patches accepted!) as we are striving to get all
of LLVM running under windows (natively and with Cygwin).

The tests and regression tests look a biggy maybe they would be better done
on the command line using make rather than separate Visual Studio projects.

I'd talk to Jeff Cohen about that. We use dejagnu and a pretty simple
command line interpreter (test/TestRunner.sh) to invoke the feature and
regression tests. The llvm-test project is a whole other thing.

As I say I am willing to help out porting so maybe to avoid duplication if
someone takes charge and points to what needs doing then it would be easier
than me just going blind at the problem.

Sure, here's a few tips:

1. lib/System (include/llvm/System) is the operating system abstraction
layer. It provides only those things that LLVM needs so its not a
complete abstraction layer. Its currently divided into two camps: Unixes
and Win32. It might get subdivided further if we port to other operating
system types (OS/390, VMS, RTOS, etc.). The basic idea is that the
interfaces provided in include/llvm/System get implemented with the same
semantics on all platforms.

2. API documentation here: http://illuvium.com/docs/doxygen/. More
general documentation is at http://llvm.cs.uiuc.edu/docs/. In
particular, you should read the Getting Started document if you haven't
already.

3. The win32 directory (at top level) contains the vcproj files for
building with the MS compiler. No doubt you've already discovered these.

4. The generalization of debugger inferior processes hasn't been done
yet because the underlying operating system mechanisms are so different.
This is what is holding up the llvm-db tool from working on win32. We
need to factor out the platform-specific portions and make lib/System
interfaces for them and then make it portable.

5. The use of fork (without execve) in the bugpoint tool is what
prevents that tool from working on win32. We need to abstract out the
notion of forking/parallelism in the same process and fake it with
threads or something in win32. Either that or redesign bugpoint a
little.

6. Not much has been done with the test suites on win32. There are 3
test suites: llvm/test/Features, llvm/test/Regression, and the llvm-test
project (separate CVS repository). Features and Regressions are
small/light/fast tests that cover basic functionality and problems we've
previously run into. I'm currently working on getting the llvm-test
suite to pass on Cygwin. I don't know if anyone's looked into getting
these tests to run with win32 native executables. The testing harness is
pretty unix-centric but it might be possible to cajole them into running
under Cygwin but using win32 built executables (as opposed to Cygwin
executables).

7. Pretty much everything else is already portable.

I'd talk to Jeff Cohen about his efforts with win32 as he's been the
primary developer on that.

Thanks, Aaron.

Reid.

6

Aaron Gray wrote:-

Hi,

I have built yesterdays CVS download of LLVM on Whidbey (Microsoft Visual Studio 2005).

LLVM built with trivial mods due to VS strictness compared to GCC. Basically there are missing return statement/values where Abort() is called, I replaced these with dummy constructors to get them to compile.

Sounds like GCC is smart enough to realise it doesn't return?

Neil.

7

From: Reid Spencer Date: Wed, 16 Feb 2005 20:38:50 -0800

6. Not much has been done with the test suites on win32. There are 3
test suites: llvm/test/Features, llvm/test/Regression, and the llvm-test
project (separate CVS repository). Features and Regressions are
small/light/fast tests that cover basic functionality and problems we've
previously run into. I'm currently working on getting the llvm-test
suite to pass on Cygwin. I don't know if anyone's looked into getting
these tests to run with win32 native executables. The testing harness is
pretty unix-centric but it might be possible to cajole them into running
under Cygwin but using win32 built executables (as opposed to Cygwin
executables).

I will look into this subject later on the mingw platform, i.e. trying to get dejagnu to work on the platform. No one seems to have done that yet on mingw.

Henrik.

8

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

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.

Neil Booth wrote:

9

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.

I have ordered a copy of Visual Studio 2003 now anyway so can work with that.

The CVS changes may probably want 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.

Sorry again for any confusion caused.

Aaron

10

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.

11

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

12

Aaron, don't worry about it, there is no confusion. We occasionally have to work around bugs in other compilers (including VC7.1), so this sort of patch is no different. As long as the changes required to get Whidbey working do not adversely affect other users/compilers, I don't have any problem with them. Again, thanks for the patch!

The one thing to watch out for though is that other uses of abort will probably creep into the compiler over time, so we might accidentally break Whidbey support. Jeff has experienced this with VC7.1 support getting minorly broken from time to time as well.

-Chris

13

Another option is just to extend LLC to directly emit Win32 OBJ files directly, so you don't need an assembler...

-Chris

14

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

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

15

It does indeed. You can even use mingw/g++ to cross-compile Windows exe under
Linux.

16

Chris Lattner wrote:

17

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:

18

I'm not sure you understand the problem.

I wouldn't be surprised :slight_smile:

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?

AFAIK, mingw _does_ link against the MS runtime.

mingw32 allows "one to produce native Windows programs that do not rely on any
3rd-party C runtime DLLs." ^1

mingw32 "uses Microsoft's runtime (either CRTDLL.DLL or MSVCRT.DLL) for all
services, and you get no more and no less than what Microsoft provides." ^2

1) http://www.mingw.org/
2) http://www.xraylith.wisc.edu/~khan/software/gnu-win32/x86-win32-ports.html

19

I'm afraid that still does not completely answer the question. I'll accept that it will work for C programs, given what you quote. It says nothing about C++ however. That's a different animal entirely. g++ mangles names in a completely different fashion than VC++. Does mingw use VC++ style mangling? g++ processes exceptions in a completely different fashion than VC++. I think you get the picture :slight_smile:

Adam Treat wrote:

20

The answer to this FAQ question implies the answer is no. It relies on g++ header files and libraries for STL support. Microsoft does not implement STL using "libstdc++"; g++ does.

Why is my C++ binary so large?

C++ programs using the Standard Template Library (ie/ #include <iostream>) cause a large part of the library to be statically linked into the binary. The need to statically link the stdc++ into the binary is two fold. First MSVCRT.dll does not contain C++ stdlib constructs. Second the legal implications of generating a libstdc++.dll are restricted by the licensing associated with the library.

Jeff Cohen wrote: