ToDo:
http://shinh.skr.jp/m/?date=20110226#p03
の記述はよく考えると微妙だったのでコメントしてみた。 まぁ普通にこっちの意図くみとってくれてるみたいだからいいけど…
http://d.hatena.ne.jp/lyrical_logical/20110228/1298914755#c1299005524
(03:51)
昏倒するまで論文読む会というのがあるとのことなんで、 例のごとくフィーリングで何やらかっこいい気がするようなものを 読んだり読まなかったり表だけ見たりした。
つまりあんまマジメに参加してない。
ログ: http://www45.atwiki.jp/konron/pages/29.html
チャットしたりログを見たりしてると、 ちゃんと研究とかやってる人はなにやら色々知っててすごいなぁとか思った。
なにやら面白い会を企画してくださった kinaba さんありがとうございます。
そろそろ「ミーハー心で勉強したフリしてみたいなー queue」がカラになりつつある気がするな。 いやこの queue って特に記録してないからふと思い出したり、 だらだら wikipedia 読んでる最中に増えたりするから なかなかカラにはならんかもしれんけど。 まぁしかし素直になんかまっとうに一つのジャンル勉強してみるとかもいいかもしれんね…
「学生時代にやらなかったことを!」とか 「今こそ青春を取り戻そう!!」みたいな感じで、 つまり社会人デビューというやつですね…
(01:57)
ちょっと前に作っていた mach-o => elf トランスレータは、 libc の初期化がめんどいとかいう理由でローダにしようかという方針になった。
% ./ld-mac otool_x86_64 -h otool_x86_64
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777223 3 0x80 2 12 1872 0x00000085
おおー。
x86 はポータブルという wo さんの主張は正しいなぁとか。
(02:07)
今まで会ったことある人で名前覚えてる人…って考えて、 h_sakurai さんが心配な感じだなぁとか思っていて、 まぁ僕自身もなんか書いとくかと思ってこれを書いておく。
あとは福島山形あたりにちらほらいるけど、 まぁあのへんなら特に連絡なければ大丈夫だろうね…
(21:21)
どうでもいいことぐぐっててもどうでもいい感じなんで、 まあ適当に細かいことをやる。
起動時に走らせるべきものを、 システム設定 => アカウント => ログイン項目 あたりで設定できるみたいだ。 どっかにあるだろうなあと思いつつ長い間放置していた。
適当に synergyc とブラウザで開くのをリモートからやれるものを 項目として足してみた。 .sh で終わっていると Xcode が開いてしまうので、 拡張子は無い方がいいようだった。 open コマンドでどういう挙動になるかは確認できそう。
スクリプトはこんな感じで希望通りの挙動になるみたいだった。 正確には Terminal.app がちょっとの時間動くのが ちょっとうざいけど、まあ気にならない。
#!/bin/sh nohup /usr/local/bin/synergyc -f u4 > /tmp/synergyc.log 2>&1 &
ついでにログイン時に Skype が動くのが 長いことうざいなあと思ってたので、 起動項目から消したりした。
(15:52)
元々 ps のオプションってよくわからんけど、 Mac の ps は特によくわかってなかった。
linux でも mac でも似たような結果を得たい場合は ps -ef を常に使うのが良さそう。 Mac だと UID が username になってなくて、 man によると -u が指定されている場合は username になるらしいが実際はならない気がする。 あと linux の ps -ef は出力が端末だと 80cols で切るようになるっぽいな。
pstree は linux の pstree -p が普段は好み。 Mac の…というか fink の pstree は ps --forest に近い感じの出力で、 ちょっと読みにくいけど長いコマンドが出てるのが便利な時は便利。 fink pstree の 80cols で切るのが便利なことはあまり無いので、 pstree -w は常にやっておいていい気がする。
Linux の方は pstree -pw とかは読めたもんじゃなくなるので、 フルなコマンドラインが欲しい場合は ps -ef --forest とかがいいのかなあと思う。
macports とか homebrew の pstee も入れてみるかな…
(16:05)
http://twitter.com/#!/yhara/status/46549698311491584
http://twitter.com/#!/shinh/status/46562269408149504
http://twitter.com/#!/kinaba/status/46570482014752768
http://jarp.does.notwork.org/diary/201103b.html#201103121
http://twitter.com/#!/sumim/status/46828720685711360
kinaba さんのやつぱっと見全然わからなかったけど面白かった。
このサイトすごいな…
http://homepage2.nifty.com/hiranouchi/prime/index.html
(16:28)
gcc のコンパイルはとりあえず動くようになった。 今は ld をなんとかしようとしている。 apple 独自ってことで色々と他よりは 細かいこと色々必要だったけど、 特にああそういえばそうだなあと思ったのは、 C++ exception が dwarf 無いせいで 全くハンドリングできないなあということだった。
まだよくわからんところで SEGV してる => ソースコードからビルドした ld が欲しいなぁ => ld をビルドしよう => xcode が古いって感じのエラーで ld のコンパイルがうまくいかない => 新しい xcode をインストール…
みたいな感じの yak shaving
(03:41)
> wget http://www.opensource.apple.com/tarballs/libstdcxx/libstdcxx-39.tar.gz --2011-03-15 02:15:52-- http://www.opensource.apple.com/tarballs/libstdcxx/libstdcxx-39.tar.gz Resolving www.opensource.apple.com... 17.254.20.243 Connecting to www.opensource.apple.com|17.254.20.243|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 117081041 (112M) [application/x-gzip] Saving to: `libstdcxx-39.tar.gz' 2% [ ] 2,772,912 535K/s eta 3m 59s ^C zsh: interrupt noglob wget
なんで libstdc++ が 112MB もあるの…と見てみると
http://www.opensource.apple.com/source/libstdcxx/libstdcxx-39/
なんか gcc とか入ってる。 大変めんどいでございましょう
(02:19)
http://golf.shinh.org/p.rb?SIANGLE
このデカい問題をやろうとすると stdin の方の pipe がつまっていたので修正した。
しかしどうもゴルフ場でやると遅いというかなんというかな問題がある。 なんか select とかしてちょびちょび読んだり書いたりするより、 素直に標準入出力をファイルにつないでやって、 そのファイルを読み書きする方が速い気がしてきた…
(08:08)
なんかしらんが bison というか、 その bison が呼び出しているらしい m4 がなかなか動かない。
まあ bison とかはどうでも良くて、 どっちかというと llvm-gcc をやりたいのだけど、 これは libllvm.dylib を使ってるから、 本当に loader ぽいことをしないといけなくてけっこうめんだくさい。 見なければならないのは rebase ってやつと export ってやつで、 それぞれまたちょっと工夫された感じのエンコーディングがされてるので、 それなりにがんばらないとなんですよね…
(22:43)
なんか昔からなんとなく30からは大人というイメージがあって、 今の自分と昔イメージしていた大人のギャップが結構あるなぁとか。
基本的に大人になるということにいいことがあるとは あんまり思ってないので、それは自分的にはとりあえず良いことではある…が。
が、なんか最近そうか僕は実は大人だったんじゃないだろうか… とか思ったことがあって。 なんか地震とかあって、いつも通り、 あらあら大変…とか思ってたんだけど、 しかしまぁよく考えると細々としたこととはいえ、 事態ををよくすることに些細な貢献ができる立場なんじゃないかなぁ… とか気付いたみたいな。
しかし30つーとそろそろ頃合だから、 なんかマジメに面白おかしいことを考えてみるのがいい気もしないでもない。 今の仕事は普通にそれなりに面白おかしいからいいんだけど、 その後みたいな。
なんかもっと色んなこと勉強すべきな気がするんだよななんとなく。
(01:01)
はなんかチマチマと少しずつ色々やっている。 とりあえず大物では clang やら llvm-gcc が動いてないのをなんとかしようと。
なんかどっから見つけたのか海外の人が twitter で少しだけ話題にしてたりして、 github のリポジトリの watch 数が既に僕の置いたものの中では最大とかになってておもろい。 やまぁ他が caddy とか ags とか w3m とかくらいしか無いので、 比較として微妙すぎるけど。
最近やったこととしては、 LC_DYLD_INFO_ONLY とかいうのの bind 系 (ELF で言うところの relocation) しか ごにょってなかったのを、 rebase っての(PICなコード内での絶対参照を補正するなにか)と export っての(nm -D で出るやつ) を対応して、 dylib を読めるようにしたのと、あとは細かい関数をしょぼしょぼ足していっているのが大きい感じだと思う。
clang とか llvm-gcc が動かんのは、 libstdc++ の ABI とかが色々変わったりしてるのが悪いのかな… という気がしていたので、 linux の libstdc++.so じゃなくて mac の libstdc++.dylib を使う方向で考えていた。 しかし、よく考えると、 ld, dyldinfo, dwarfdump, dsymutil あたりは C++ で書かれているけど動いてるわけで、ちょっとヘンな話ではある。 最終的には libstdc++.dylib 使う方が良い方向な気がするけど、 もうちょい手っ取り早く動かす方法はありそうだなぁ…
(01:20)
#0 0x00007ffff6eee165 in raise (sig=<value optimized out>)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff6ef0f70 in abort () at abort.c:92
#2 0x00007ffff6f2427b in __libc_message (do_abort=<value optimized out>,
fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3 0x00007ffff6f2dad6 in malloc_printerr (action=3,
str=0x7ffff6fe1b75 "free(): invalid pointer", ptr=<value optimized out>)
at malloc.c:6267
#4 0x00007ffff6f3284c in __libc_free (mem=<value optimized out>)
at malloc.c:3739
#5 0x00007ffff77558a8 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, unsigned long) ()
from /usr/lib/libstdc++.so.6
#6 0x00007ffff77558ec in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) () from /usr/lib/libstdc++.so.6
#7 0x00007ffff77570fd in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::replace(unsigned long, unsigned long, char const*, unsigned long) () from /usr/lib/libstdc++.so.6
#8 0x0000000100e94650 in ?? ()
#9 0x0000000100ec3dfc in ?? ()
#10 0x0000000000000017 in ?? ()
こういう stack trace になっていて、 debian の libstdc++ のバージョンが /usr/lib/debug に置いてあるやつと そろってないせいかデバッグ情報出ないな… と、バージョンをそろえてみたりしたんだけど、 そもそも /usr/lib/libstdc++.so.6.0.14 に .gnu_debuglink がついてない…
objcopy --add-gnu-debuglink=/usr/lib/debug/libstdc++.so.6.0.14 libstdc++.so.6.0.14
とかでむりやりつけた。
warning: the debug information found in "/usr/lib/debug//usr/lib/libstdc++.so.6.0.14" does not match "/usr/lib/libstdc++.so.6" (CRC mismatch).
うーんどうしたもんか。
(05:19)
まぁやっぱ libstdc++.dylib を読む方向性の方が良いかなぁ…とながめてみる。
まずどうもおかしいのが filesize がゼロの LC_SEGMENT があることで、 これはなんか xcode に入ってる libstdc++.dylib は 中身ないんだかなんだか知らんがそうなってるみたいだった。 というわけでとりあえず Mac から取ってきた。
で、 Mac から取ってきた方は初期化ルーチンのところでコケる。 スタックトレースがそれなりに深いけど意味わからんので、 Mach-O のシンボルテーブル使ってスタックトレースが出せるようにしたり。 なんか知らんけど gdb のスタックトレースってのは たいへん優秀で他より情報出がちなんで、 python から gdb いじる系のあれでほげほげしてみる。
結果
#0 0x7ffff79c7ed4 __pthread_mutex_lock #1 __gnu_cxx::__recursive_mutex::lock()(+9) [0x10004ce2d(4ae2d)] #2 0x7fffffffdbb0 None #3 __cxa_guard_acquire(+34) [0x10004cdcd(4adcd)] #4 0x7fffffffdd20 None #5 0x7ffff6eb9d00 None #6 0x7fffffffdc20 None #7 (anonymous namespace)::get_locale_mutex()(+32) [0x10000b702(9702)] #8 std::money_put<wchar_t, std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::id(+8) [0x100088540(86540)] #9 std::locale::id::_S_refcount(+8) [0x100088438(86438)] #10 0x7ffff6ec6450 None #11 (anonymous namespace)::locale_cache_mutex(+40) [0x100088760(86760)] #12 vtable for std::basic_streambuf<char, std::char_traits<char> >(+10) [0x100083f90(81f90)] #13 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::size() const(+62dc70) [0x62dc70(62dc70)] #14 __gnu_internal::buf_wcerr(+270) [0x100088410(86410)] #15 0x0 None
よくわからんところで死んでるということはわかった…
(06:11)
の apple のソースコードがリリースされてないように思える。
Xcode 3.2.4 の clang は
% clang -v Apple clang version 1.5 (tags/Apple/clang-60) Target: x86_64-apple-darwin10 Thread model: posix
で、
http://opensource.apple.com/release/developer-tools-324/
には clang が無くて、
http://opensource.apple.com/release/mac-os-x-1066/
にあるのは clang-23 とかでだいぶふるい。
Xcode 4 以降は
http://opensource.apple.com/release/developer-tools-40/
にあって clang-137 とかなんでバージョンあってそうだけど…
(18:02)
↑のはそんなわけないだろ! と自分を叱責する次第。 原因はあいかわらずわかってないけど。
Mach-O は意味わからず適当にいじってる部分が多くてよくない。 なんか Mach-O のリファレンスみたいなやつって なんか量多いわりにイマイチ情報が足りない気がするんだよな…
適当にぐぐってたところ、このシリーズ勉強になりそうだなぁと発見した。
http://d.hatena.ne.jp/teru_kusu/20100329/1269849713
遅延ロードとか今全然やってないから、 やる気が起きたら参考になりげ…
(17:46)
| 前 | 2011年 3月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ izumick [無事で何より。こっちから関東以北に電話しても全然つながらないんだよね。福島の人、浜通りに勤めてたよね。忙しいから連絡..]
_ shinh [はい、なんかわかったら連絡さしあげますです。]