Saturday, 7 February 2009

いつもの課題 glibc

Linuxのsystem callで、

 kernel 側のソースコード
 API 側のソースコード

を見つけるという課題があるんだけど、これが面白いほど「毎年違う」。

授業中に「ここだよ、ほら」みたいな感じで示すんですが、

 qemu でkernelをtraceする

とかさ。結構、面白い。だが、それようのkernel soruce/binaryを作るのは大変。

API側も、glibc なんだが... これが一筋縄では出来ない。え? 簡単? 残念ながら、うちは...


 Fedora 7 で、gcc だけ 4.1.2

これだと、コンパイラの依存性で落ちちゃう。gcc は最近 drastic に変わっているので... array_init とか、atomic_swap とか、document もないしな〜

info gcc をepkg に入れて欲しいが...

取り敢えず、../glibc-2.6/configure --prefix=/lib で、GNUCの#defineを調整して、make -k でごまかすというので動くようです。

でも、dynamic loading があるので、traceも工夫しないと動かない。

まぁ、僕は面白いが、学生はどうなんだろ?

でも、ソースだけ見ても出来る。 例えば、execl だったら、
grep execl glibc-2.7/**/*.c
ぐらいで捕まるよね?

で、それで、__execve だとわかるので、
grep __execve glibc-2.7/**/*.c
する。

で、必要なのは、linux なので、sysdeps/unix/sysv/linux の下だ
ってわかって、でも、実は、それは、INLINE_SYSCALL だから、

grep INLINE_SYSCALL glibc-2.7/**/*.h

ってな感じだろ? で、i386用の定義は
glibc-2.7/sysdeps/unix/sysv/linux/i386/sysdep.h
にあるのはわかる。

それがどう展開されるかはかなり複雑

結局は... int $0x80か、他のものになります。sysdep.h の中で。

Post a Comment