migrate to the LLVM toolchain

[thestinger]

Especially on Windows, we shouldn't have a dependency on either MinGW or MSVC++. LLVM's toolchain is not entirely mature, but they do have C/C++ working on Windows independently of other toolchains.

http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

• libgcc -> compiler-rt (required to fix some other bugs like 64-bit signed/unsigned overflow checked multiplication unavailable on 32-bit #8449) (closed by compiler-rt #12027)
• libsupc++ (exception support) -> libc++abi (may still have a dependency on libgcc on some platforms) (closed by Remove C++ dependencies #11121)
• gcc/ld -> lld
• ship clang with snapshot to build the C runtime bits, and drop the C++ bits (to avoid needing to build libc++ as a replacement for libstdc++ too) (closed by 508b7b9)

[brson]

nominating. At the least we need to switch our linker away from gcc to something else on windows in order to get away from requiring a mingw install just to run rustc.

[catamorphism]

1.0, high. Windows needs to work.

[alexcrichton]

I was doing some testing with this recently, and here's all the troubles I ran into:

• We'd have to have a submodule for clang, compiler-rt, and lld (not that bad)
• It looks like lld will only build with cmake (we'd have to introduce this dependency)
• I could not get compiler-rt when not using cmake (it hit a build error)
• I could not get compiler-rt to build when using cmake (find . -name '*compiler-rt*' came up with nothing interesting)
• I could not get lld to link a hello-world binary on darwin (lots of complaints about undefined symbols)
• I could build libcxxabi from LLVM on osx/linux, but it would probably require that we build clang as well. It requires a fairly new C++ compiler (above llvm 3.2 I think?) and some distros are still lagging behind on 3.0 as the official clang version. OSX has a new-enough clang by default, and it appears that freebsd does as well, so we could perhaps do some easy version detection to figure out whether we need to build clang or not.
• On OSX, we can build libunwind out of the folder in libcxxabi (yay!)
• On linux, it looks like we may be able to rely on libgcc_eh.a for _Unwind_Resume and friends

I have done little testing on windows, but I believe that the story will be very similar except for figuring out where _Unwind_Resume comes from. I'm also probably just not doing anything correctly, but right now I'm having a hard time of figuring out what...

[vadimcn]

FWIW, I've checked out a recent Windows build of lld (from llvm.org/builds), and it could not link objects produced by mingw:

• in "gnu" mode it did not recognize the file format of COFF .obj files.
• in "link" mode it asserted about not being able to process "IMAGE_SYM_DEBUG" section.

[vadimcn]

@brson, @alexcrichton: Looks like I've succeeded in compiling compiler-rt on mingw. (I hope other platforms will be easier because it was actually intended to be built there). This opens up 2 possible venues for further work:

• migration of rustc dependencies from libgcc to compiler-rt,
• using Address Sanitizer instead of (or in addition to) Valgrind.
  Which one do you consider more important?

[vadimcn]

cc #749

[alexcrichton]

Interesting! I think there's no question about moving to compiler-rt instead of libgcc. I'd be more than willing to help you integrate it with the current build system!

How does using compiler-rt instead of libgcc relate to valgrind vs address sanitizer?

[vadimcn]

Address sanitizer runtime is a part of compiler-rt. Rust could use compiler-rt just for that, for starters.
Also, please note that we'll still be depending on libgcc for the unwinding library, at least on windows.

[alexcrichton]

Hm, if we could not compile the asan part of compiler-rt for now I think that may be the best way to go.

Depending on libgcc is fine for unwinding, moving to compiler-rt is the motivation for fixing bugs like #8449.

[vadimcn]

asan compiles just fine actually. But using it will require some plumbing in rustc, such as emitting sanitize_address attributes on functions and running asan pass in llvm.

ok I'll look into migration from libgcc.