EGLIBC初探

在Embedded的環境下，我們有許多C Library的選擇，從BSD libc、uClibc、glibc、dietlibc，甚至是klibc (配合initramfs)，過去我們考量到footprint，往往會捨棄發展活躍的GNU C Library (glibc)，轉而以uClibc或dietlibc來建構系統，正如uClibc的FAQ網頁提及的項目 "What's wrong with glibc?" 所說：

"The GNU C library is a great piece of software, make no mistake. It is compliant with just about every standard ever created, and runs on just about every operating system and architecture -- no small task! But there is a price to be paid for that. It is quite a large library, and keeps getting larger with each release. It does not even pretend to target embedded systems. To quote from Ulrich Drepper, the maintainer of GNU libc: "...glibc is not the right thing for [an embedded OS]. It is designed as a native library (as opposed to embedded). Many functions (e.g., printf) contain functionality which is not wanted in embedded systems." 24 May 1999"

以及下一條 "So uClibc is smaller then glibc? Doesn't that mean it completely sucks? How could it be smaller and not suck?" 所說：

"uClibc and glibc have different goals. glibc strives for features and performance, and is targeted for desktops and servers with (these days) lots of resources. It also strives for ABI stability. On the other hand, the goal of uClibc is to provide as much functionality as possible in a small amount of space, and it is intended primarily for embedded use. It is also highly configurable in supported features, at the cost of ABI differences for different configurations."

所以很明顯，glibc考量到通用性系統的需求，許多部份會考量到效能的最佳化處理，所以光是字串函式往往就可能拆成許多程序來實做，以針對不同的資料量給予最佳效能的處理方式，但往往也必須付出大量的footprint衝擊。Greg Alexander甚至寫了一篇用詞尖銳的文章 "GLIBC SUCKS" 來闡述他的觀察：就算是簡單只用printf()函式的 "Hello World" 程式，竟然也不成比例的龐大，引述如下：

Let's perform some more GLIBC2 vs. BSD libc comparisons:

[greg@linux] ~$ gcc -static -o hello hello.c; strip hello
[greg@linux] ~$ du -sk hello
416     hello

compared to:

[greg@freebsd] ~$ gcc -static -o hello hello.c; strip hello
[greg@freebsd] ~$ du -sk hello
44      hello

Yeah, that's right, when statically linked GLIBC2's printf() and support routines are about 10x as big as BSD's. We're on computers, a 15% improvement is considered worth looking at so you can copy their techniques. An "order of magnitude" is 2x. You simply aren't expecting 10x differences between extremely simple code that hasn't advanced, technologically, in more than two decades.

可見如此簡單的應用程式，其空間使用竟然達十倍之譜，在筆者的「深入淺出Hello World」系列演講也提及許多glibc與gcc潛藏的神秘性質，這些對於有特定目標、空間侷限的系統來說，是很難允許的。但採用非glibc的解決方案雖可大幅降低footprint與系統複雜度，卻可能因而限制可用的應用程式，最有名的例子就是Mozilla一直無法在uClibc上正確編譯與執行，這也辜負了採用GNU/Linux作為Embedded system作業系統的美意。過去我們得因應需求與彈性考量，多方取捨並周旋於前述的C Library實做中。

專注於GNU開發工具研發與客制化的CodeSourcery公司與若干嵌入式系統大廠，諸如MontaVista、Freescale，及WindRiver等廠商合作，針對glibc的改進計畫 (自2.5版開始)，實做出更適合Embedded環境的C Library實做 -- EGLIBC，並承諾與glibc的binary/source compatibility，其明確的目標可參考EGLIBC::Mission網頁：

" Expand and enhance the capabilities of the GNU C Library (GLIBC) to support embedded systems for diverse environments, and maintain an open development environment encouraging broad, cooperative developer participation."

所以採取同樣的codebase (svn merged from FSF)，同時也確保是Free Software (copyright holder為FSF)，在mailing-list也可見到「借力使力」的發展模式，如Joseph S. Myers的post "[patches] EGLIBC 2.6 created"。Jollen兄日前在「Embedded Device 等於 PC」一文提及以下概念：

「就現代的硬體來說，embedded device 和 PC 的界線是越來越小了，雖然有時參與的 project 是 'embedded device'，但是技術本質上就好像在做 PC 一樣。」

這是非常有趣、值得思索的趨勢，拜硬體蓬勃發展所賜，我們得以在此時間點大量採用原本桌面系統的軟體建設，知名的OpenMoko計畫就是最好的明證，但畢竟嵌入式系統的考量仍有差異，所以今日我們有以下發展理念：

• 銜接活躍的自由軟體開發
• 不只採用開放的系統，更要有開放的發展心態
• 將力量集中於刀鋒上，創造核心價值
  

這使得採用EGLIBC成為多贏的解決方案，於是OrzLab也開始評估這些嶄新技術。延續之前的分析與模擬驗證 (詳見「視覺化系統模擬與偵錯」一文)，最近的重心放於ARM Embedded ABI、GCC 4.2，與EGLIBC等最新的技術，為了簡化進行流程，我改了簡單的script:toolchain-eglibc.sh，這可自動擷取原始程式碼並建構。執行方式很簡單：

./toolchain-eglibc.sh arm

成功編譯後，會在$HOME/cross-build/arm-none-linux-gnueabi目錄下建立以下子目錄：

• obj : 建構過程的目的檔，可忽略
• tools : 包含GNU Toolchain
• sysroot : 置入target的Runtime (root file system)

稍後筆者會探討如何利用系統模擬器來驗證，並探討整體效能與記憶體使用的提昇。

Update: Jick的更新與修正可參考「EGLIBC: Embedded GLIBC 体验」