有鑑於 Google 的 Android toolchain 開發團隊雖然活躍提交修改/貢獻到 GCC 與 binutils，但受限於 Android 原始碼釋出的慣例，總是要等待頗長的時間，才有機會使用到新的 GNU Toolchain 改善或者新功能，所以，0xlab 開發者就準備一份客製化的版本，請參考以下網址：

• http://downloads.0xlab.org/toolchain/armv5te/

目前提供 gcc-4.4.3 與 gcc-4.4.4 兩個版本，前者是取自 Google Android 的原始碼分支，提供 ICF (Identical Comdat/Code Folding) 與 LIPO (Lightweight IPO) 等優化機制，而 gcc-4.4.4 的版本則是 0xlab 升級到新的程式基礎，並加入必要的修正。原始程式碼與 Toolchain 建構系統可參考 GIT: android-toolchain。不久的將來，我們將會全面移轉到 Linaro toolchain，也會一併發布 gcc-4.4 與 gcc-4.5 的 Android toolchain。

read on

我們在今年八月中旬的 COSCUP 研討會中，很榮幸地向與會的朋友介紹 0xlab 若干新的開放原始碼專案，本文稍作整理回顧。0xdroid 是 0xlab 最早的一項整合性開放原始碼專案，目的是建構於 Beagleboard 開放的硬體之上，提供 Android 的參考實做環境，經過一年多的累積，裡頭的成果被帶到不同的移動裝置中，比方說手機與 Tablet。今年二月份，有幸在 Mobile World Congress 2010 展示基於 Android 的移動裝置，Tieto 也在 TI OMAP3 平台展示 0xdroid，這些都讓我們更有信心，擴展到多元的應用。

這半年間，延續 0xdroid 的經驗，我們發展 / 貢獻以下專案：

• 0xRobocat : 與 CATCAN 合作的專案，目的是打造一組控制伺服馬達與相關零組件的軟體框架，可提供給 Android 或 GNU/Linux 使用，以 Apache License 2.0 授權釋出。除了用於打造機器人外 (是真的可走動的 "Android")，本專案可用於 Android 裝置 (如手機) 的自動測試
  
• 0xBench : 有鑑於 Android 上的系統效能評比程式，不是不完整，就是非開放原始碼，所以我們決定重新打造一個。0xBench 可從 C 函式庫/系統呼叫的層面，一路從 Dalvik VM 評測到 Android framework，仍持續擴充，並且我們提供 Web service，允許貢獻評測的結果，用互動的方式來分析。程式主體是 Apache License 2.0 授權
• android-toolchain : 0xlab 特製的 GNU Toolchain，以 Android team 的成果為基礎，整合來自 Linaro Toolchain Working Group 的改善。這些主要是 GNU GPLv3 授權
  
• Android Open Source Project (AOSP) : 提交 0xlab 過去在 TI OMAP 與 Qualcomm 72xx 平台的一些修改，經過公開的 Review 機制，慢慢整合到 AOSP
• CyanogenMod : 社群版本的 Android，在 Nexus One, HTC Dream 等裝置有相當優越的表現，收錄若干來自 0xlab 的改良，比方說 Bluetooth HID profile
  

除了以上的開放原始碼專案，我們內部正進行一個基於 Android 的新型態應用，未來也會將相關的專案程式碼，以開放原始碼的形式釋出，完整的列表可參考 0xlab Projects。至於 AOSP，我們現有更改的項目是：

• build - 調整 Android build system、修正工具程式的瑕疵
• bionic - 提供 ARM optimizations，針對 ARMv6/ARMv7
• PixelFlinger - 基本的 refactoring，以及 ARM 實做的改良
• libpng / libz - 利用 GCC visibility，進一步縮減 code size
• elfcopy - ELF 工具的調整
• bionic / apriori / build - 支援 DT_GNU_HASH，加快動態連結的速度
• toolchain - 加強 build system 的彈性

以上，歡迎舊雨新知給我們支持與指教，謝謝。

read on

延續筆者去年的紀錄「當 Compiler 遇上 Mobile」，最近我們又獲得一些進展，是在 Android 的 Dalvik 虛擬機器環境中，引入 pre-compiled class 的實驗，除了可改善執行時期的效能、記憶體使用量外，另外就是避免在「反組譯並修改 Android 應用程式實例」一文可見的資訊保護議題。

其實十幾年前，在 Java 平台中就有相當多團隊提出可行的方案，而世界上第一個開放原始碼的 Kaffe 虛擬機器專案，早在 1999 年即提出實做 "Kaffe/GCJ integration"，成功地將 GCJ (GCC for Java) 自 Java class/source 編譯得到的機械碼，當作 pre-compiled shared library，讓 Kaffee VM 讀取，預期可有效改善執行效能並縮減起始時間。GNU Classpath 專案主持人 Mark Wielaard 在 LWN 的文章 "GCJ - past, present, and future" 提到相關的歷史與技術背景，最早可回溯到 Cygnus solutions 時期 (RedHat 尚未併購) 的 GCJ 計畫提案 -- "A Gcc-based Java Implementation"。

為了降低實做的複雜度，筆者最早採用 LLVM 與 IcedTea 作為系統框架，不過一直到今年春節，整體進度還是陷入膠著的狀態。現在則引入 Java2C 搭配 PGO (Profile-Guided Optimization) 與統計模型，嘗試分析運行於 Dalvik VM 的 Android activity / system server，佔用系統資源最頻繁的項目，並預先編譯 (pre-compile) 這些 class/method，居中透過 JNI (Java Native Interface) 讓 Dalvik VM 存取。不過，實務上來說，不是將所有 class/method 都編譯為原生機械碼，就會帶來效能提昇，相反地，後者往往讓系統陷入更差的效能。目前 Eclair 裡面的 Dalvik VM 雖然沒有完整的 JIT compiler，但其 fast interpreter for ARM 的確做了頗多 threaded interpreter 的改進，考量到 I-cache, paging, 與 branch prediction，若我們不思量 Java / Android Dalvik 應用程式的執行時期行為，只是一味作編譯轉換，很可能只是編譯極少被執行，或者完全不會被執行到的程式碼，因此加重執行時期的負擔，而最該被優化的部份，受限於不完整的 source-to-source 轉換，有顧此失彼的疑慮。

於是，找出系統中最該被優化的部份，並考量到正確性與相容度，就是我們的首要研究議題，筆者採用知名的 SciMark 2.0 作為量化分析的指標。以下是在 Qualcomm MSM7x25 硬體平台 (arm1136j-s) 的效能評比，ARM11 的時脈是 528 MHz，ARM Linux 版本為 2.6.29.6-0xlab：
由上可見，在 SciMark 2.0 的各項評比中，Pre-compiled class 執行效能都較 Android Dalvik fast interpreter for ARM 給予一定程度的改良，並且透過 FDO (Feedback Directed Optimization)，大多可進一步給予提昇。這僅是初步的整合實驗數據，還需要更多分析與進行實做。

read on

很多人從事 Android 移植，但連 Android Toolchain 都自行維護者，相對就少多了。筆者過去有幸在「台灣心」計畫中，從事建構於台灣自主 CPU 的軟體開發，嘗試從零到有，將 Android 移植到 Andes NDS32 架構，就涉及到 Toolchain 的更動。而維護 0xdroid 與對應 0xlab 的 GNU Toolchain，不免會迷失於眾多的原始程式碼，只好靜下心慢慢探索，沒想到因此挖掘到頗多「寶物」，本文簡記備忘使用。

Google 工程師 Jing Yu 於 Jan 18, 2010 提交一份修改 "Bring gcc-4.4.0 to up-to-date"，讓人摸不著頭緒，不過其對於 GCC 的 architecture 更動，追加了新項目，可參見檔案 gcc-4.4.0/gcc/config/linux-grtev1.h 。以下節錄開頭註解：

/* Definitions for Linux-based GRTE (Google RunTime Environment) version 1.
Copyright (C) 2009 Free Software Foundation, Inc.
Contributed by Chris Demetriou.

This file is part of GCC.

這個以 Linux 為基礎的 GRTE 到底是什麼呢？沒獲得解答，只好在其 gcc spec 檔中探索，以下是相關的描述：

/* When GRTE links statically, it needs its NSS and resolver libraries
linked in as well. Note that when linking statically, these are
enclosed in a group by LINK_GCC_C_SEQUENCE_SPEC. */
#undef LINUX_GRTE_EXTRA_SPECS
#define LINUX_GRTE_EXTRA_SPECS \
{ "libc", "%{static:%(libc_static);:-lc}" }, \
{ "libc_p", "%{static:%(libc_p_static);:-lc_p}" }, \
{ "libc_static", \
"-lc -lnss_borg -lnss_cache -lnss_dns -lnss_files -lresolv" }, \
{ "libc_p_static", \
"-lc_p -lnss_borg_p -lnss_cache_p -lnss_dns_p -lnss_files_p -lresolv_p" },

這裡的 libc 看來是獨立的 C Library 實做，比較有趣的是 libnss 的部份。libnss 可透過外部的 module 作擴充，比方說 libnss-ldap 就是 "NSS module for using LDAP as a naming service"，而前述 gcc spec 提及當進行靜態編譯時，需要將所需的 module 一併連結，那麼，這系列 libnss_ 開頭的函式庫，顯然就是 GRTE (Google RunTime Environment) 所需的基礎建設。來看看有哪些特別的：

• libnss_borg
• libnss_cache

或許後者可從名稱猜出一些端倪，但這個 "libnss_borg" 實在是太詭異 (Borg in Star Trek?)，跟 GRTE 一樣神秘，我們只好等待 Google 大神給我們一些驚喜。

另外，Android Benchmark Suite 2.0.0 已公開釋出，可參見 benchmark.git，值得一書的是，內建了 FDO (Feedback Directed Optimization) 的編譯、測試，與效能評估機制。

read on

GNU GCC 4.4 已於 Apr 21, 2009 正式釋出，伴隨眾多改進、修正，與硬體平台改善，詳情可見"GCC 4.4 Release Series Changes, New Features, and Fixes"，不過 Android repository 裡頭的 prebuilt GNU Toolchain 仍停留在 gcc-4.2.1 (Release date: Jul 18, 2007)，總是有些遺憾，且讓我們動手改變。

EMBINUX™ Lab 提供一份 prebuilt GNU Toolchain for Android，參考其 git 的更動，可建立一套基於 gcc-4.4 與 binutils-2.19.1 的 toolchain，筆者準備打包好的套件： toolchain-arm-eabi-4_4_0.tar.bz2。另外，因為 gcc-4.4 對於 C/C++ 語意更加嚴格，像是應用程式對 va_list 的使用就需要調整，筆者將這些小修改整理為 migrate-gcc44.patch。以下是簡要的升級方式：

# cd mydroid
# cd prebuilt/linux-x86/toolchain
# tar jxvf toolchain-arm-eabi-4_4_0.tar.bz2
# cd ../../..
# patch -p1 < migrate-gcc44.patch

重新編譯與建構 Android 即可。需要更動的部份，列出作參考：

# diffstat migrate-gcc44.patch
core/combo/linux-arm.mk             |    2 +-
dist/sqlite3.h                      |    2 +-
envsetup.sh                         |    2 +-
pdk/ndk/samples/sample/Makefile.lib |    2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

read on