2016年10月9日 星期日

進行arm 開發時遇到的各種狀況

約一週前重灌了電腦,重灌這檔事最麻煩的就是一些開發環境會消失不見,平常用得順手的東西突然不見了,例如我的arm 開發環境就是一例:
首先在archlinux 上面,跟之前這篇不同,現在只剩下gcc49, gcc53跟gdb 還在
http://yodalee.blogspot.tw/2015/04/llvmclang.html
arm-none-eabi-gcc53-linaro
arm-none-eabi-gdb-linaro

替代品是AUR中下面這些套件(順帶一提,安裝這幾個套件之前,請先去/etc/makepkg.conf 把MAKEFLAGS 改成 -jn,不然用單核心編譯這幾個近100 MB的程式會編譯到想翻桌):
arm-linux-gnueabihf-binutils
arm-linux-gnueabihf-gcc
arm-linux-gnueabihf-glibc
arm-linux-gnueabihf-linux-api-headers
arm-linux-gnueabihf-gdb

安裝完之後當然就來用一下了,測試當然就用最簡單的helloworld.c 去測:
$ arm-linux-gnueabihf-gcc helloworld.c -o hello
exec format error: ./hello
這是當然的囉,因為我的機器是x86_64,而arm-gcc 編出來的執行檔要在arm 架構上執行,幸好這年頭我們有qemu-arm 可以用(老實說,悲劇就是從這裡開始的= =):
qemu-arm hello
/lib/ld-linux-armhf.so.3: No such file or directory
這又是為什麼呢?我們可以file 它一下,可以看到它的interpreter 是/lib/ld-linux-armhf.so.3,而這個檔案是不存在的。
file hello
hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=716a92a4985090baa83f8b762c5f9844e197ed83, not stripped

它真正的位置在arm-gcc 的安裝位置:/usr/arm-linux-gnueabihf/lib,創個symbolic link過去
ln -s /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 /lib/ld-linux-armhf.so.3
ll ld-linux-armhf.so.3
lrwxrwxrwx 1 root root 48 Oct 5 19:10 ld-linux-armhf.so.3 -> /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3

這時候就不會有No such file or directory,雖然會換成另一個錯誤
hello: error while loading shared libraries: libc.so.6: wrong ELF class: ELFCLASS64 http://blog.csdn.net/sahusoft/article/details/7388617
原因是dynamic linker 在連結動態函式庫時,找到的libc.so.6 是錯誤的格式,它找不到它要的arm 格式的函式庫,這步有時會有其他的錯誤像是:
cannot open shared object file: No such file or directory
這就是電腦上沒有安裝相對應的函式庫,可以用ldd 來確認這件事,沒有就要安裝該函式庫;或者函式庫安裝在/usr/lib 以外的特殊路徑,就要利用ld.so.conf去設定,像我的/etc/ld.so.conf.d裡面就有:
android-sdk.conf
cuda.conf
fakeroot.conf
ffmpeg2.8.conf
lib32-glibc.conf
octave.conf
openmpi.conf

不過我們的狀況比較複雜一點,在這之前試著把 /usr/arm-linux-gnueabihf/lib 加到ld.so.conf 裡面,執行ldconfig 時就出問題了
$ ldconfig
ldconfig: /usr/lib/ld-linux-armhf.so.3 is for unknown machine 40.
我們x86_64 的ldconfig 壓根不認arm 的函式庫,這些函式庫也沒加到ld.conf.cache,自然也不會在執行時被 ld-linux-armhf.so.3 連結,所以上面的執行還是失敗了。

所以說了這麼多,我們到底要怎麼樣才能把我們的hello world 跑起來?

首先是rpath
http://stackoverflow.com/questions/2728552/how-to-link-to-a-different-libc-file
在呼叫gcc 的時候使用
arm-linux-gnueabihf-gcc -Xlinker -rpath=/usr/arm-linux-gnueabihf/lib hello.c
這樣編譯出來的執行檔就會以/usr/arm-linux-gnueabihf/lib 為第一優先,就能夠直接以qemu-arm 去執行。

另一個方法是設定LD_LIBRARY_PATH,這個的優先順序高過 ldconfig 設定的路徑,也能讓qemu-arm 跑起來:
export LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib/
當然這不是一個好方法,也是老話題了,請見:
http://xahlee.info/UnixResource_dir/_/ldpath.html

或者是利用qemu-arm 的-L flag,這個的位階低於LD_LIBRARY_PATH,因此用這個要確定LD_LIBRARY_PATH沒有設值。
qemu-arm -L /usr/arm-linux-gnueabihf hello

試了這麼多方法,最後一種其實才是最有效的做法,也是我忘掉的方法(yay

寫文的同時我大概整理一下 man ld 裡面,在選項-rpath=dir跟-rpath-link=dir的說明:
首先是rpath ,這是設定runtime 時期的library search path,這些字串會完整的被複製到runtime linker (也就是ld.so)用來尋找共享函式庫;如果rpath 沒有設定,則linker 會使用LD_RUN_PATH 的值。
因此透過rpath 我們有兩招:
第一個是上面寫的,用rpath 設定搜尋路徑:
arm-linux-gnueabihf-gcc -Xlinker -rpath=/usr/arm-linux-gnueabihf/lib hello.c
arm-linux-gnueabihf-gcc -Wl,-rpath=/usr/arm-linux-gnueabihf/lib hello.c

第二個是直接編譯,但先設定LD_RUN_PATH的值:
export LD_RUN_PATH=/usr/arm-linux/gnueabihf/lib
arm-linux-gnueabihf-gcc hello.c

我們可以用readelf -d 把dynamic sections 給讀出來,就能看到我們設定的rpath 了:
readelf -d hello
0x0000000f (RPATH) 函式庫路徑:[/usr/arm-linux-gnueabihf/lib]

另外還有一種是 -L,它會設定連接時搜尋共享函式庫的目錄,這裡只給一個最粗淺的例子:
arm-linux-gnueabihf-gcc -c hello.c -o hello.o
arm-linux-gnueabihf-ld hell.o -o hello
會發生undefined reference to puts 的錯誤,因為我們沒有連接所需要的 c library,另外我們也沒有指定程式的進入點為何,要能連結通過至少要:
arm-linux-gnueabihf-ld hell.o -o -lc -L/usr/arm-linux-gnueabihf/lib hello –entry main

當然這樣不代表可以執行,試著執行會發現dynamic linker 並沒有正確設定,除此之外還有各種runtime 的library 需要連結進去才會動;要看到可運作的呼叫方式,可以用gcc -v (-verbose) 來觀察。

-rpath-link 則只指定link 時搜尋shared library的路徑,這個路徑不會包含到executable 裡面,這個我一時之間給不出例子,但在這裡有找到,利用 -rpath-link=. 在編譯時指定在編譯時目錄尋找 shared library,另外關鍵的差別都寫在這幾句話了:
在 gcc 中使用 rpath/rpath-link 指定 shared library 搜尋路徑
在 -rpath-link 裡指定 "." (當前目錄) 還算正常,因為我們可以控制現在的工作目錄,
但是在 -rpath 裡指定 "." 就有點奇怪,因為你不知道別人會在哪個目錄執行你的程式...

使用-rpath-link 須知它也會蓋掉原本的搜尋路徑,因此用-rpath-link有個危害是:link time linker(ld)跟runtime linker (ld.so) 可能會使用不同的shared library,因為後者並沒有設定這個路徑,而是去預設的路徑尋找。

man ld 有列出 link time linker 的搜尋路徑,不過它未寫明有沒有先後關係,但以-rpath 來說顯然是有的:
https://my.oschina.net/shelllife/blog/115958
http://blog.lxgcc.net/?tag=dt_runpath
1. 透過 -rpath-link 指定的資料夾
2. 透過 -rpath 指定的路徑,如上所說,這跟 -rpath-link的差別是它會被包括到runtime linker中
3. 如果前兩者都沒有指定,尋找LD_RUN_PATH環境變數的值
4. 在SunOS,如果 -rpath 未指定,尋找 -L 選項設定的值
5. 尋找LD_LIBRARY_PATH 設定之路徑,這裡有句 For a native linker,不確定native linker是在指什麼特別的linker
6. For a native ELF linker,會查找現在引入的共享函式庫中設定的DT_RUNPATH 跟DT_RPATH section,後者的優先度高於前者(其實這就是在編譯shared library 時,以rpath 編進去的路徑:)
7. 預設路徑 /lib, /usr/lib
8. /etc/ld.so.conf 設定的路徑、

整體大概就是這樣,從編譯到執行,有許許多多的地方都能讓我們有各種方法對執行檔「上下其手」,去改動裡面連結、動態連結引入的東西
不過說老實話,其實這篇文…是呃…我忘了 qemu-arm 使用上就是用 -L 去指定library path 的產物,花了我一堆時間… 這真的是:Hello World 年年都會寫,每一年都有不同的體會呢XD。
Related Posts Plugin for WordPress, Blogger...