How to build Windows Itanium applications.

Introduction

This document contains information describing how to create a Windows Itanium toolchain.

Windows Itanium allows you to deploy Itanium C++ ABI applications on top of the MS VS CRT. This environment can use the Windows SDK headers directly and does not required additional headers or additional runtime machinery (such as is used by mingw).

Windows Itanium Stack:

  • Uses the Itanium C++ abi.

  • libc++.

  • libc++-abi.

  • libunwind.

  • The MS VS CRT.

  • Is compatible with MS Windows SDK include headers.

  • COFF/PE file format.

  • LLD

Note: compiler-rt is not used. This functionality is supplied by the MS VCRT.

Prerequisites

  • The MS SDK is installed as part of MS Visual Studio.

  • Clang with support for the windows-itanium triple.

  • COFF LLD with support for the -autoimport switch.

Known issues:

SJLJ exceptions, “-fsjlj-exceptions”, are the only currently supported model.

link.exe (the MS linker) is unsuitable as it doesn’t support auto-importing which is currently required to link correctly. However, if that limitation is removed then there are no other known issues with using link.exe.

Currently, there is a lack of a usable Windows compiler driver for Windows Itanium. A reasonable work-around is to build clang with a windows-msvc default target and then override the triple with e.g. “-Xclang -triple -Xclang x86_64-unknown-windows-itanium”. The linker can be specified with: “-fuse-ld=lld”.

In the Itanium C++ ABI the first member of an object is a pointer to the vtable for its class. The vtable is often emitted into the object file with the key function and must be imported for classes marked dllimport. The pointers must be globally unique. Unfortunately, the COFF/PE file format does not provide a mechanism to store a runtime address from another DLL into this pointer (although runtime addresses are patched into the IAT). Therefore, the compiler must emit some code, that runs after IAT patching but before anything that might use the vtable pointers, and sets the vtable pointer to the address from the IAT. For the special case of the references to vtables for __cxxabiv1::__class_type_info from typeinto objects there is no declaration available to the compiler so this can’t be done. To allow programs to link we currently rely on the -auto-import switch in LLD to auto-import references to __cxxabiv1::__class_type_info pointers (see: https://reviews.llvm.org/D43184 for a related discussion). This allows for linking; but, code that actually uses such fields will not work as they these will not be fixed up at runtime. See _pei386_runtime_relocator which handles the runtime component of the autoimporting scheme used for mingw and comments in https://reviews.llvm.org/D43184 and https://reviews.llvm.org/D89518 for more.

Assembling a Toolchain:

The procedure is:

# Build an LLVM toolchain with support for Windows Itanium. # Use the toolchain from step 1. to build libc++, libc++abi, and libunwind.

It is also possible to cross-compile from Linux.

To build the libraries in step 2, refer to the libc++ documentation.

The next section discuss the salient options and modifications required for building and installing the libraries. This assumes that we are building libunwind and libc++ as DLLs and statically linking libc++abi into libc++. Other build configurations are possible, but they are not discussed here.

Common CMake configuration options:

  • -D_LIBCPP_ABI_FORCE_ITANIUM'

Tell the libc++ headers that the Itanium C++ ABI is being used.

  • -DCMAKE_C_FLAGS="-lmsvcrt -llegacy_stdio_definitions -D_NO_CRT_STDIO_INLINE"

Supply CRT definitions including stdio definitions that have been removed from the MS VS CRT. We don’t want the stdio functions declared inline as they will cause multiple definition errors when the same symbols are pulled in from legacy_stdio_definitions.ib.

  • -DCMAKE_INSTALL_PREFIX=<install path>

Where to install the library and headers.

Building libunwind:

  • -DLIBUNWIND_ENABLE_SHARED=ON

  • -DLIBUNWIND_ENABLE_STATIC=OFF

libunwind can be built as a DLL. It is not dependent on other projects.

  • -DLIBUNWIND_USE_COMPILER_RT=OFF

We use the MS runtime.

The CMake files will need to be edited to prevent them adding GNU specific libraries to the link line.

Building libc++abi:

  • -DLIBCXXABI_ENABLE_SHARED=OFF

  • -DLIBCXXABI_ENABLE_STATIC=ON

  • -DLIBCXX_ENABLE_SHARED=ON'

  • -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON

To break the symbol dependency between libc++abi and libc++ we build libc++abi as a static library and then statically link it into the libc++ DLL. This necessitates setting the CMake file to ensure that the visibility macros (which expand to dllexport/import) are expanded as they will be needed when creating the final libc++ DLL later, see: https://reviews.llvm.org/D90021.

  • -DLIBCXXABI_LIBCXX_INCLUDES=<path to libcxx>/include

Where to find the libc++ headers

Building libc++:

  • -DLIBCXX_ENABLE_SHARED=ON

  • -DLIBCXX_ENABLE_STATIC=OFF

We build libc++ as a DLL and statically link libc++abi into it.

  • -DLIBCXX_INSTALL_HEADERS=ON

Install the headers.

  • -DLIBCXX_USE_COMPILER_RT=OFF

We use the MS runtime.

  • -DLIBCXX_HAS_WIN32_THREAD_API=ON

Windows Itanium does not offer a POSIX-like layer over WIN32.

  • -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON

  • -DLIBCXX_CXX_ABI=libcxxabi

  • -DLIBCXX_CXX_ABI_INCLUDE_PATHS=<libcxxabi src path>/include

  • -DLIBCXX_CXX_ABI_LIBRARY_PATH=<libcxxabi build path>/lib

Use the static libc++abi library built earlier.

  • -DLIBCXX_NO_VCRUNTIME=ON

Remove any dependency on the VC runtime - we need libc++abi to supply the C++ runtime.

  • -DCMAKE_C_FLAGS=<path to installed unwind.lib>

As we are statically linking against libcxxabi we need to link against the unwind import library to resolve unwind references from the libcxxabi objects.

  • -DCMAKE_C_FLAGS+=' -UCLOCK_REALTIME'

Prevent the inclusion of sys/time that MS doesn’t provide.

Notes:

An example build recipe is available here: https://reviews.llvm.org/D88124