Hello list,

I would like to make a proposal about utilizing Linaro toolchain for
Android and NDK (Native Development Kit)[1].

** Motivation

There are some different perspectives between Linaro toolchain and
Google Android toolchain including technical and
non-technical considerations.  It doesn't really work if we only
replace prebuilt toolchain with Linaro toolchain because
of the compatibility of Android system utilities such as ELF
prelinker.  Also, since Android is developed in relatively closed
environment (Google style open source model), a great amount of
software components are not always verified by different
toolchain or build configurations.  This proposal attempts to
establish the compact development flow to enable Linaro
optimized ARM toolchain to build Android from scratch and verify it
transparently.  Eventually, Android can be the reference
indicator as Linaro toolchain performance and reliability.


** Brief introduction to Google Android toolchain

Inside Google, there is a dedicated compiler team working on GNU
Toolchain for various purposes including server-side
computing, Android, Chrome OS, etc. Google engineers submit patches to
upstream for public review and maintain the
toolchain for Android.  Along with each Android Open Source Prokect
(AOSP) release, there is a special branch in korg
GIT [2] for hosting the GPL'd  toolchain source code modified by
Google.  Usually, file "README.google" mentioned the
summary, but it is not developer friendly because several changes were
done within one GIT commit.

Please refer to wiki for details:
    https://wiki.linaro.org/Platform/Android/UpstreamToolchain


** What's wrong with Android upstream Toolchain?

In my opinion, list as following:

(1) Few information about Google improvement:  Sometimes, we have to
guess something from implicit GIT commitlog
such as "commit gcc-4.4.3 which is used to build gcc-4.4.3 Android
toolchain in master"[3].  It is hard to track and get
verified carefully.

(2) Google specific improvements are absent in recent release, only
enabled months later.  For example, Google Compiler
Team Lead, Dr. Shih-wei Liao, presented the improvements against GNU
Toolchain in the middle of 2009.[4].  The report
came with several impressive improvements like FDO (Feedback Directed
Optimizations) and IPO (Inter-Procedure
Optimizations).  However, only some of them are public to AOSP and be
integrated late in the middle of 2010 (Android
Froyo; 2.2).  Even FDO was merged in Android Froyo already, but there
is few documentation and no robust method to verify
by community members such as Linaro engineers.

(3) For some reasons, Google tends to deliver stable (old) toolchain
plus mainline backport.  It is a safe and workable approach,
but sometimes developers would expect to use the latest technologies
as Linaro aims to bring to the world.

(4) Few readable documentation.  For example, Google already open its
toolchain benchmark suite in early 2010, but there was
no document specific to such important components.  Furthermore, there
was one file gone in public kog GIT, required by
automated benchmark process.  One year later, Google engineer finally
put back the one to public.  This implies the unusual way
Google developed and delivered software.


** Linaro's Approach to enable latest technologies

Linaro android team tries to do:
(1) Document Android toolchain and related utilities in korg GIT as
possible as we can.
(2) Early adaptation of Linaro toolchain to Android build system and
verify these output systematically.
(3) Backport Google changes to Linaro GCC and review in public.
(4) Improve the deployment and validation flow by means of Linaro
infrastructure.
(5) Build and test Android system with Linaro tools.  Then, figure out
the regressions caused by Linaro Toolchain and/or
aggressive optimizations
(6) measure performance gain by Linaro tools

The detailed specification in wiki:
    https://wiki.linaro.org/Platform/Android/Specs/LinaroAndroidToolchain


** Implementation of Linaro toolchain for Android

We started from Android style toolchain build and move to Linaro GCC +
ARM specific optimizations in mind.  The initial work
can be obtained by wiki:
    https://wiki.linaro.org/Platform/Android/Toolchain

We plan to maintain the following GIT repositories at least:
 * android/toolchain/build.git : Linaro-aware build system.  Derived
from Android toolchain build system, it can handle Linaro-GCC
   and Linaro snapshot/bzr.
 * android/toolchain/gcc-patches.git : Patchset to be applied on top
of Linaro-GCC release/snapshots

The reference builder script output:
$ ./linaro-build.sh --help
--prefix-dir=               Specify where to install (default:
/tmp/android-toolchain-eabi)
--gcc-src-dir=       Specify where linaro gcc source is (in <toolchain>/gcc)
--apply-gcc-patch=(yes|no)  Apply-patch which in
<toolchain>/gcc-patches directory (default: no)

Current verified combinations:
 * gcc-linaro: 4.5-2011.02-0
 * binutils: 2.20.1
 * gmp: 4.2.4
 * mpfr: 2.4.1

Only gcc is replaced by gcc-linaro: 4.5-2011.02-0 and others are
checked out from korg GIT.


** Summary of gcc-patches

"gcc-patches" are used as "backport" from Google changes into Linaro
gcc base.  Here is the summary at present:

0001-Add-linux-android.patch
    Add linux-android

0002-Add-support-for-Bionic-C-library.patch
    Add support for Bionic C library

0003-Support-compilation-for-Android-platform.patch
    Support compilation for Android platform

0004-Add-multilib-configuration-for-arm-linux-androideabi.patch
    Add multilib configuration for arm-linux-androideabi

0005-Fix-gthr-posix.h-to-support-Bionic.patch
    Fix gthr-posix.h to support Bionic

0006-Add-untested-support-for-Bionic-to-libstdc.patch
    Add [untested] support for Bionic to libstdc++

These patches are taken from Maxim Kuvyrkov of CodeSourcery in gcc-4.6
branch.  Of course, we can always add changes by
Google or other Android specific adaptation by this model.


** Planned improvements over Linaro toolchain for Android

(1) GCC multilib setting
     Default: arm, fpu and thumb.  The prebuilt google toolchain use:
armv5te and mandroid.  We should focus on ARMv7.
(2) HardFP-ABI Support for Android.
(3) Patch management: Better to get the Android patches into
Linaro-GCC tree eventually.
(4) Build system improvement. Don't have to build gmp, mpfr everytime,
and provide option to build without gdb.
(5) Enable LTO (Link Time Optimization, introduced since gcc-4.5) in
Android TARGET_GLOBAL_CFLAGS
(6) Verify the functionality of FDO (Feedback Directed Optimization)
and introduce the approaches to integrate.


** Toward Android NDK

Once Linaro toolchain for Android is ready to use, it is time to
re-package Android NDK by Linaro toolchain.  To do that, extra
build configuration, sysroot, is required.  According to Android
Release Cycle & Phases[5], the repacked NDK should be verified
one moth after Android public release.

Sincerely,
Jim Huang (jserv)

[1] http://developer.android.com/sdk/ndk/index.html
[2] http://android.git.kernel.org/
[3] 
http://android.git.kernel.org/?p=toolchain/gcc.git;a=commit;h=b094d6c4bf572654a031ecc4afe675154c886dc5
[4] Smaller and Faster Android: A talk from a practitioner to fellow
ones, Shih-wei Liao, Google,
    
http://coscup.wdfiles.com/local--files/schedule-2009/AndroidOptimizationStudies.pdf
[5] Android Release Cycle & Phases Draft,
https://wiki.linaro.org/Platform/Android/ReleaseCycle

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to