Chromiumを手探った#2 - コードに当たりを付けよう
#1はこちら。
前回ビルドに成功したChromiumの大量のソースコードから、今回弄るべき対象となる部分を見つけるためのアレコレです。
GDBを使ったデバッグ（基本編）
タブを新しく作成した際にどのようなソースコードが読まれ、どのような動作をしているかを調べるためにはデバッガを使用します。今回はGDBをEmacs上から扱いました。
M-x gud-gdb
gdb --fullname chromeを（事前にM-x shellで...src/out/Defaultまで移動した後に）実行すると、
シンボルの読み込みを延々と続け、2〜10分後…
ようやくシンボルの読み込みが終了し、デバッガ上でコードを探っていくことが出来ます。あとはmain関数やその他の怪しい関数にbreakpointを設定してnextやstepで辿っていく…というのが基本です。
問題点
何より重いです。シンボルを読み込むだけで数分何も出来ない時間が生まれてしまい、生きているのが辛くなります。
また、スレッドが多重に立ち上がり、所望のスレッドがどれなのか把握しづらいです。ブラウザは立ち上がった後、基本的に入力待ちをしているため、「とりあえずnextしてみる」に意味がありません。
さらに、「タブを開く」という動作のGUI的側面を管理する.jsファイルをこの方法では追うことが出来ず、あまり本質的ではありませんでした。
ソースコードをあたる
GDBを上手く動かすことができなかった僕たちには泥臭くコードを見ていくしか選択肢がありませんでした。
ファイル名(new_tab_ui.ccなど)をもとに幾つかのソースコードを見ていく中で、変数kChromeUINewTabURL[]を発見しました。これが怪しいと睨んだ僕たちはこの文字列がソースコード内に含まれるファイルを検索することになりました。
そこで主に用いたのがgrepコマンドです。
$ grep -rnI kChromeUINewTabURLを実行すると、.../src/chrome/common/url_constants.ccなるファイルに、
const char kChromeUINewTabURL[] = "chrome://new_tab";として定義されていることが判明しました。また、この文字列を直接変更することで「新しいタブ」ページを任意のページに変更することができました。
後はこの変更を、設定ページ(chrome://settings)から行えるようにすればいいだけだ！とこの時はまだ楽勝ムードが漂っていました。（遠い過去のお話のような気がします…）
これ以降も基本的にはgrepでソースコードに当たりをつける作業を何度も行っています。また、変数名で検索することでコードとコードの繋がりや依存関係を推定することもできます。
僕たちはgrepが端末で行えて気楽だったのでこればかり使っていましたが、ChromiumにはCode Searchという優秀なコード検索ツールが用意されています。こちらを利用するのも非常に有効です。
GDBを使ったデバッグ（上級編）
ライブラリをGDBで辿る方法、シンボルを全て読み込む機能をオフにする方法などが実験内で紹介されました。非常にわかりやすい説明が成されていますので、ここではリンクを貼るに留めておきます。
ちなみに、これが紹介されたタイミングでは僕たちはコードに目星をつけ切っていましたので、正直あんまりこの中に書かれていることは活用できてないです…。（やってはみましたが）
次回予告
grepという武器を入手し、意気揚々とソースコードの山に挑戦する一行だったが、立ち塞がるのは訳の分からない変数ばかり。前も後ろも何も見えない正しく五里霧中の状況で差し伸べられた一筋の光とは！？――次回「printfデバッグは神」
#3はこちら
