binutils にパッチ投げてみた話

Mach-O バイナリをコード見ながら逆アセンブルする方法が無いってのがずっと困っていました。つまり linux でよくやっている objdump -S みたいなことがやりたかったんですが、 objdump -S は Mach-O に対しては動かないし、 otool -tvV もソースコードは見せてくれないし、っていう。でまぁ一念発起して binutils というか libbfd をいじってみたのでした。

今回はじめて FSF なソフトに patch 投げてみて、まぁ特に著作権の処理とかどのくらい時間かかるもんなのかよくわからなくて、こちらのかた以外にあまり体験談的なのが見つからなかったので、なんか書いていみようかと。

とりあえず適当にパッチ書き。経験上デカいパッチいきなり投げるヤツはうざがられるので、なんか小さめな目標で…ってことで objdump -S を .o に対してだけ動くようなものを書きました。というのは Mac の実行ファイルや動的ライブラリって、 dSYM っていう別なバンドルに保存されてるんで。参考: http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme

で、パッチ書けたので ML に入った。過去ログとか見るのめんどうだったので、深く考えずパッチ投げた。どうも ML にパッチを本文の末尾にくっつけて投げるスタイルが多いように見えたので適当にマネしました。添付ファイルと違ってコメントつけやすいから、こういう文化なんだろうな…と予想。

11月26日土曜にパッチ投げて月曜に返事をもらえました。要はみんな仕事でやってる感じぽい。適当にフィードバックを受けた部分を修正して再投稿。 OK とのこと。 Mach-O メンテナに Mach-O の部分見てもらって、 dwarf2.c とかちょっといじったのはグローバルメンテナの人が見てくれました。

で、 FSF に書面で著作権譲渡をしないといかんよ、と言われました。あれこれ探してみると、

http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/

が見つかって、これの request-assign.future を assign _at_ gnu.org に送る感じでいいの? って聞いたところ、それでいいよ、とのこと。というわけでメールを送る。11月29日。

8日後、12月7日におへんじもらえて、この PDF 印刷してサインして送れ、とのこと。この日のうちに手紙送って、一応送ったよ、とメール。そのメールへの返事は12月9日。

12月9日に配達完了、とのこと。で、12月13日に手続き終わったぜーというメールをもらったので、コミットしてもらいました。

ざっくり2週間くらいで、まぁちょうどそんなもんかなーと思っていた程度でした。その間に他のパッチをしょぼしょぼ書いてたので、1つずつ送っていきました。一気に送るとややこしいですし、慣れてないうちはパッチAで指摘してもらったことが、パッチBにも必要、ってことが結構ありますし、まぁ全く急いでないし、っていう感じでした。

でまぁ昨日になってやっと私のほしかった dSYM 使って逆アセンブルにソース重ねる機能がつきました、と。

思ったのは、グーグルやら Chrome/WebKit にパッチ投げる時のグッドプラクティスがだいたいそのまんま使えるなぁ…というような。具体的には

パッチは細かく。一気にいろんなことやるとレビュー大変だし、慣れてないスタイルのコードベースでデカいパッチ書くと、似たようなスタイルの問題が大量に出てきてうっとうしいし
最初はしょうもない変更で練習。こういうのでなんとなくこっちのレベルを知ってもらうのはいい気がする。つまり、まぁ論外ではないけど、それなりに変なミスしうるから、ちゃんとレビューせんとなーくらいの情報が伝わるというか
何をやろうとしてるか、なるべく説明する。英語書くのめんどくさいコード見ればわかってくれるでしょ…と思っちゃうけど、ほどほどにがんばる。普通にパッチの意図を伝えるのも大事だけど、説明書くことによって、どの程度対象のプロジェクトを理解してるかを伝えられるという効果も重要だと思う。他の方針思いついてた場合は、これも考えたけどどっちがいいかね、とか聞いたりするのもいい気がする
空気読む。 GNU style うざい…とか、こっちのファイルはタブ使っててこっちは使ってない困る…とか思ったけど、まぁまわりにあわせて無駄な波風をたてない
レビューコメントよく読む。私の場合よくあるのは、コード書く時に方針Aと方針Bを思いついて、方針Aが良いだろうと思って選んだ場所にコメントがつくと、あ、これは方針Bかなーと早合点しがちで、よく読むと、実は全く思いついてなかった方針Cを提案してくれてた、っていうようなことがよくある気がします
急がない。どうせ時差あって、相手が読むまで半日くらいあったりするので、あまり急いで返事することに意味ない。それに、なんか間違った返事するとそれを修正するのにまた半日かかるわけでして…

まぁあんまプロジェクトによらないテクニックですな。