あるデジイチ初心者の記録(v2.0)

某氏を接待dinnerにご案内。”American”(ただし非巨大肉)なものというリクエストだったので、無難そうなMike’s Cafe(in Menlo Park)へ。

Appetizer: (居酒屋風にいうと)カマンベールチーズのかりかり揚げ。「shareしたいんだけど、どう？」と聞いたら「ばっちり」と言われたのでorderしてみたが、見ての通り結構shareしにくい形状だった…

Scampiガーリックソースと野菜とご飯。ホワイトバランス調整しなかったらちょっと黄色くなってしまった。

BIND 10 design meeting中のご飯を一挙掲載。

More… »

一つ前のエントリの続き。gccの_Unwind_Backtrace()には、フレームポインタなしでコンパイルされたコードに対しても動くという特長がある。はじめは、最初のフレームのときだけbuiltin関数に頼った後はレジスタの値を復元しながら巻き戻していくのでそういうこともできて当然、くらいに思っていたのだが、調べてみたらかなりtrickyだということが判明した: (少なくともFreeBSD/i386の場合)フレームポインタなしでコンパイルすると、gccは各フレームにおけるスタックの伸縮状況を細かく記録するFDEを作る。_Unwind_Backtrace()で巻き戻すときは、レジスタの状況にはほとんど頼らず、一つ前のフレームにおけるスタックの開始位置から、FDEに記録されている現在のフレームのスタックのサイズ分を差し引いて、直接現在フレームのスタックの位置を計算している。
単に_Unwind_Backtrace()を使うだけなら、こんなことまで知ってる必要はまったくないのだが、せっかく時間をかけて調べたのでこれもメモとして残しておくことにする。
More… »

ふと思い立ち、gccの秘密(?)関数_Unwind_Backtrace()を使って実行途中プロセスのbacktraceを取ってみようとしたら、驚くほど動かず、延々と調査するはめに。結局わかったことは以下:

• C++のコードの中から使った場合は(試した範囲内では)いつでも動く
• Cのコードから使った場合、x86_64(amd64)やIA64では動くが、x86(32ビット)とかsparcでは動かない。また、これらはOSにも依存しない
• Cの場合で、x86_64とx86の違いは、ELFの.eh_frame section内に実行コードのframeに関するcall frame information(CFI)が含まれているかどうか。含まれていれば動くが、そうでなければ動かない。
• x86におけるC++とCの差もELFの.eh_frame sectionの中身の違い
• .eh_frame sectionに必要な情報がなくても、.debug_frame sectionに実行コードのCFIが含まれていれば、それをちょっといじって__register_frame()(さらに秘密な関数？)で登録すれば動くようになる
• IA64の場合は上記とは別な扱いになっている模様。CでもC++でも、そもそも.eh_frame sectionが存在しないが_Unwind_Backtrace()はちゃんと動く

Cで動かすためのテストコードも公開しているので、万一このページを読んだ方がいらっしゃいましたら、(とくにi386やsparc以外で)動いたとか動かなかったとかご報告いただければ幸いです。

以下はとっても長い詳細。
More… »

出張でSan Franciscoに来ている某氏らと晩飯。

最近、誰かが出張に来るというついでに外食というパターンが結構多いような気がする(だからどうということもないが)。

South Bay住民との位置バランスを考慮して某氏には Millbrae まで出てきてもらい、肉希望の某氏のリクエストにより、BelmontのThe Van’sへ。
More… »

某氏から更新頻度が低いと怒られ、swine fluの疑いまでかけられてしまったので、次回帰国時に別室送りにならないよう、たまった写真を一部公開して潔白を証明することにする。
More… »