2009年08月28日
DWARF 一年生
デバッガの開発は、UI レベルから JTAG レベルまで、非常に幅広いレイヤーの知識が必要です。そのため現在の PARTNER の開発は分業化が進んでいて、それぞれの領域を1 人から数人の担当者が開発する形になっています。
デバッガの肝の一つとして、ELF バイナリに入ってるデバッグ情報の解析があるのですが、そこらへんはほぼ全て社長と佐藤さんが行ってきたそうです。
私は入社してから今まで、ほぼずっとシミュレータ周りの開発をしてきましたので、どちらかというと PARTNER のコア部分とは少し離れた位置にいます。
しかし、デバッガベンダーに勤めていながら、全くデバッグ情報の解析について知らないというわけにもいかないので、少しずつ勉強していく過程をメモしていこうかと思います。
デバッガの肝の一つとして、ELF バイナリに入ってるデバッグ情報の解析があるのですが、そこらへんはほぼ全て社長と佐藤さんが行ってきたそうです。
私は入社してから今まで、ほぼずっとシミュレータ周りの開発をしてきましたので、どちらかというと PARTNER のコア部分とは少し離れた位置にいます。
しかし、デバッガベンダーに勤めていながら、全くデバッグ情報の解析について知らないというわけにもいかないので、少しずつ勉強していく過程をメモしていこうかと思います。
さて、デバッグ情報と一口に言っても、いろいろな規格があります。通常の PARTNER は、主に GCC が生成する DWARF や STABS という情報を解析します。(Win 版では、pdb ファイルなども解析します。他には COFF や XCOFF など、また、さらにそれぞれの規格に対して各ベンダーのコンパイラごとに独自の拡張が入るので、個別対応を挙げて行くときりが無いそうです。社長はそれら全てに今まで対応してきたわけで、すごいですね。)
今回は広く使われている DWARF を見て行きたいと思います。
# STABS の方が古い規格で、シンプルですがダイナミックリンク周りの表現力が弱いようで、現在の主流は DWARF のようです。
http://dwarfstd.org/
DWARF は独立した規格ですが、ELF や GCC の影響をけっこう受けているのではないかと思います。DWARF は現在 Ver.3 が出ています。
http://dwarfstd.org/Dwarf3.pdf (2005 年 12 月)
佐藤さん曰く、GCC の 4.5 から DWARF 4 という新しいバージョンが一部入るそうです。現時点でも 3 の一部しか入って無いのですが、GCC は必要な情報さえ出せれば良いわけなので、規格の網羅率にはほとんど関心が無いみたいです。
DWARF 自体は、データフォーマットというよりも、むしろある種のプログラミング言語 (バイトコード) のようなものなので、様々な計算処理なども可能なようです。ただ、コンパイラの実装者から見れば、そこらへんはあまり関心が無いわけです。
（コンパイラが吐かないデバッグ情報は、デバッガはサポートしてもあまり意味が無いので実装が遅れる。デバッガが読めないデバッグ情報を吐いてもしょうがないので、コンパイラもサポートしない、というまさに鶏と卵の関係なわけです。GCC/GDB が FOSS 唯一のデファクトスタンダードであるがゆえに、技術革新がなかなか進まないのは見ていて歯がゆいところでもあります。）
流れとしては、GCC の dwarf4 branch から
http://gcc.gnu.org/viewcvs/branches/dwarf4/
Variable Tracking Assignments branch (VTA) に入り、
http://gcc.gnu.org/wiki/Var_Tracking_Assignments
それが、GCC 4.5 から main line にマージされるという流れのようです。
GCC は 4.x からは様々な高度な最適化を行うようになってきたのですが、そのせいで 4.5 からは、たとえ -O0 で最適化を切ったとしても、正しく変数などがインスペクトできないパターンが出てきてしまったそうです。
そこで、より高度なデバッグ情報が必要になってくるわけですが、デバッグ情報がリッチになれば、解析と生成に時間がかかるため、GCC のコンパイルスピードが非常に遅くなってしまうそうです。（今 Redhat の人が頑張って高速化しているそうですが、はたして。）
-fvar-tracking-assignments で有効になるらしいのですが、例えば以下のような情報が dwarf 4 で吐かれるそうです。
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00905.html
まだ先輩からの受け売りをまとめたばかりで全然勉強してませんが、ちょっと長くなりすぎたので、今回はこの辺で。
今回は広く使われている DWARF を見て行きたいと思います。
# STABS の方が古い規格で、シンプルですがダイナミックリンク周りの表現力が弱いようで、現在の主流は DWARF のようです。
http://dwarfstd.org/
DWARF は独立した規格ですが、ELF や GCC の影響をけっこう受けているのではないかと思います。DWARF は現在 Ver.3 が出ています。
http://dwarfstd.org/Dwarf3.pdf (2005 年 12 月)
佐藤さん曰く、GCC の 4.5 から DWARF 4 という新しいバージョンが一部入るそうです。現時点でも 3 の一部しか入って無いのですが、GCC は必要な情報さえ出せれば良いわけなので、規格の網羅率にはほとんど関心が無いみたいです。
DWARF 自体は、データフォーマットというよりも、むしろある種のプログラミング言語 (バイトコード) のようなものなので、様々な計算処理なども可能なようです。ただ、コンパイラの実装者から見れば、そこらへんはあまり関心が無いわけです。
（コンパイラが吐かないデバッグ情報は、デバッガはサポートしてもあまり意味が無いので実装が遅れる。デバッガが読めないデバッグ情報を吐いてもしょうがないので、コンパイラもサポートしない、というまさに鶏と卵の関係なわけです。GCC/GDB が FOSS 唯一のデファクトスタンダードであるがゆえに、技術革新がなかなか進まないのは見ていて歯がゆいところでもあります。）
流れとしては、GCC の dwarf4 branch から
http://gcc.gnu.org/viewcvs/branches/dwarf4/
Variable Tracking Assignments branch (VTA) に入り、
http://gcc.gnu.org/wiki/Var_Tracking_Assignments
それが、GCC 4.5 から main line にマージされるという流れのようです。
GCC は 4.x からは様々な高度な最適化を行うようになってきたのですが、そのせいで 4.5 からは、たとえ -O0 で最適化を切ったとしても、正しく変数などがインスペクトできないパターンが出てきてしまったそうです。
そこで、より高度なデバッグ情報が必要になってくるわけですが、デバッグ情報がリッチになれば、解析と生成に時間がかかるため、GCC のコンパイルスピードが非常に遅くなってしまうそうです。（今 Redhat の人が頑張って高速化しているそうですが、はたして。）
-fvar-tracking-assignments で有効になるらしいのですが、例えば以下のような情報が dwarf 4 で吐かれるそうです。
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00905.html
まだ先輩からの受け売りをまとめたばかりで全然勉強してませんが、ちょっと長くなりすぎたので、今回はこの辺で。
