Building LLVM under Mingw. Part I: tools-only

Hello, Everyone.

Now I have some spare time and I've decided to build LLVM on Mingw.
I've grab the latest 1.7 release (not CVS snapshot). Here are some
issues fixed during the build. Now I'm preparing gcc build. So, I
think, there will some other "parts"

1. Prerequisites

1.1 GCC 3.4.5 from mingw.org site.
$ gcc --version
gcc.exe (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

1.2. Binutils 2.16.91 20060119 from mingw.org site.
$ ld --version
GNU ld version 2.16.91 20060119
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.

1.3. GNU Make 3.79.1 taken from msys distribution.

$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug-make@gnu.org>.

1.4. Bison 1.875 from GNUWin32 project

$ bison --version
bison (GNU Bison) 1.875

1.5 Flex 2.5.4 from GNUWin32 project.

2. Patching.

2.1. Libraries
Add "LIBS+= -lpsapi -limagehlp" to each makefile (AFTER
Makefile.common inclusion) building some tool (burg, tablegen, ll*),
since gcc doesn't support vcpp style #pragma's of form:
#pragma comment(lib, "dbghelp.lib")

2.2 CopyFile
Patch lib/System/Win32/Path.inc in such way, that declaration of
CopyFile will look like:

void
CopyFile(const sys::Path &Dest, const sys::Path &Src) {

2.3 X86 stuff
Patch lib/Target/X86/X86SubTarget.cpp & X86JITInfo.cpp in such way:

X86SubTarget.cpp:
#if defined(__CYGWIN__) || defined(__MINGW32__)
    TargetType = isCygwin;
#elif defined(__APPLE__)
    TargetType = isDarwin;
#elif defined(_WIN32)
    TargetType = isWindows;
#endif

X86JITInfo.cpp:
#if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__)
    ".globl _X86CompilationCallback\n"
  "_X86CompilationCallback:\n"
#else
...
#if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__)
    "call _X86CompilationCallback2\n"
#else

2.4 alarm()'s in Sparc backend

Remove from lib/Target/SparcV9/ModuloScheduling/ModuloScheduling.cpp
all calls to alarm().

3. That's all

This should be enough to configure and build LLVM in tools-only mode.
Unfortunately, ld crashed while building llc, I'm currently
investigating this problem. Also, I'm working on building gcc backend.
The results will follow.

Anton Korobeynikov wrote:

1.4. Bison 1.875 from GNUWin32 project

$ bison --version
bison (GNU Bison) 1.875
  
Bison 1.875 is known to have problems building LLVM. Please upgrade to a newer version (at least 1.875d). The current version is 2.1.

Hello, Jeff.

You wrote Saturday, April 29, 2006, 7:35:46 PM:

Bison 1.875 is known to have problems building LLVM. Please upgrade to
a newer version (at least 1.875d). The current version is 2.1.

Hmm.. I haven't found any problem building LLVM with that bison. :wink:
The problem, when ld crashed compiling llc is much more serious. It
seems to be linker bug.

Anton Korobeynikov wrote:

2. Patching.

2.1. Libraries
Add "LIBS+= -lpsapi -limagehlp" to each makefile (AFTER
Makefile.common inclusion) building some tool (burg, tablegen, ll*),
since gcc doesn't support vcpp style #pragma's of form:
#pragma comment(lib, "dbghelp.lib")
  

I'd fix this, but I don't touch Unix build stuff :slight_smile: I'll let Reid handle this one. I suspect he'll prefer to fix Makefile.common rather than each individual makefile. And dbghelp.lib really ought to be used. imagehlp is very, very obsolete and vanishes on 64-bit Windows. Yes, I know mingw doesn't support dbghelp. I can still rant about it :slight_smile:

2.2 CopyFile
Patch lib/System/Win32/Path.inc in such way, that declaration of
CopyFile will look like:

void
CopyFile(const sys::Path &Dest, const sys::Path &Src) {
  

Applied.

2.3 X86 stuff
Patch lib/Target/X86/X86SubTarget.cpp & X86JITInfo.cpp in such way:

X86SubTarget.cpp:
#if defined(__CYGWIN__) || defined(__MINGW32__)
    TargetType = isCygwin;
#elif defined(__APPLE__)
    TargetType = isDarwin;
#elif defined(_WIN32)
    TargetType = isWindows;
#endif

This is what's already there. What changed?

X86JITInfo.cpp:
#if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__)
    ".globl _X86CompilationCallback\n"
  "_X86CompilationCallback:\n"
#else
...
#if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__)
    "call _X86CompilationCallback2\n"
#else

Applied.

2.4 alarm()'s in Sparc backend

Remove from lib/Target/SparcV9/ModuloScheduling/ModuloScheduling.cpp
all calls to alarm().
  

This code no longer exists post-1.7.

Anton Korobeynikov wrote:

Hello, Jeff.

You wrote Saturday, April 29, 2006, 7:35:46 PM:

> Bison 1.875 is known to have problems building LLVM. Please upgrade to
> a newer version (at least 1.875d). The current version is 2.1.
Hmm.. I haven't found any problem building LLVM with that bison. :wink:
The problem, when ld crashed compiling llc is much more serious. It
seems to be linker bug.

You will. You haven't gotten that far yet. It shows up as a crash running gccas.

As for ld crashing, I have no suggestions.

Hello, Jeff.

You wrote Saturday, April 29, 2006, 10:45:02 PM:

Yes, I know mingw doesn't support dbghelp. I can still rant about it :slight_smile:

:wink: Well. Maybe this library will be included in some next versions of
mingw's win32api package. Anyway, we can make such library just
"on-fly" from the corresponding .dll.

This is what's already there. What changed?

Maybe this was my bug while trying to remeber, what I've patched :wink:

Hello, Jeff.

You wrote Saturday, April 29, 2006, 10:50:08 PM:

You will. You haven't gotten that far yet. It shows up as a crash
running gccas.

Ok. Switched to 2.1

As for ld crashing, I have no suggestions.

It seems to be bug in bfd/cofflink.c file of libbfd. I can even name the
function, where weird thing happens. But it's out of my possibilities
to debug this now.

Now I'm trying to build LLVM without --enable-optimized option and see,
what will happen.

Hi,

The Cygwin LLVM release (OPTIMIZED_ENABLED) version triggers a bug in LD (BFD binutils) this may well be common to MinGW as well.

Aaron

Hello, Aaron.

You wrote Sunday, April 30, 2006, 12:01:10 AM:

The Cygwin LLVM release (OPTIMIZED_ENABLED) version triggers a bug in LD
(BFD binutils) this may well be common to MinGW as well.

Seems so, since debug version of llc.exe builds smoothly. Do you have
more information about this issue?

Hello, Aaron.

You wrote Sunday, April 30, 2006, 12:01:10 AM:

> The Cygwin LLVM release (OPTIMIZED_ENABLED) version triggers a bug in LD
> (BFD binutils) this may well be common to MinGW as well.
Seems so, since debug version of llc.exe builds smoothly. Do you have
more information about this issue?

Anton,

It was about a year ago now so I cannot remember the precise details.

I traced the code its easy enough to find the error message in the bfd code.

It was about three of the source units causing the error.

Either GCC is producing erronous object modules or the bfd is miss reading the data in them.

Sorry I cannot really be of much help,

Aaron

Hello, Aaron.

You wrote Sunday, April 30, 2006, 1:34:16 AM:

I traced the code its easy enough to find the error message in the bfd code.

Hmm. This seems to be another bug. I've just got access to null
address in linker and it's crashed. No error message at all.

BTW: I've also had to make this change when building tools.
(I'm building right now and noticed that it doesn't come up anymore, maybe
someone checked it in in the last week or so)

So I've been continuing to work on building LLVM under Mingw.
I've made progress on the CFE build and will perhaps post my results later
today.

Anyway, I just did the tools-only part and had a few questions/comments

First of all, with regards to my setup. I have the following in my notes:

   These are the files I downloaded:
      MinGW-3.1.0-1.exe
      MSYS-1.0.11-2004.04.30-1.exe
      msysDTK-1.0.1.exe (for CVS)
      gcc-core-3.4.2-20040916-1.tar.gz
      gcc-g++-3.4.2-20040916-1.tar.gz
      binutils-2.16.91-20060119-1.tar.gz

      WARNING: llvm-tools wouldn't link with this version of gcc:
            gcc-core-3.4.5-20060117-1.tar.gz
      gcc-g++-3.4.5-200600117-1.tar.gz

It seems like I had problems with gcc version 3.4.5. But I guess others
didn't see these problems? (I'll have to try it again).

Previously, I was patching X86JITInfo.cpp like this:

   NOTE: I couldn't get llc to link until I made the following change (CVS
diff):
   Greg Pettyjohn@GREGLAPTOP ~/llvm/lib/Target/X86
   $ cvs diff X86JITInfo.cppIndex: X86JITInfo.cpp