2009年10月06日
2009年10月02日
http://www.gnu.org/software/gdb/news/reversible.html
http://d.hatena.ne.jp/hayamiz/20090930/1254323169
(ネタ元は、私がtwitterに張ったURLのようです。すごいブックマークの数ですね。)
ちなみに私は、greenteaさんの獲物で知ったのですが、同僚の佐藤さんやkobaさん、社長などは既に知っていました。
この機能は、GCC Summit 2007で発表されたようです。
http://ols.108.redhat.com/2007/GCC-Reprints/GCC2007-Proceedings.pdf
"Reversible Debugging", Paul Brook(CodeSourcery), Daniel Jacobowitz (CodeSourcery), pp.69-76
佐藤さん曰く、Non-stop multi-threaded debuggingも地味だけど面白いとのことです。
続きを読む
2009年09月30日
[LTO merge][0/15] Description of the final 15 patches
http://gcc.gnu.org/ml/gcc/2009-09/msg00578.html
http://gcc.gnu.org/ml/gcc-patches/2009-09/
ついにLTO(Link-Time Optimization)branchがGCC trunkにmergeされるようです。
続きを読む
2009年09月28日
今日は弊社の製品であるexeGCCのVLINK(Virtual Link)機能について紹介します。
これはターゲットボードに弊社のPARTNER-Jetがつながっていれば、CPUとRAMしか動いていない状況でも使うことができます。
2009年09月24日
- DWARF と有限状態機械
- DWARF と有限状態機械 (2)
概要、プログラムヘッダときて、今回のバイトコードで行番号プログラムの仕様は最後です。
行番号プログラムの目的は、1つのコンパイル単位中の行番号情報表を構築することです。つまり、プログラムを実行すると、表が出力として得られます。
この表は、命令アドレス、ファイル名、行、列、各種位置フラグ(ブレークポイント関係など)など、有限状態機械の状態と1列が対応するようなものです。つまり、行番号プログラムの実行過程における有限状態機械の状態遷移の記録=行番号情報表となります。
この表において、命令アドレスは増加する一方ですが、行番号はコンパイラの最適化などによる命令の並び替えによって減少する場合もあります。
続きを読む
2009年09月18日
2009年09月16日
- DWARF と有限状態機械
前回は、どのようにして行番号情報が保持されているのかという概要、そして有限状態機械の仕様について説明しました。
今回は、具体的なヘッダのフォーマットを見ていきます。
デバッグ情報の自由なベンダー拡張を許しつつ、それをサポートしないデバッガでも独自拡張部分以外のデバッグ情報は正しく読めるような工夫がしてある点が面白いところだと思います。このしくみは実際に多用されていて、コンパイラベンダーごとに、様々な独自拡張が入ったDWARFが生成されるようです。
行番号プログラムヘッダ(The Line Number Program Header)は、以下のようなフォーマットになっています。
続きを読む
2009年09月14日
ソースレベルデバッガが最低限必要とする情報として、ソースコード中のプログラム行の位置と、対応するマシン命令アドレスの表があります。特にコンパイラによる高度な最適化が入ってくると、1つの行から不連続なアドレスにマシン命令が生成されるようになってくるので、デバッグ情報が無ければ、どこのアドレスにブレークポイントを張れば良いのか、ステップ実行の時にどこで止めれば良いのか、などが全くわからなくなってしまいます。
この対応表は非常に巨大なものに成り得るので、DWARFは対応表をそのまま持つのではなく、行番号プログラム(line number program)によって対応表を生成するという仕様になっています。これは、JVMの仮想機械語のようなバイトコードプログラムとなっています。具体的には、ソースコードのファイル名、行/列番号、命令アドレスなどを状態とする有限状態機械を定義し、その仮想機械のバイトコード列(= 行番号プログラム)をデバッグ情報として保持します。
続きを読む
2009年09月10日
この記事ではgcc 4.4.0を使用しています。もっと新しいgccの場合はこちら。
2013年06月27日 ARMのNEONのSIMD命令をgccのオートベクタライズの最適化で使う方法
AndroidのSDKのgoldfishのCPUをcortex-A8に置き換えてNEONのSIMD命令を試す(その2) のときにはarm_neon.hに定義されているintrinsicsを使ってNEONのSIMD命令を生成させました。この方法だとNEONの命令について詳細を知っていなければなりませんし、なによりもそのプログラムがNEONに依存したものになってしまいます。
今回はコンパイラの最適化の機能を使ってNEONのSIMD命令を生成させるコツを紹介します。
2009年09月08日
（ただし、これはあくまでも私が理解したところなので、間違いが多分にあるかと思いますし、特にレビューを受けてもいない文章です。文責は私にあります。）
リアルタイムトレースとは、プログラムの実行中の PC の動きや、データアクセスの際のアドレスやアクセスタイプ (R/W) などをキャプチャーする機能のことです。基本的には CPU に負荷をかけずに済むので、実際にプログラムを動作させた時の CPU の状態遷移をそのまま見ることができます。(遅くなるものもあるそうです。)
組み込みではリアルタイム性が重要なプログラムが多いので、トレースは非常にデバッグの役に立つ機能です。弊社の PARTNER-Jet は、1 GB の大容量トレースを難なくこなし、QProbe という解析ツールと連携することもできます。(Model 40 の場合。)
ETM (Embedded Trace Macrocell) は、CPU (ARM CORE) のバスを監視し、トレース信号を外部に直接出力するためのユニットです。ETM はたくさん線が必要なのですが、チップの線は高価 (未確認ですが、1本線が増えるたびに、単価が0.5円上がるという話も) ですし、接続するためのプローブも単価が高いものになります。
ETB (Embedded Trace Buffer) は、その名の通り、ARM SoC 内の超高速メモリです。直接信号を出力するのではないため、トレースデータを取りこぼすこと無くためて置くことができます。ただし、SoC 内のシリコンには限りがあるのでそれほど大容量にはできませんし、JTAG 経由でデータを吸いだす必要があります。特別なプローブが必要無く、JTAG のみで済むというのはメリットでもあります。
簡単ですが、以上を図にまとめると、以下のようになるかと思います。
2009年09月04日
これまで2回に渡ってDalvikVMのインタープリタの部分でFPU命令を使って高速化する変更方法を紹介しました。
残りのCの部分で書いてある部分もコンパイルオプションを変えればFPU命令を使うようになるはずです。ソースをながめてみるとsetjmpの部分でFPUレジスタが退避されていなかったので、そのソース修正も合わせて紹介します。
2009年09月02日
2009年08月31日
AndroidのDalvik VMではJavaのバイトコードから変換されたDXコードというものをインタープリタで実行しています。DXコードの中には浮動小数点演算を行うための命令もあるのですが、現状のDalvik VMではFPU命令を使わずにすべてソフトウェアによる浮動小数点演算のライブラリを呼び出しています。
Android SDKのシミュレータでは実はkernelとqemuはVFPが有効になっているのでFPU命令を使うことができます。そこでインタープリタのコードの浮動小数点の四則演算の部分をFPU命令を使うように書き換えて少し高速化してみました。
2009年08月28日
デバッガの肝の一つとして、ELF バイナリに入ってるデバッグ情報の解析があるのですが、そこらへんはほぼ全て社長と佐藤さんが行ってきたそうです。
私は入社してから今まで、ほぼずっとシミュレータ周りの開発をしてきましたので、どちらかというと PARTNER のコア部分とは少し離れた位置にいます。
しかし、デバッガベンダーに勤めていながら、全くデバッグ情報の解析について知らないというわけにもいかないので、少しずつ勉強していく過程をメモしていこうかと思います。
続きを読む
