ToDo:
なんか知らんけど、共有オブジェクトと意味不明なつきあいかたをしていて悩まされる感じの夢を見た。同名で内容の違ったのが二つあって、それが両方必要。で、いやこっちのバイナリはあっちのやつを読んでくれないとまずいのに…とか悩んでいる
基本的には意味不明な状況だけど、夢でまでこの手の問題を考えるとのか…と感慨深くなった。
(09:16)
2 drw-rw-rw- 0 1001 1002 0 Feb 2 04:19 foo 2 -rw-rw-rw- 0 1001 1002 129 Feb 2 00:35 hello.c 2 drw-rw-rw- 0 1001 1002 0 Feb 2 00:31 mingn 2 -rw-rw-rw- 0 1001 1002 1 Feb 2 04:20 moe 2 -rw-rw-rw- 0 1001 1002 1 Feb 2 03:48 ok 2 drw-rw-rw- 0 1001 1002 0 Feb 2 02:11 tmp 2 drw-rw-rw- 0 1001 1002 0 Feb 2 03:52 xxx
なんで全部 inode 同じなんだよ! てーか実装見る感じこれ開くたびに変わる気しかしないんだけど…
(16:19)
にチームの人と行った。なんだこれ…って感じですごかった。
チームの人は女の子の乗った鮫が悪いヤツを喰ってるシーンが一番良かったとか言ってて、ロボットレストランって名前からは全く想像できない感想であった。
セグウェイが事故ってたり、あとそもそも見たこと無い乗り物とかがあった。あれはバイク的なものだったのかなぁ。
(12:59)
http://i-saint.hatenablog.com/entry/2014/01/30/014332
undump (http://d.hatena.ne.jp/shinichiro_h/20060715#1152922272) 書いたあとに、結構既存研究があるぽい、ってことでちょっと勉強したことがあるなぁ。
モジュール、ヒープ、ページメモリ、スタックまでのメモリは、単純にメモリのマップされてる領域を片っ端から保存しておいて、復元するのが簡単なはず。 Unix なら core に program header が入ってるので、どうマップすればいいかもそれ見りゃわかるし、復元も copy-on-write で mmap するだけでいいはずで安いし省メモリ(初期化だけに使った用なメモリはメモリ消費しないんで)、たぶん。 Windows の core 相当が何か知らないけど、まぁ無いわきゃない…のかな
スレッドはスレッド起こしなおして元の PC に飛ぶだけ。 TLS があるならその前に TLS 用のレジスタも復帰するだけ。
で、たぶんそこからが結構地獄で、 fd の復元がまずもってめんどくさい…がこれは技術的には普通に可能で、書いてあるようなやり方で全然いけると思う。このへんくらいまでは、既存のオープンソースのライブラリとかが、 undump 作った直後くらいの段階でほどほどにある感じだったと思う。
IPC とネットワークはたぶん本気でたいへん。なんか論文とかで結構あったと思う。日本の大きなメーカとかが、ルータとかまで手入れて、メンテしたいマシンにいたサーバプロセスの移動とかした話を聞いたことがある気がするけど、まぁ費用対効果がすっごく低い気がする。
クラウド屋さんとかだと、データを serve してるプロセス動かしたい時は単に殺して他で生き返らせても動く構成にしておけばいいじゃん、どうせマシンって壊れるんだしさ…って風潮になってると思う。大量並列計算みたいなやつだと、ソフト側に協力させて、ここで状態保存ですよーみたいなことやる感じにしてると思う、 mapreduce とか。というわけで、僕の感覚ではサーバ用途ではこのへんの研究は流行ってない…気がする。
クライアントアプリだと初期化の高速化っていう限定的な用途で普通に使われてそう…かな。有名所だと emacs って今でも一通りの初期化した後の core を保存しておいて、そこから復帰する感じで起動してる…と思う。このへんだとメモリだけできれば良かったりするのでだいぶラクなんだろうね。
だーいぶ話がそれるけど、 Android やら Chrome がやってる zygote ってのもディスク使わず似たようなことをやってる感じ…だと思う。初期化が終わった状態のプロセス (zygote process) を用意しておいて、そのプロセスをもう一個作りたくなったら、一から初期化しなおすんじゃなくて、 zygote process に IPC 送って fork してもらう。これも初期化用途なんで、 fd から先のめんどくさいことはほとんど考えなくて良い。 Chrome 動かした状態で ps --forest すると chrome が階層構造になってるのがそれ…
と思ったんだけど、なんか僕が思ってたより一段深いなこれ…よくわからんけどぱっと見、 zygote に IPC 送る専用のプロセスがいる感じなのかな。 Chrome むつかしい…
(13:54)
最近は飲み会以外で日本大手のビール/発泡酒/第三種を飲むのを完全にやめた。酒は飲んでて何飲むかっていうと地ビールをなるべく飲んでいる。単にラガーに飽きただけかもしれないけど。
何が好きかというとまあなんでも飲むんだけど、今はペールエールとベルギー流の白ビールが好きな気がする。 IPA とスタウトあたりはちょっと前好きだったけど最近好きでないので、あまり好みは固定されてない気がする。銘柄は最低でも10回くらい飲まないと覚えられない子なので、あんまり覚えない。というかビールってこう適当に飲むもんなので、日常的に手に入らない種類にはイマイチひかれない。好きで覚えてるのは、結局日常で触れられるもので、
日本のだとよなよな最強だなぁ。よなよなエールと水曜日のネコがうまい。あと昔はそれほどでもなかったけど、銀河高原もうまいような。まぁでも上記の連中の方が好きかな。
会社の外人に日本酒と焼酎飲ませながら、日本は地ビールが最近まで作れなくて、大手が強すぎてさみしい、とかいう話をした。ら、「アメリカも似たような法律が30年前くらいまであって、それまではワインは色々個性があって上流階級の飲むもので、ビールは労働者の酒だった。種類はクアーズバドワイザーハイネケンみたいなラガーが4種類くらいあるだけで」みたいなことを教えてもらって、勉強になった。アメリカでも地ビールが浸透するのは時間がかかったから、そのうち流行るんじゃね、とか言ってた。今の雰囲気ではそんな気がしないけど、まぁそういうもんかもしれぬ。
(19:28)
冬休みに昔作った 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)
ちょっと前になんとなくコード書いてるとこ撮ってみたやつだけど、 lld じゃなくて ldd だなぁ…とか思った。
http://www.youtube.com/watch?v=Lw2cW-n4hC8
わかったことは elf.h 見ないと ELF 扱うプログラム書けないぽいってことだった。あと vim 使えてない
(03:18)
http://www.ced.is.utsunomiya-u.ac.jp/lecture/2013/aca/ARMjp-vH.pdf
ざっくりと ARM モードの命令セットをながめた。なんか結構ヘンなのあるんだなぁ。 short な複素数に便利ですって言われても僕の日常にはあまり影響しないよな…まぁ暗号とか動画エンコーダとかそのへんで便利だったりするんかね。
まだイマイチ GE フラグがよくわかってない…がまぁいいか。
Thumb はだいたいこれのエンコードが違って命令が少ないバージョンって理解でいいのかな…また今度ざっくり眺めよう
(01:18)
https://www.youtube.com/watch?v=HOfll06X16c
via https://twitter.com/i_saint/status/421159098814455808
かっこe
(01:51)
http://www.slideshare.net/ozuma5119/vps-28984029
via https://twitter.com/eban/status/420198539885432832
かっこe
(01:51)
去年は 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)
NaCl で遊んでたら、 8MB かそこらの tar ファイルのダウンロードを nacl_io がダウンロードしてる最中に bad_alloc 。んなはずないよなとプログラム確認してみるに本当に 8MB 分の vector<char>::resize に失敗してる。
ホントかよーと思うけどデバッグするのだるいので、 pepper_31 から pepper_32 に上げてみて、それでダメなら JS で tar は散らかすことにしようと思う… pepper_32 に上げてみる理由としては、 NACLVERBOSITY セットしてみたら NaClSysBrk が目に入って、 NaCl って最近 brk を deprecate した気がするなぁと。でもたぶん関係ないだろうな。
(01:17)
なんかひとつわかんないのは、バグで設定無視してデータ送るように途中でなっちゃってたってのは、通信量とか明らかに増えるはずだから普通気付く気がするんだけど、なんで気付かんかったんだろ、っての。
まぁこの手のやつは証拠ない限り悪意は無いって考えるのがだいたい正解なんで、単に本当に見てなかったのかな、って思ってるんだけど、しかしトラフィック見てないってのはかなりビックリな話ではある。
あるいは設定オフで使ってる人が少なすぎて気付かなかったとか、 Baidu IME のトラフィックと混じってて Baidu IME の方が多いとかで気付かなかったとか、まぁ可能性は色々考えられるんだけど、いまひとつどれも腑に落ちない感。
ぐぐると同じこと疑問に思ってる人少しいるぽいな。
(15:23)
記録をあさってまとめてみた。情報源は前教えてもらった google location history とメールとコマンドライン履歴
自宅で泊まったのが 234 日らしい。家賃の 35% がムダになっているわけか…やはり家に金かけるのは意味がないな。
あと国外にいた期間が109日。多かったなー。
あ、アメリカから日本への移動では移動を開始した日に東京って記録した気がするから、5日は飛行機の上なので、自宅は 229 日か。
まぁ来年はおとなしくなる予定…
(21:15)
| 前 | 2024年 5月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。