Things to do in order to integrate clang/llvm with the base system.

Contents

  1. Things to do in order to integrate clang/llvm with the base system.
  2. Goal
    1. Things we need this for
    2. Pleasant side effects
  3. Testing
  4. TODO
    1. Things to do
      1. boot monitor changes
        1. assembly (antoine)
        2. C
      2. pkgsrc package of clang/llvm (beng - done)
      3. change clang/llvm not to use /usr/gnu gcc path (beng - done)
      4. use pkgsrc toolchain (beng - done)
      5. create and use system libraries in /usr/lib instead of /usr/gnu/lib (beng - done)
    2. Problems found
      1. gcc/llvm ABI incompatabilities
        1. hard-fp (beng - done)
      2. gcc dependency: lib and pkgsrc (beng - done)
      3. misc bugs
        1. weird invocation bug
        2. unaligned movaps (beng - fixed)
      4. Crashes to debug (beng - DONE - when generating elf, then converting to aout, this works!)
  5. TODO once we're done with that
    1. adapt buildsystem to single compiler
    2. adapt system to single compiler
    3. adapt release script
  6. It would be nice if

Goal

Things we need this for

Pleasant side effects

Testing

First, it has to work properly; second, its libraries have to work properly with gcc-compiled code (i.e. packages that use the base system libraries).

Build and test all minix base system with clang, test compiling packages with gcc with clang-format libraries, make sure minix and package tests pass, etc.

TODO

Things to do

boot monitor changes

assembly (antoine)

The boot monitor assembly is written in Xenix syntax and has to be converted to gas (ATT).

This also requires asmconv/gas2ack to be updated to translate 16-bit code, in order to allow ACK to continue operating.

This also requires installboot and autopart to be updated to deal with non-ACK binaries (masterboot.)

Status: mostly done, modulo testing

C

The C code executes in a 16-bit code segment; can llvm generate suitable code, directly or through trickery (e.g. tell assembler to generate 32-bit prefix for every instruction)? See this gas manual page and some osdev wiki page i found this on ;).

Switching to 32-bit protected mode (and switching back to real mode for bios calls) might be a solution too, but pretty heavy change.

pkgsrc package of clang/llvm (beng - done)

There's currently only a bigports port of clang/llvm, which is obsolete now. It has to become a pkgsrc package.

Status: done, modulo testing

change clang/llvm not to use /usr/gnu gcc path (beng - done)

There are still places in the clang/llvm codebase where /usr/gnu/... is hardcoded, e.g. AddGnuCPlusPlusIncludePaths("/usr/gnu/include/c++/4.4.3", .. in tools/clang/lib/Frontend/InitHeaderSearch.cpp.

use pkgsrc toolchain (beng - done)

Currently clang+llvm configured to use gar and gas, but we have since switched the gcc/clang toolchain names to ar and as.

create and use system libraries in /usr/lib instead of /usr/gnu/lib (beng - done)

Currently all gcc/clang format libraries are there. Which is wonderful, except that the name is bogus now (it's not just gcc) and it's the wrong location for our standard base system libraries. So this should be renamed.

My (ben's) suggestion is to take /usr/lib; because

When to do this though? During the transition perhaps, to avoid more noise later.

Problems found

gcc/llvm ABI incompatabilities

hard-fp (beng - done)

llvm generates fpu code by default. we want to switch to this too, both to use the hardware and simplify porting and crosscompiling. So gcc has to be reconfigured to generate hardware-fp code by default. This isn't entirely trivial as gcc will fail to build halfway through if this default is simply changed, as the system libraries will still require soft-fp support in order to compile things. The next step is to try to recompile all of the libraries in hardware-fp mode (using gcc command line switch), then compile a new gcc that does hardware-fp mode by default with those.

This is an abi incompatability too, as doubles are returned differently in soft- and hard- fp mode in gcc.

gcc dependency: lib and pkgsrc (beng - done)

clang seems to need -lgcc for 64bit arithmetic. WTF.

also for some goddamn reason gcc gets installed if you install clang with pkgsrc. that dependency has to be broken too.

presumably (!!) the compiler-rt package from llvm will fix this (!)

compiler-rt requires:

misc bugs

weird invocation bug

# /usr/pkg/bin/clang -o hello hello.c
error: unable to execute command:  is not executable
error: clang frontend command failed due to signal 1 (use -v to see invocation)

This doesn't happen if clang is invoked without a full pathname..

unaligned movaps (beng - fixed)

This code: 

double func(unsigned long long k)
{
        return 2.0 + k;
}

Generates this code: 

00002000 <_func>:
    2000:       55                      push   %ebp
    2001:       89 e5                   mov    %esp,%ebp
    2003:       83 e4 f0                and    $0xfffffff0,%esp
    2006:       83 ec 30                sub    $0x30,%esp
    2009:       8b 45 0c                mov    0xc(%ebp),%eax
    200c:       8b 4d 08                mov    0x8(%ebp),%ecx
    200f:       89 4c 24 20             mov    %ecx,0x20(%esp)
    2013:       66 0f 6e c1             movd   %ecx,%xmm0
    2017:       89 44 24 24             mov    %eax,0x24(%esp)
    201b:       66 0f 6e c8             movd   %eax,%xmm1
    201f:       66 0f 62 c8             punpckldq %xmm0,%xmm1
    2023:       0f 28 05 e8 23 00 00    movaps 0x23e8,%xmm0

The program segfaults on the movaps, presumably because it isn't aligned to a 16-byte boundary. This seems to be this bug: http://www.mail-archive.com/llvmbugs@cs.uiuc.edu/msg08919.html So hopefully tracking the llvm release branch will fix this. (Yes it did!)

Crashes to debug (beng - DONE - when generating elf, then converting to aout, this works!)

Some programs crash when compiled with clang, most noticeably: make. Presumably this is an ABI problem but not sure.. it also happens if all the libraries are compiled with clang.

TODO once we're done with that

adapt buildsystem to single compiler

Throw out all special cases and special treatment for two different compilers. I'm thinking of

adapt system to single compiler

Throw out all the ACK-related utilities. The following list is not limitative:

Also to considered are some utilities which need improvements or conversion to support clang/gcc format, like:

adapt release script

Don't install ack any more; no more bootstrapping of /usr/lib from build machine, just install the clang package, and bootstrap everything from that.

It would be nice if

clang were faster than gcc :(

MinixWiki: ClangIntegration (last edited 2011-06-09 12:03:46 by BenGras)