ToDo:
↑のはそんなわけないだろ! と自分を叱責する次第。 原因はあいかわらずわかってないけど。
Mach-O は意味わからず適当にいじってる部分が多くてよくない。 なんか Mach-O のリファレンスみたいなやつって なんか量多いわりにイマイチ情報が足りない気がするんだよな…
適当にぐぐってたところ、このシリーズ勉強になりそうだなぁと発見した。
http://d.hatena.ne.jp/teru_kusu/20100329/1269849713
遅延ロードとか今全然やってないから、 やる気が起きたら参考になりげ…
(17:46)
の 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)
まぁやっぱ 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)
#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)
なんか昔からなんとなく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)
なんかしらんが bison というか、 その bison が呼び出しているらしい m4 がなかなか動かない。
まあ bison とかはどうでも良くて、 どっちかというと llvm-gcc をやりたいのだけど、 これは libllvm.dylib を使ってるから、 本当に loader ぽいことをしないといけなくてけっこうめんだくさい。 見なければならないのは rebase ってやつと export ってやつで、 それぞれまたちょっと工夫された感じのエンコーディングがされてるので、 それなりにがんばらないとなんですよね…
(22:43)
http://golf.shinh.org/p.rb?SIANGLE
このデカい問題をやろうとすると stdin の方の pipe がつまっていたので修正した。
しかしどうもゴルフ場でやると遅いというかなんというかな問題がある。 なんか select とかしてちょびちょび読んだり書いたりするより、 素直に標準入出力をファイルにつないでやって、 そのファイルを読み書きする方が速い気がしてきた…
(08:08)
| 前 | 2024年 10月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。