顯示具有 toolchain 標籤的文章。 顯示所有文章
顯示具有 toolchain 標籤的文章。 顯示所有文章

2009年5月27日 星期三

buildroot - Enable setjmp/longjmp exceptions?

這週花了大部分的時間在處理這件事上

繼先前share buildroot toolchain with others之後
接著近日又被詢問了 c++ compiler 的環境
當下看了看buildroot configuration 中 Toolchain 項目有著一行

[] Build/install c++ compiler and libstdc++?

心想著這應該不過 30 分鍾就可以搞定了
接著就是一連串疑問的開始

編譯過程中, 編譯 libsupc++ 時錯誤發生了

/tmp/ccxY0pxQ.s: Assembler messages:
/tmp/ccxY0pxQ.s:423: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:580: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:581: Error: duplicate .handlerdata directive
/tmp/ccxY0pxQ.s:948: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:949: Error: duplicate .handlerdata directive
make[5]: *** [eh_alloc.lo] Error 1

而即便以相似設定以 crosstool-ng 編譯也會在相同點出問題

以buildroot和錯誤訊息作為關鍵字搜索, 可以看到一些資訊, 然而無有效線索
只好嘗試往 source code 找尋蛛絲馬跡
最後找到的是處理 exceptions 相關的部份
於是檢視一下buildroot有關exception的設定, 同在 Toolchain 內有著另外一行

[*] Enable setjmp/longjmp exceptions?

該項目主要是在編譯 gcc 時增加了一個設定項目
--enable-sjlj-exceptions

簡單地說, 是以呼叫 setjmp/longjmp 的方式來作exception handling
而事實上 libsupc++ 亦是C++中處理exception的部份
雖然沒有繼續trace, 然而應該是該部份與 C library 的部份有衝突
所以這問題應該與 uClibc 是有相關的

另外, 如果不使用 setjmp/longjmp 的 exception handling model
則採用的是 call frame unwinding 的方式

這兩者間的差異和優缺就不多說了

2009年4月29日 星期三

share buildroot toolchain with others

由於工作平台環境限制的緣故(見buildroot: 三個願望一次滿足一文),
所以當時採用了buildroot, 以利於產生toolchain與使用uClibc

當然, 單單在個人環境下使用buildroot不太會有問題
(意外是會接二連三發生的...:P)
最近要與他人co-work, 所以要把開發環境設好
天真如我, 反射性地, 就把 buildroot目錄下的 build_arm/staging_dir 打包後丟了出去
直到同事遇到了一堆 include/library search path 問題, 向我反映, 這才發現不妙
套句國見比呂的話, 現在才想要轉用crosstool-ng實在是太遜了
而使用alias 去傳入 sysroot 參數對於別人也不是好主意

問題發生的主要原因在於toolchain 對於 include/library search path找不到所需檔案
簡單的說, 就去觀察toolchain的path 設置, 並且把找不到的檔案放在適當位置即可
預設的include path可以透過 arm-linux-cpp -v 來取得
而library path 是由 arm-linux-gcc -print-search-dirs 取得

接著就是做一些file link or move
比較要注意的是libc.so 這個文字檔, 把裡面GROUP的path prefix 移除就可以了

anyway, 不這麼做的話, 比呂和英雄是不會對決的...
但是我們可不會水平外曲球, 下次還是改用crosstool-ng or scratchbox吧

2009年3月10日 星期二

buildroot: 三個願望一次滿足

由於新工作開始了, Prex的部份以後會慢慢推進
(目前mp3 decoder ok了, 還要弄audio driver/daemon)
而buildroot就是因為新工作的內容而開始接觸 (以前就聽過, 只是一直沒機會去玩.)

在開發embedded system中, crossplatform toolchain的選擇是相當重要的一環
在數年前, 產生對應平台的 gcc cross toolchain是相當麻煩的一件事情
glibc/gcc/binutils..版本的排列組合有可能會造成不同的問題
(ex: compiler編不過, compiler編完了不能編kernel)
因此需要花時間嘗試組合, 找到較佳的組合, 過程冗長繁複
而這幾年來令個人印象深刻的是Dan Kegel當時所撰寫的build script
方便的設定, 大大地簡化了如此測試的程序

現今cross toolchain可以說垂手可得了, 相當方便
稍微google一下就可以得到不少訊息和編譯好的工具
像是移植prex的過程中, 個人選擇CodeSourcery的Toolchain
主要的目標硬體平台(x86, ARM, MIPS, ColdFire, PowerPC)都有
也貼心地提供Linux/Windows兩種版本,
而CodeSourcery也隨著時間不斷地提供新版本和新平台的支援
不想親自動手準備相關環境情況下, 算是相當高品質的選擇

對於Embedded Linux而言, 除了toolchain, kernel外
除了Toolchain還得張羅root file system
buildroot提供相當方面的介面(類似編譯linux kernel的menuconfig), 滿足這三種需求
buildroot是uClibc的相關project, 提供uClibc-based的gcc toolchain
相對glibc/gcc所建構的環境, 在所需空間上節省不少
而且也編譯好busybox, 方便迅速地建構適用的環境
套句廣告詞: 三個願望一次滿足!

另外, 除了CodeSourcery toolchain, buildroot 外, Scratchbox也是不錯的選擇
而較龐大且全面的Embedded Linux專案可以考慮OpenMoko所採用的OpenEmbedded

在 ARM 平台上使用 Function Multi-Versioning (FMV) - 以使用 Android NDK 為例

Function Multi-Versioning (FMV) 過往的 CPU 發展歷程中, x86 平台由於因應各種應用需求的提出, 而陸陸續續加入了不同的指令集, 此外也可能因為針對市場做等級區隔, 支援的數量與種類也不等. 在 Linux 平台上這些 CPU 資訊可以透過...