Resource: LCA14 Name: LCA14-304: Building Android with CLANG for ARM v7 and v8 platforms Date: 05-03-2014 Speaker: Bernhard Rosenkränzer Video: https://www.youtube.com/watch?v=xfzyvFCOPdA

1. Wed-5-Mar, 11:15am, Presenter Name.
LCA14-304: Building Android with
CLANG for ARMv7 & v8 platforms

2. lWorking much closer with upstream than before: Of a fairly large patchset touching 62
subprojects, only 18 patched subprojects remain. All other patches (including partial
patches to subprojects we're still patching) have been upstreamed.
lCurrent status: gcc 4.9 based builds on Nexus 10 and Nexus 7 (2013) are working
perfectly. Clang 3.4 based builds compile, but don't currently boot because of a Bionic
problem that needs further analysis.
lRemaining subprojects we have to apply local patches to:
lart, dalvik
lelfutils, e2fsprogs, perf, iproute2, llvm, libunwind
lbionic
lGallery2
lhardware/qcom/display, hardware/samsung_slsi/exynos5
lframeworks/av, frameworks/base
lexternal/chromium, external/chromium_org
lsystem/core
lkernel
Current status

3. lart
lclang 3.4 extra warnings that cause the build (with enforced -Werror) to fail:
lImplicitly casting enums to int
lMissing template keyword gcc is less strict about
lInitialized but unused variable
ldalvik
lUse of __builtin___clear_cache (gcc extension)
Remaining issues

4. lelfutils
lheavy use of nested functions (a gcc extension not supported in clang; clang
maintainers say they will never support it)
lTriggers clang bug #18201
lProblem with upstreaming: AOSP wants patches to elfutils to go through the elfutils
project rather than AOSP. elfutils maintainers don't care, calling any compiler other
than gcc “useless crap”
le2fsprogs
lProblems caused by clang using C99 semantics while gcc defaults to C89 semantics
– different interpretations of “inline”, “extern inline”
lFix accepted in upstream e2fsprogs
lAOSP should pull in updated e2fsprogs; patch doing that submitted but not yet
accepted (stuck in review loop?)
lperf
lRelies on __thread being available
liproute2
lUses variable-length arrays in structs (gcc extension not supported by clang)
Remaining issues

5. lllvm
lProbably the oddest thing not to compile with clang out of the box, given clang is part
of the llvm project...
lBut Bionic is at fault – with extra safety checks enabled, Bionic uses
l#define sprintf __builtin___sprintf_chk
lllvm uses std::sprintf...
lSo the patch is a workaround for an underlying Bionic issue
lGallery2
lCaused by different inline semantics (gcc defaulting to C89, clang to C99)
Remaining issues

6. lbionic
lBootup issues caused by blobs being built incorrectly: A number of blobs (e.g. GPU drivers for Nexus 10, Nexus 7) are
built with ancient toolchains, and rely on availability of libgcc symbols being exported by something (Android doesn't
have a shared libgcc). Proper fix is to fix (or better, open) blobs
lBionic has some hacks to provide what they need:
l#define COMPAT_FUNCTIONS_LIST
l XX(__adddf3) ...
l#define XX(f) extern void f(void);
lCOMPAT_FUNCTIONS_LIST
l#undef XX
l#define XX(f) f();
lvoid __bionic_libgcc_compat_hooks(void)
l{
l COMPAT_FUNCTIONS_LIST
l}
lWith gcc 4.9, that workaround is needed for some extra functions - __aeabi_udivmod and __popcount_tab
lClang issues:
lClang generates infinite recursive calls if __aeabi_memcpy and friends are implemented the Bionic way:
lvoid __aeabi_memcpy(void *dest, const void *src, size_t n) {
lmemcpy(dest, src, n); }
lRemaining (yet unsolved) issue: Applications including init crash on startup when using a clang 3.4-compiled Bionic.
Remaining issues

7. lHardware/qcom/display
lSingleton instances declared outside their target namespace. Produces a warning in clang 3.4 (C++11 extension used
outside of C++11 mode), causing build failure because of -Werror
lHardware/samsumg_slsi/exynos5
lUse of constructs that can be interpreted as C++11 string literals. Causes warnings with gcc 4.9
lFrameworks/av
lInline assembly incompatible with clang (“add r8, r0, asl #2” rather than “add r8, r8, r0, asl #2”)
lUndefined static const variables (kicked out by gcc -O1 and higher, problem with clang and gcc -O0)
lMissing #include statement for DISALLOW_EVIL_CONSTRUCTORS
lFrameworks/base
lUses variable-length arrays of non-POD data types – gcc extension not supported by clanalng
lExternal/chromium, external/chromium_org
lUse of std::snprintf (Bionic's default implementation is a #define)
lAssumptions about clang being clang 3.3
lUpstreaming slower because it has to go through 3rd party (chromium.org)
lSystem/core
lC99 inline semantics
Remaining issues

8. lKernel
lThe upstream kernel has various issues with clang 3.4, most of which are being fixed these days.
lBiggest issue is the use of variable-length arrays in structs (there is code to replace them – but gcc so far seems to
generate better code with VLAIS than with portable replacement constructs).
lVarious bugs discovered in device specific code that isn't part of the upstream kernel (e.g. incorrect uses of sizeof in
various Nexus 7 specific bits)
Remaining issues

9. lClang-wrapper (tool we're using to give clang a more gcc-like interface, so we don't
have to modify the build system) has complete Aarch64 support
lBoth gcc 4.9 and clang 3.4 have good Aarch64 support
lHowever, not all of the Android codebase is ready for the 64bit world – complete
64/64 build is still a work in progress regardless of toolchain.
Aarch64 status

10. lAarch64 porting
lRun test builds with clang 3.5 snapshots
lUpstream remaining patches
Next steps

11. More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members