LLVM Microconference Notes

Welcome to Linux Plumbers Conference 2015

The structure will be short introductions to an issue or topic followed by a discussion with the audience.

A limit of 3 slides per presentation is enforced to ensure focus and allocate enough time for discussions.

Please use this etherpad to take notes. Microconf leaders will be giving a TWO MINUTE summary of their microconference during the Friday afternoon closing session.

Please remember there is no video this year, so your notes are the only record of your microconference.

Miniconf leaders: Please remember to take note of the approximate number of attendees in your session(s).  ~28 much of the time

1. Wifi SSID: Exhibitor Internet Login: linux Password: seattle

SCHEDULE

• •                  Done ? Final spurt ? - Compiling the Linux Kernel with clang on x86          

• •                 Beyond traditional compilation           

Kostya Serebryany

• • • "One compiler to compile them all"
    • Monopoly in the compiler - why break the monopoly ... ex:
      • ASan (Address Sanitizer)
      • TSan (Thread Sanitizer)
      • MSan (Memory Sanitizer)
      • UBSan (Undefined behaviour Sanitizer)
      • -> new Features
    • Kernel/GLibc/Distros tailored to use one compiler
      • lots of hacks required
      • distro integration hacky and hard to maintain
    • Features ported, but not all (thanks to competition)
    • Coverage and hardening can improve code quality further (beyond Sanitizers)
      • New:
        • -fsanitize-coverage
        • libFuzzer
      • Beyond fuzzing, code hardning also needed
        • -fsanitize=cfi-vcall -flto
      • Safestack (buffer-overflow protection)
    • Goal - support "another" compiler
      • setup contiguous builds,
      • expand use of Sanitizers, fuzziing, hardening to enhance our code

• •                 BPF in LLVM and kernel          
  •   Alexei Starovoitov
    • classic BPF -> extended BPF
    • BPF backend in LLVM since 02/2015 (will be in 3.7)
    • Also in gcc, but clang backend was much easier to implement
      • LLVM backend BPF
        • Integrated Assembler generates ELF
        • JIT mode supported (in-memory .c to in-memory bpf)
          • -> used in tracing
          • faster than dtrace
        • bpf+perf
        • BPF compiler (hybrid between python and c)
        • bcc tools (performance observation tools)
          • https://github.com/iovisor/bcc

• •                
  •   
  •                 Rethinking the core OS in 2015          

  • Bernhard Rosenkraenzer

    •   Binutils - actually no replacement (lldb and others still WIP)
    • Assembler: gas (still llvm integrated-as cannot deal with all constructs)
    • tools like "nm" break once we derive from the "standard" .o (e.g. gcc/clang with lto)
      • workaround: nm wrapper
    • llvm as primary compiler (e.g. openmandriva 3 almost fully built with clan 3.7)
      • not too problematic (usually bad code and non-standard extensions)
      • still libgcc libgcc_s libatomic and others (and libstdc++)
      • that still means you also need a gcc cross-compiler for every arch you support
      • clang __GNUC__ returns 4.2.1 (historical reasons) actually closer to 4.9
        • question: what about flag to set version clang reports ??
      • Do not use for compatibility:
        • nested functions
        • Variable length arrays in structs
        • Variable length arrays of non-POD types
        • Empty structs
        • Array subscripts of type "char"
        • Reserved words
        • no c89-isms or c++98-isms 
      • Interesting pugs found in the transition
    • glibc <-> musl 
      • but watch out for binary compatibility
      • support needs patch in clang (still some hardcodings e.g. dynamic linker)
    • libstdc++ <-> LLVM libc++
      • ~50% smaller 
    • crosscompiling
      • well "should" make things easier in llvm/clang, but we still need binutils and gcc-based compiler for the libs :/
      • --sysroot in clang still needs work (but wrappers help out here)

• •                 Can Linux live without GNU toolchain?          

  • Khem Raj

    • embedded toolchain (non-android)  clang/musl-based using YoctoProject/OpenEmbedded
    • the toolchain build sequence is complex (chicken-egg issue  gcc<-> glibc)
    • new: clang builds side-by-side with gcc (like a additional cross-compiler), compiler chosen by package (e.g. built-time requirement)
    • goal is to actually replace the old gcc bootstrap cycle with gcc and to a native clang/musl/compiler-rt/libc++ toolchain
    • clang+musl right now
      • still uses gcc runtime
      • uses compiler-rt (replace libgcc)
      • uses libc++ (replace libstdc++)
    • arch support (armv7a, aarch64, x86)
    •   Limitations:
      • packages not fixed to compile with clang
      • building SDKs not yet supported (alongside gcc)
      • musl-based SDKs don't have all tools, yet
    • Layers:
      • meta-musl
      • meta-clang
  •                 Limitations of various linkers in clang based toolchains          

  • Mark Charlebois

    • linkers in the px4 project
      • partial linking (with -Ur)  (ld.bfd only!)
      • different combination of linker / compiler (binutils+clang, mclinker+clang ...)
      • linkerscript needed to generated firmware (px4 has quite simple file)
  •   
  •                 Using clang static analyzer with the Linux kernel code          
    • also in tool session -> bumped to later