はじめてのにき

_ ldscript

去年は ldscript を例年より多く書いた年でもあった。いやもちろん例年書くようなもんでないから、ちょっと書いたってだけなんだけど。

それはそうとして、 nacl-binutils の glibc 用の ldscript がどう考えてもこれ普通にはできないよなー的な問題があって見ていた。

通常、 ld script は ld/genscripts.sh を走らせることによってできていて、これは ld/{emulparams,emultempl,scripttempl} を合成することによって、複数の ld script を作る…ぽい。

さて問題だったのは、 nacl-binutils/ld/emulparams/elf_nacl.sh はどう見ても newlib 用というか、 static link するバイナリ用に見えるんだよな… start address とか。で、しかしよく見ると、 nacl-glibc/nacl/dyn-link/ldscripts の下に置いてあるファイルをコピーしてからリリースしてるっぽい。どうでも良いオチであった…

(00:02)

_ ARM

http://www.ced.is.utsunomiya-u.ac.jp/lecture/2013/aca/ARMjp-vH.pdf

ざっくりと ARM モードの命令セットをながめた。なんか結構ヘンなのあるんだなぁ。 short な複素数に便利ですって言われても僕の日常にはあまり影響しないよな…まぁ暗号とか動画エンコーダとかそのへんで便利だったりするんかね。

まだイマイチ GE フラグがよくわかってない…がまぁいいか。

Thumb はだいたいこれのエンコードが違って命令が少ないバージョンって理解でいいのかな…また今度ざっくり眺めよう

(01:18)

_ x86-64 ABI of TinyCC

http://repo.or.cz/w/tinycc.git/commitdiff/55ea6d3fc175b0e01e2e946ca9b319c1fbe8aa67?hp=3f1d9000071eeebe315795079c3adbe4022d6d19

なんか TCC がちゃんと x86-64 ABI 守る呼び出し規約やっててびびった。頑張って実装したなあ…

(01:50)

_ パズルゲーム

https://www.youtube.com/watch?v=HOfll06X16c

via https://twitter.com/i_saint/status/421159098814455808

かっこe

(01:51)

_ さくら VPS でハニーポット

http://www.slideshare.net/ozuma5119/vps-28984029

via https://twitter.com/eban/status/420198539885432832

かっこe

(01:51)

_ ぷよm@s

http://www.nicovideo.jp/watch/sm22653884

やっとトーナメント終わった

(23:20)

_ lld

ちょっと前になんとなくコード書いてるとこ撮ってみたやつだけど、 lld じゃなくて ldd だなぁ…とか思った。

http://www.youtube.com/watch?v=Lw2cW-n4hC8

わかったことは elf.h 見ないと ELF 扱うプログラム書けないぽいってことだった。あと vim 使えてない

(03:18)

_ ld

冬休みに昔作った nacl-gcc を Chrome の NaCl 上で動かすってのを復活させて、 bash の上で動かしてたりしてたのをチマチマ naclports に入れていっている。

その時一番困った問題は、これ

http://shinh.skr.jp/m/?date=20140103#p01

もうちょっと詳しく書いてみる。

最新の nacl-gcc/nacl-binutils で最新の nacl-binutils をビルドするとリンクがこけて、少し古い nacl-gcc/nacl-binutils で少し古い nacl-binutils もビルドできず、しかし古いので新しいのを作るか、新しいので古いのを作ると大丈夫という問題があった。

きっと ./configure がなんかヘンなもの detect しちゃって compile/link flag が微妙に違うとかそういうのだろーなーと見てみても、コマンドラインは基本一致している。

はてこれはいよいよおかしいなーと -v とかつけてみると、リンカスクリプトの prefix を指定するオプションが古いやつと最新で違う。古いやつは elf_nacl で新しいのは elf_i386_nacl 。しかしこれが一致してると動くならともかく、一致してると動かないのはヘンだ。

しょうがないから strace とかで様子を見ると、 ld をリンクする時だけ、カレントディレクトリにある ldscripts/elf*_nacl.x* とかを見ている。 ld をリンクする時は ld の出力ディレクトリに cd してからリンクしてるんだけど、この時 ldscripts ってディレクトリが既に置いてある。しかしこれ同じ内容のものがあるなら問題ないはずなんだけどなぁ、と見てみると、どうも static link 用の ldscripts が置いてあると気付く。

で、わかったことは nacl-glibc の shared link 用の ldscript はこっちのディレクトリにあって

https://chromium.googlesource.com/native_client/nacl-glibc/+/master/nacl/dyn-link/ldscripts

かつこれは後から ld の中に置いてある ldscripts と merge されているってこと。 linux 用の nacl-binutils をビルドする時はカレントディレクトリに置いてある NaCl 用の ldscripts は無視されるから問題ないんだけど、 NaCl 用の nacl-binutils をビルドする時は static link 用の設定を読んでしまうってわけ。

まぁ結局対処としてはカレントディレクトリにある ldscripts ディレクトリを ld をリンクする時だけ一時的に rename してやれば良くて、実際はこんな感じ

 ld-new$(EXEEXT): $(ld_new_OBJECTS) $(ld_new_DEPENDENCIES)
 @rm -f ld-new$(EXEEXT)
- $(LINK) $(ld_new_OBJECTS) $(ld_new_LDADD) $(LIBS)
+ # ./ldscripts/* will be read during this link and it messes up the
+ # link result because ./ldscripts contains the linker script for
+ # statically linked binaries. So, we temporary rename it.
+ mv ldscripts ldscripts.tmp && ($(LINK) $(ld_new_OBJECTS) $(ld_new_LDADD) $(LIBS) || (mv bar foo && false)) && mv ldscripts.tmp ldscripts

NaCl で遊んでると、大袈裟にハマってから、「俺だから致命傷で済んだがお前には NaCl は難しい」とか中二的な発言をしたくなるエピソードがたくさんできるわけだけど、これはまさにそういうインスタンスであった。

(01:36)