有鑑於 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

就如人們所熟悉，Android 底層運作 Dalvik 虛擬機器，在 C Library 層面採用衍生自 NetBSD libc 的 bionic。與過往的 Java 為基礎的操作環境 (OE; Operating Environment，如 Transvirtual 的 PocketLinux / XOE) 不同的是，每個 VM instance 均為獨立的 Linux process，且由 Zygote 所「孵化」。就系統的角度來說，縱使底層對 system library 做了 prelink (透過工具 build/tools/apriori)，但因語言實做的特性，需頻繁經由 JNI 去存取底層服務，也就是說，有大量的 dlopen()/dlsym() 操作，這些均無法透過 prelink 來縮減載入時間。

在 COSCUP 2010 的議程「打造特製的 Android Toolchain」中，小弟介紹了 0xlab 近來的幾項嘗試與改進項目，除了 GNU Toolchain (採用 gcc-4.4.4 搭配一系列的修改) 之外，就包含 Android bionic libc 與 prelink 的修改，企圖引入 DT_GNU_HASH 的機制 (也稱為 gnu hashstyle，或 gnu hash)，以加速 Android 的動態連結。現在基礎工作大致完畢，陸續提交到 AOSP (Android Open Source Project) 的 Code Review，應該會納入 Android Gingerbread 以及後續的版本中。實驗平台採用 Qualcomm MSM7x25 (arm1136j-s)，平均縮減 26% 的 ELF 動態連結時間，這對所有的 Android Activity (Java 程式) 與需要額外作 dlopen() 處理的系統函式庫，如 Qualcomm 的 camera HAL/service 或 Opencore/DSP，均可適用。

這過程中，讓小弟學習到頗多，從一開始的分析 (透過 oprofile 與開啟 bionic 裡頭 linker 的除錯資訊)，觀察到 Android 的動態連結處理，有點類似 OpenOffice 所面臨的議題，於是嘗試引入 DT_GNU_HASH。背景知識可參考以下文獻：

• LWN 清晰的介紹文章 "Optimizing Linker Load Times"，涵蓋四項 linker 參數背後的處理機制: -Wl,-O1, -Bdirect Linking, dynsor, gnu hashstyle (Precomputed Hash Values)
• Ali Bahrami 的 blog 文章 "GNU Hash ELF Sections" 與 "The Cost Of ELF Symbol Hashing"，淺顯易懂
  
• glibc 維護者 Ulrich Drepper 的論文 "How To Write Shared Libraries" (不要被 How To 字眼騙了，其實頗深入)，廣泛探討從歷史因素到 DSO 運作機制，以及 GNU Hackers 如何參照 Sun Microsystems 過往的改良機制，重新實做出 gnu hashstyle

gnu hashstyle 採用 Daniel J Bernstein 提出的 hash function，Jakub Jelinek 做了分析，比較原本 ELF hash:

The number of collisions in the 537403 symbols is:
name  2sym collision # 3sym collision # more than 3sym collision #
sysv            1749                5
libiberty         42
dcache            37
djb2              29
sdbm              39
djb3              31
rot              337               39                         61
sax               34
fnv               40
oat               30

sysv 那項是原本的 hash function，而 djb2 則是 GNU Toolchain 採用的方案。就現有自由軟體的實做來看，包含 glibc, uClibc, dietlibc (前三者支援 GNU/Linux), FreeBSD libc 均提供 gnu hashstyle 的支援，但 Android 未正式在 bionic 提供。需留意的是，prelink 方案總是比 gnu hashstyle 帶來更快的動態連結時間，但付出的代價 (空間) 較高，而且不若後者有彈性。

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

很多人從事 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