Table of Contents
Toolchain working group
Action items
discussion
Toolchain working group
Action items
bdrewery to change –sysroot (always pass)
r304681
jonathan
to add LLVM instrumentation rules to build system
someone (?) to test use of absolute paths in build
someone (?) to test turning on BUILD_SHARED_LIBS
kib to profile Clang startup with BUILD_SHARED_LIBS
theraven to find CMake option for building LLVM libs as single .so
anything about arm64 linker package building?
bdrewery to continue working on cross-
OS
building
emaste to work on LLDB for kernel (based on previous GSoC project)
discussion
build systems
proposal (Bryan): always pass –sysroot, even to bootstrapped cross-compiler
Q: stop defining sysroot, etc., in cross-compiler?
Q: use absolute paths for build failure reproducibility?
reproduciblity: already need to give up on paths
linking: linker might not be able to handle that many absolute pathnames (command line args too long)
brooks: worthwhile experiment, may not work for, e.g., lib32
LLVM
BUILD_SHARED_LIBS?
sometimes required to build a Debug Clang on machines with 4GB or 8GB of RAM
some LLVM tools (e.g., lldb) broken with 2
Apple has an option to build one big LLVM shared library rather than lots of tiny ones
if we fix BUILD_SHARED_LIBS for lldb, we can set up a build bot and others might stop breaking it
build bots do exist but could stand some improvement
we don't want to slow the build down more
is it still useful to have a static build toolchain?
might need to profile this 20s startup time that brooks has observed (RTLD? FS cache?)
job for kib
theraven thinks there might be a CMake option to build a single .so
instrumentation
/usr/bin/opt?
goes hand-in-hand with BUILD_SHARED_LIBS!
might be tough to support opt, etc., for five years
non-default package for packaged base
emaste would like llvm-objdump, etc.
Linkers
lld can link userland on x86_64 (except some funny boot bits), non-booting kernel
linker script support getting in good shape
will likely be viable for FreeBSD 12
self-hosting on arm64, 32b “getting there” (“past hello world”)
not particularly close on PowerPC, MIPS: might require external toolchain for 12
improvements/benefits
ten years of better linking
LTO
requirements
version scripts require wildcards on demangled C++ symbols (everything else should be fine)
linker scripts (mainly for the kernel)
LTO is a nice-to-have, not a requirement, but a *relly nice* to-have.
there is an LLVM meta-bug for building FreeBSD
11 for arm64 will ship without a base system linker (old GNU ld doesn't support arm64!)
will need to ship packages
there are machines to build these packages, but there are… issues (firmware, etc.)
Cross-
OS
builds
hardest part: bootstrapping system to have FreeBSD-like environment (including a libcompat)
two problems
need a C++11 compiler (which most modern Linux distros have, but RHEL is a bit out of date)
portability
need BSD stuff in libc
there is a portable version of mtree
need a portable crunchgen (or not use crunchgen)
NetBSD has this kind of thing
cperciva: could we use NetBSD as our compatibility layer? :)
additional problems
UFS
can't read the filesystem you just built
one approach: dump/restore + libarchive
another approach: FUSE
another approach: rump kernel
need a bi-endian UFS
“make tools” for cross-
OS
building can be huge, manual and explicit
compat should still be optimized for the case of building on FreeBSD
LLDB
in base for 11 (amd64, arm64, not i386)
Missing single step on arm32, horrible user experience
missing functionality:
we don't parse FP registers in core files
gdbserver
on Mac
OS
X and Linux, all debugging is remote debugging
Facebook has DS2, which may be a useful target for FreeBSD inclusion once complete
Keeping lldb/gdb-server separate makes debugging threaded code cleaner
kernel support doesn't exist yet: there was a GSoC project, emaste to work on it
De-
GPL
libunwind enabled in -CURRENT
lack of tools for debugging libunwind: they don't understand EHABI
binutils: still install as, ld, and objdump
as: no replacement
can just turn it off for amd64
11 ports failed without a /usr/bin/as
consensus: force failing ports to use binutils
some parts of i386 use /usr/bin/as rather than Clang
might be able to switch to .S
mips64
upstream binutils doesn't understand freebsd-mips64
project: extract base system's binutils into separate repository, make port
devel-binutils-mips64 as-is doesn't work
sparc64
no actual relationship to currently-shipping hardware
last Ultra3
EOL
'ed by Sun in 2008
plan
emaste to turn of /usr/bin/as for amd64, arm64
incrementally migrate to external binutils
expunge GNU as
lld will become ld
llvm-objdump
caught up (sort of) to GNU objdump about a week ago
different command-line arguments, slightly less polished
lack of SafeStack, libssp
possibly too broken to care about
diff, rcs
replaced ident this week
there is an OpenRCS
strategy: once rcs is all that's left, then we can remove it
dtc
theraven's dtc currently disabled
doesn't always support /include
lots of bugs when run over arm dts files
libomp
llvm's implementation usable (the one Intel open-sourced)
discussion ongoing about port vs base
possible consensus: use ports
minor blockers
will need to build it twice
currently built as part of the LLVM port, but users might object to installing the LLVM static mega-package (1
GB
)
libcov
gperf
build tool for GCC that creates perfect hashes
grep: bsdgrep
Apple has some grep fixes
fairly easy to crash it
groff
has been removed, man pages need updating
LLVM's test-suite needs groff (but it's in ports)
libgcc
not using compiler-rt for the shared version
we should try to keep it up-to-date with modern libgcc (some GNU tools need this)
readline
only gdb uses this
LLVM fat binaries
Leave LLVM IR into the objects, so we can do later optimisations
Research quality for most tools that can consume it, so maybe not priority now
Nevertheless, interesting to have the option to, so further experimentation can happen
Single-architecture bitcode, not for cross-architecture late generation
May be hard to hold on LLVM to micro-optimise, since it defaults to the most common sub-arch not the minimal one
sanitizers
modularization
QEMU
Historical