LCA14: LCA14-304: Building Android with CLANG for ARM v7 and v8 platforms
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

LCA14: LCA14-304: Building Android with CLANG for ARM v7 and v8 platforms

on

  • 474 views

...


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

Statistics

Views

Total Views
474
Views on SlideShare
474
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

LCA14: LCA14-304: Building Android with CLANG for ARM v7 and v8 platforms Presentation Transcript

  • 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