2014/10/28(火)glibcのビルド

逆アセンブルしてもソースコード中の関数をみても一致しない。
なぜだろうか・・・、ということで少し探ってみた時のメモ。
解決に至っていないので、そのものズバリが欲しい人は回れ右でお願いいたします・・・。
情報提供、誤り指摘はありがたく頂戴させていただきます。

ビルドされたログを見る

ct-ngにビルドしてもらった時のログから、1ファイルのコマンドラインを引っ張ってみる。
[ALL  ] 
( echo '#define SYSCALL_NAME close';
	echo '#define SYSCALL_NARGS 1';
	echo '#define SYSCALL_SYMBOL __libc_close';
	echo '#define SYSCALL_CANCELLABLE 1';
	echo '#include <syscall-template.S>';
	echo 'weak_alias (__libc_close, __close)';
	echo 'libc_hidden_weak (__close)';
	echo 'weak_alias (__libc_close, close)';
	echo 'libc_hidden_weak (close)';
	) \
 | arm-linaro-linux-gnueabi-gcc -c 
 -I../include 
-I/PATH/TO/MYDIR/_build/arm-linaro-linux-gnueabi/build/build-libc-final/io 
-I/PATH/TO/MYDIR/_build/arm-linaro-linux-gnueabi/build/build-libc-final 
-I../ports/sysdeps/arm/elf 
-I../ports/sysdeps/unix/sysv/linux/arm/eabi/nptl 
-I../ports/sysdeps/unix/sysv/linux/arm/eabi 
-I../ports/sysdeps/unix/sysv/linux/arm/nptl 
-I../ports/sysdeps/unix/sysv/linux/arm 
-I../nptl/sysdeps/unix/sysv/linux 
-I../nptl/sysdeps/pthread 
-I../sysdeps/pthread 
-I../ports/sysdeps/unix/sysv/linux 
-I../sysdeps/unix/sysv/linux 
-I../sysdeps/gnu 
-I../sysdeps/unix/common 
-I../sysdeps/unix/mman 
-I../sysdeps/unix/inet 
-I../nptl/sysdeps/unix/sysv 
-I../ports/sysdeps/unix/sysv 
-I../sysdeps/unix/sysv 
-I../ports/sysdeps/unix/arm 
-I../nptl/sysdeps/unix 
-I../ports/sysdeps/unix 
-I../sysdeps/unix 
-I../sysdeps/posix 
-I../ports/sysdeps/arm/eabi 
-I../ports/sysdeps/arm/nptl 
-I../ports/sysdeps/arm 
-I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32 
-I../sysdeps/ieee754/dbl-64 
-I../sysdeps/ieee754 
-I../sysdeps/generic/elf 
-I../sysdeps/generic 
-I../nptl 
-I../ports  
-I.. 
-I../libio 
-I. -nostdinc
 -isystem /PATH/TO/MYDIR/_build/arm-linaro-linux-gnueabi/buildtools/lib/gcc/arm-linaro-linux-gnueabi/4.7.4/include
 -isystem /PATH/TO/MYDIR/_build/arm-linaro-linux-gnueabi/buildtools/lib/gcc/arm-linaro-linux-gnueabi/4.7.4/include-fixed
 -isystem /opt/export/V980_cam/repo/_master_m8m/hosttool/arm-linaro-linux-gnueabi/arm-linaro-linux-gnueabi/sysroot/usr/include
 -D_LIBC_REENTRANT
 -include ../include/libc-symbols.h
 -DASSEMBLER
   -Wa,--noexecstack  
 -o /PATH/TO/MYDIR/_build/arm-linaro-linux-gnueabi/build/build-libc-final/io/close.o
 -x assembler-with-cpp -
 -MD
 -MP
 -MF /PATH/TO/MYDIR/_build/arm-linaro-linux-gnueabi/build/build-libc-final/io/close.o.dt
 -MT
 /PATH/TO/MYDIR/_build/arm-linaro-linux-gnueabi/build/build-libc-final/io/close.o
ソースコードだけ見ててもアカンやつや...
というかむしろソースコードないぞおい.
echoコマンドで現存するシステムコールはソースコードを生成してコンパイルしちゃうのかなぁ.
えぐいなぁ...

glibcじゃなくなるけど, eglibcの場合は 以下のソースをincludeして コードが生成されちゃう模様.
src/eglibc-2_13/sysdeps/unix/syscall-template.S
src/eglibc-2_13/ports/sysdeps/unix/sysv/linux/arm/nptl/sysdep-cancel.h
※nptl/cancel可能を前提として.

CodeSourcery G++ LITEのsource compile

2012/07/24build_systemimport

cross compile環境の構築

昔は h8のcross環境をへろへろ~っと作っていたけれど、久しぶり。
野良よりも、toolchainを公開されているものを流用してくることにします。
CodeSourcery G++ LITEですが、mentorの組み込みソフト部門として買収されたようです。

Host OSは Virtual machine上のCentOS5.7だったと思う.. 小数点部分が怪しい.
$ uname -a
Linux localhost.localdomain 2.6.18-274.el5 #1 SMP Fri Jul 22 04:49:12 EDT 2011 i686 i686 i386 GNU/Linux

$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

targetとか準備

ざっと作業メモを貼っておく。将来の自分用メモ的な意味で...
$ mkdir -p /tmp/csl_scratch/local_tools/bin
 ln -sf /usr/bin/gcc i686-pc-linux-gnu-gcc
 ln -sf /usr/bin/g++ i686-pc-linux-gnu-g++
 ln -sf /usr/bin/ar i686-pc-linux-gnu-ar
 ln -sf /usr/bin/ranlib i686-pc-linux-gnu-ranlib
 ln -sf /usr/bin/strip i686-pc-linux-gnu-strip

$ export OSS_DIR=/path/to/OSS
 ※ここは各自sourceを拾ってきたpathを設定。環境変わっても流用できるように.. 少しくらいは.

$ mkdir -p /tmp/csl_scratch/
$ cd /tmp/csl_scratch/
$ tar xf $OSS_DIR/CodeSourcery/freescale-2010.09-55-powerpc-linux-gnu.src.tar.bz2 

$ mkdir -p /tmp/csl_scratch/gnu-lite-release/src
$ cd /tmp/csl_scratch/gnu-lite-release/src
$ for f in $(ls /tmp/csl_scratch/freescale-2010.09-55-powerpc-linux-gnu/*.bz2); do tar xf $f; done

HOST環境を用意.

付属のshell scriptを見ると、GCC 4.3.3が無難そう.
置換で済む変更は sedでざっくり書き換え. テキトウに手動補正.
$ cp -a freescale-2010.09-55-powerpc-linux-gnu/freescale-2010.09-55-powerpc-linux-gnu.sh build.sh

$ sed -e 's,/scratch/froydnj,/tmp/csl_scratch,g' \
   -e 's,pushenvvar PATH /usr/local/tools/gcc-4.3.3/bin,pushenvvar PATH /tmp/csl_scratch/local_tools/bin:\$PATH,' \
   -e 's,pushenvvar LD_LIBRARY_PATH,#pushenvvar LD_LIBRARY_PATH,' \
   -e 's,rmdir ./lib/rh73,# rmdir ./lib/rh73,' \
   -e 's,/rh73/,/,' \
   -e 's/ -j4/ -j8/g' \
   -e 's,-mrh73,,' \
   -e 's,/usr/local/tools/gcc-4.3.3/bin/,/tmp/csl_scratch/local_tools/bin/,' \
   -i build.sh

CSFLを見ながら構築していこうと思ったけれど頓挫した.
ので, そのタイミングで拾っておいた m4,texinfoをHostに入れてしまう.
既存環境を壊さないように、これも/tmpに放り込んでみた.
永続して使うなら, 適当なuser directoryにでも入れておくと良いだろう.
ここに書いてないけれど, hostのgcc, binutils, kernel headers, flex, bisonくらいは必要.
厳密にどれだけ必要なのかは... 調べきる元気が無かったので, 既存環境に無いものをだましだまし追加.
tar xf $OSS_DIR/CLFS_PKG/m4-1.4.16.tar.bz2 

./configure --prefix=/tmp/csl_scratch/local_tools
make
make install
tar xf $OSS_DIR//CLFS_PKG/texinfo-4.13a.tar.gz 

./configure --prefix=/tmp/csl_scratch/local_tools
make
make install


カットアンドトライ

以下は残す. 2~35はコメントアウト*1
# task [001/258] 
# task [036/258] /i686-pc-linux-gnu/host_cleanup

ここでこける.
task [068/258] /i686-pc-linux-gnu/toolchain/binutils/postinstall
gnu-lte-release/obj/binutil... powerpc-linux-gnu-i686-pc-linux-gnu/libiberty/functions.texi
500行目あたり, 関数定義のマクロ部分に余計な改行が入っているので、改行をとってリトライ.
[148/258] /i686-pc-linux-gnu/toolchain/gdb/0/build
 /tmp/csl_scratch/gnu-lite-release/obj/gdb-src-2010.09-55-powerpc-linux-gnu-i686-pc-linux-gnu/libiberty/functions.texi

task [147/258] /i686-pc-linux-gnu/toolchain/gdb/0/configure
ここからやり直すとよい.

以下のtaskで参照している, getting started guideのソースが無い..?
task [158/258] /i686-pc-linux-gnu/getting_started/copy
task [159/258] /i686-pc-linux-gnu/getting_started/configure
task [160/258] /i686-pc-linux-gnu/getting_started/build
task [161/258] /i686-pc-linux-gnu/getting_started/install
task [162/258] /i686-pc-linux-gnu/csl_docbook
以下は 置換漏れ. まさかフルパスで書いていたとはな...
task [172/258] /i686-pc-linux-gnu/strip_host_objects
./build.sh: line 57432: /usr/local/tools/gcc-4.3.3/bin/i686-pc-linux-gnu-strip: No such file or directory

targetのlibcにデバッグシンボルを残したいときは, 次のタスクをスキップすると良い.
 task [173/258] /i686-pc-linux-gnu/strip_target_objects

installer?これも無かったと思う.
このディレクトリ"gnu-lite-release/src/scripts-trunk/"が無い.
パッケージを作るためのスクリプトが入っているようだけれど、source archiveには入ってなさそう.
task [175/258] /i686-pc-linux-gnu/package_installanywhere/unpack
task [176/258] /i686-pc-linux-gnu/package_installanywhere/merge_modules
task [177/258] /i686-pc-linux-gnu/package_installanywhere/installer
task [178/258] /i686-pc-linux-gnu/package_rpm

*1 : if false; then .... fi で切ってしまう

まとめ

たぶん host側も CSLのtoolchainを持っていれば良かったのだろう.
これに限らず host環境の依存性も重要であると再認識できた.

Build System

2012/01/05build_systemimport

Build System

と言っても良いのか、よくわかっておりませんが。。。
GNU build systemってwikipediaには
autoconfが載っているから、やっぱり違うような...

いずれも、設定すれば、自動的にlinux kernel image, roofs imageまで作り上げてくれる。
最終段の挙動だけにしぼれば、tarballやsrc.rpmを展開して、configure/makeしているようなもの。
autoconfの威力と、基本的に同じ操作でbuildしているものを自動化したもの、か?

詳しく追いかけていないけれど、それぞれで強みを持ったarchitectureはあると思う。
メンテナーと更新頻度、得意なscriptが使われているか、などを考えて選択すれば良いと思う。

最悪全部自分でpackage source拾って、buildできるようにはなっておいた方がいろいろと便利ねtp146_note

buildroot

Build Rootは、あまり中身を見ていないのでパス(ぉ

LTIB

LTIBはfreescale semiconductorが管理している環境、かな?
同社のサイトにBSPなんかを取りに行っているので、対応しているRDBを使っているなら
さくっとrootfsが作れちゃう。

OpenEmbedded

OpenEmbeddedは、まだこれから食べるところ。
bitbakeというpython scriptからイロイロと起動する模様。

openwrt

OpenWrtは、主にルータのf/wを書き換えたりするのが多そう。
perlで書かれている。