#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(void)
int line = 0, cnt;
for (line = 0; line < 10; line++) {
cnt = line * 5;
printf("result=%d\n",cnt);
return 0;
「gdb デバッグしたい実行ファイル名」の場合は GDB が起動しますが、–interpreter=mi または -i=mi オプションをつけると GDB/MI が起動します。-q オプションは起動時に表示されるメッセージを省略します。
GDB を起動します。
GDB を mi モードで起動します。
GDB の場合は (gdb) の後ろで入力待ちになっていますが、GDB/MI の場合は (gdb) の後で改行され、次の行の先頭で入力待ちになっています。
起動できたら、コマンドを入力してデバッグ対象のプログラムを実行してみましょう。
GDB/MI のコマンドには、たいてい同等機能の GDB コマンドがあります。GDB/MI のマニュアルには「The corresponding gdb command is ‘xxx’. 」の形で対応する GDB コマンドを記載しています。ただし、すべてのコマンドに対応する GDB コマンドがあるわけではなく、GDB/MI にしかないものもあります。代表的なものとして「変数オブジェクト」があります。
GDB/MI のコマンド名は、- を先頭と単語の区切りに使用しています。ブレークポイントに関するものは -break- で始まり、データ操作に関するものは -data-、スタックに関するものは -stack-、プログラム制御に関するものは -exec- で始まるなど、カテゴリ分けしているものもあります。
GDB は run で実行します。
GDB/MI では、-exec-run を使用します。
GDB は q コマンドでデバッガを終了します。
GDB/MI では、-gdb-exit を使用します。
次に、今回実装することにした機能について GDB と GDB/MI のコマンドを見ていきましょう。
ブレークポイントを設定する
sample.c の 10 行目にブレークポイントを設定します。
GDB でブレークポイントを設定するには、break (省略形は b) を使用します。
GDB/MI では -break-insert を使用します。ファイル名、行番号は -f オプションで指定します。
コマンドを実行すると ^done が返ってきます。その後ろに、実行結果 (設定したブレークポイントの情報) が「xxx(属性名)=”値”」の形で続きます。どのコマンドに対して何が返ってくるかは GDB/MI のマニュアル ( https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html ) を参照してください。
ここでは「number=”1”」は GDB のブレークポイント番号です。number, addr, file, line の値から GDB の実行結果の文字列「Breakpoint 1 at 0x100000f4e: file sample.c, line 10.」を生成できることがわかります。GDB/MI は IDE でも使われています。IDE では、戻り値のうち必要な情報だけを取り出し、整形して表示します。
ブレークポイントに条件をつける
GDB で条件付きブレークポイントを設定するには、if の後ろに条件を記述します。
ここでは、「変数 line の値が 7 のとき」を条件に指定します。
GDB/MI では -c オプション (condition) を使用して条件を記述します。
テンポラリブレークポイント (一時ブレークポイント) を設定する
テンポラリブレークポイントは、1 回限り有効なブレークポイントです。テンポラリブレークポイントは一度停止したら設定自体が削除されてしまうのが、通常のブレークポイントと異なります。
IDE ではよくある「カーソル位置まで実行」は、カーソルで指定された行にテンポラリブレークポイントを設定すると実装できます。
GDB でテンポラリブレークポイントを設定するには tbreak を使用します。
GDB/MI は、ブレークポイントを設定するコマンド -break-insert に -t オプションをつけるとテンポラリブレークポイントになります。
ブレークポイントで停止した時に得られる情報
ブレークポイントで停止した時に得られる情報も、GDB と GDB/MI では異なります。
GDB では次のように表示されます。
GDB/MI の場合、次のように表示されます。
GDB/MI では、ブレークポイントで停止した時は停止理由が reason=”breakpoint-hit” のように”reason=xx”の形で返ってきます。
停止後に実行を再開する
ブレークポイントやステップ実行で一時停止した後、続きを実行したい場合、
GDB では continue (省略形は c) を使用します。
GDB/MI の場合、 -exec-continue を使用します。
ステップ実行する
ステップ実行は、次の実行行が関数内部の場合、関数の中も 1 行ずつ実行します。このような動作をステップインといいます。
GDB は step (省略形は s) を使用します。
GDB/MI では -exec-step を使用します。
ステップ実行で停止した時は停止理由が reason=”end-stepping-range” となります。
関数単位で実行する
「関数単位で実行する」はステップインとは違い、次の行が関数の場合は、関数内では止まらず関数を実行した後に止まります。このような動作をステップオーバーと言います。
GDB は next (省略形は n) を使用します。
GDB/MI では -exec-next を使用します。
変数の値を表示する
GDB は「print 変数名」(省略形は p) を使用します。
GDB/MI では「-data-evaluate-expression 変数名」を使用します。
nomitory のしくみ
ここまでは、GDB と GDB/MI の話をしました。
ここからは、GDB または GDB/MI を使って、mruby 上の Ruby コードをデバッグするにはどのようにしたら実現できるか述べます。
使用しているサンプルコードは https://github.com/yurie/rubima50/blob/master/rubima2.c です。
ブレークポイントのしくみ
Ruby のコードにブレークポイントを設定しても GDB にはわかりません。一方、C で実装されている mruby 本体のコードに「今 Ruby のどの行を実行しているか」が分かるところがあれば、その情報をもとにブレークポイントを設定できます。
上図は mrubyVM でバイトコードが実行されるときの動作イメージです。
VM のバイトコードを実行しているところで「今実行しているバイトコードは Ruby のコードのどの部分か」が取得できます。
それが、図の「CODE_FETCH_HOOK」のところです。詳しくは、次の code_fetch_hook で紹介します。
code_fetch_hook
mruby.h ( https://github.com/mruby/mruby/blob/master/include/mruby.h ) に定義されている mrb_state 構造体に以下のような定義があります。
code_fetch_hook 関数ポインタに指定された関数は、バイトコードを実行するたびに毎回呼び出されます。(図の CODE_FETCH_HOOK のところです)
ここでは説明の都合上、code_fetch 関数という名前の関数をセットすることにします。以降、code_fetch 関数とはここにセットした関数名を指します。
code_fetch_hook に指定する関数 (code_fetch 関数) の引数は、 以下のようになります。
1 番目が mrb_state 構造体
2 番目がバイトコードなどの情報が入っている mrb_irep 構造体
3 番目が現在実行しているバイトコードへのポインタ
最後が VM のレジスタ
code_fetch 関数内では、この引数の mrb_irep 構造体に入っている情報から、実行している Ruby のファイル名、行番号、変数の値など、デバッグに必要な情報を取り出します。
停止する条件
この code_fetch 関数内で、
現在実行している Ruby のファイル名 = ブレークポイントを設定したい Ruby のファイル名
現在実行している Ruby の行番号 = ブレークポイントを設定したい Ruby の行番号
上記2つの条件が一致したときブレークポイントで止まるようにすると、Ruby コードのブレークポイントが実装できます。
nomitory の場合、この 2 つの条件をブレークポイントの条件式で指定するようにしました。
Ruby コード 1 行はバイトコード 1 行とは限らない
ここでひとつ気をつけなければならないことがあります。
code_fetch 関数は、バイトコードを実行するたびに呼ばれます。つまり、1 行の Ruby のコードが複数のバイトコードになる場合、同じ行に対して複数回呼ばれてしまいます。
ここでは簡単のため 、以下のスクリプト rubima.rb を使用します。
この問題を回避するために、1 行の Ruby コードに対して 1 度しか呼ばれないところに条件付きブレークポイントを設定します。nomitory では、code_fetch 関数が 1 行の Ruby コードに対して 2 回以上呼ばれていないかチェックした後の処理に、条件付きブレークポイントを設定するようにしました。
参考) バイトコードを出力するには -v オプションとファイル名をつけて mruby コマンドを実行します。
実行結果例を以下に示します。
赤丸で囲った部分が Ruby コードの行番号です。3 行目は複数行のバイトコードになっていることがわかります。
ブレークポイントの実装例
GDB (C) の場合
GDB (Ruby) の場合
GDB/MI (Ruby) の場合
ステップ実行のしくみ
GDB の場合はステップインは step コマンド、ステップオーバーは next コマンドでした。当然ですが、この GDB の step, next は C のコードを基準としていますので、Ruby のコードを実行する際には使用できません。
そのため、同等の処理を別途実装します。
早速、実装方法をみていきましょう。
ステップイン
まずはステップインです。ステップインの実現はそう難しくはありません。先ほどの Ruby 用ブレークポイントのしくみを利用できます。
code_fetch 関数内に、ファイル名、行番号を指定しないでブレークポイントを設定すると、ステップインの実装ができます。Ruby のコード 1 行が複数行のバイトコードになっていた場合の対策は code_fetch 関数内で行っているので、ここでは単純に「次に止まるのは次の行が実行されたとき」とみなすことができます。
しかし、ファイル名、行番号を指定しないでブレークポイントを設定すると、プログラムが終了するまで 1 行動作しては止まります。1 行だけ実行したい場合は、一度止まったらブレークポイントを削除しなければなりません。
そこで nomitory では、テンポラリブレークポイントを使用します。テンポラリブレークポイントは 1 度だけ有効なブレークポイントです。step が呼ばれたら、テンポラリブレークポイントを設定して実行します。こうすれば、一度止まった後は再度 step (または next) を呼ばない限り止まらなくなるので、期待するステップインの動作になります。
ステップインの実装例
GDB (C) の場合
GDB (Ruby) の場合
GDB/MI (Ruby) の場合
ステップオーバー
次はステップオーバーです。ステップオーバーは、ステップインの処理を拡張します。
ステップオーバーは関数の場合その中に入りません。さて、今実行している行が関数の中かどうかはどのように判断すればよいでしょうか。
関数の中に入ると変わる値を監視すればよいですね。その監視対象が callinfo です。
callinfo は関数の呼び出しごとに作られる関数スタックで、関数に入ると一つ増え、関数を抜けると一つ減ります。mruby の場合、mrb_callinfo 構造体が mruby.h に定義されています。
実行前にこの callinfo のスタックの深さを取得しておき、callinfo の深さを条件にしたテンポラリブレークポイントを実行します。そうすると、関数の中に入るとはスタックが深くなるためブレークポイントでは止まらず、関数から出るとブレークポイントで止まるようになります。
ステップオーバーの実装例
GDB (C) の場合
GDB (Ruby) の場合
GDB/MI (Ruby) の場合
変数表示のしくみ
最後に Ruby の変数の値を表示する方法を説明します。
GDB で C の変数の値は「print 変数名」で分かりますが、Ruby の変数は認識してくれません。
そこで mruby 側で変数名を引数で渡すと、変数の値を返す関数を作成し、GDB なら print、GDB/MI の場合は -data-evaluate-expression で呼び出します。
この変数を返す関数の中身は次のようなしくみです。
変数に関する情報も mrb_state 構造体にあります。引数で渡された変数名に該当するシンボルを mrb_state 構造体にある配列リストから探して値を取得します。
変数の値を取得するには、Ruby の inspect メソッドを使用します。
ここで気をつけなければならないのが、デバッガの実装に Ruby の関数を使用したときの動作です。inspect メソッドは Ruby の関数のため、デバッグ対象のプログラム同様にバイトコードとして実行され、 code_fetch 関数も呼び出してしまいます。呼び出された code_fetch 関数はデバッグ対象のプログラムではなくデバッガが呼び出した inspect メソッドの実行結果を返します。このようなことが起きないように inspect メソッド実行中は code_fetch 関数を呼ばないようにしておきましょう。
nomitory の場合、IDE の一部として機能しているので、変数ウィンドウに変数一覧を表示するための関数も作成しました。
変数表示の実装例
GDB (C) の場合
GDB (Ruby) の場合
GDB/MI (Ruby) の場合
GDB を使って mruby 上で動作する Ruby のデバッグを可能にする方法を紹介しました。もし、Eclipseでnomitoryを使ってみたくなったら、http://yamanekko.github.io/nomitory/ を参考にインストールしてください。
GDB/MI については資料が容易に見つけられなかったこともあり、紹介しました。
一番苦労したのは Java で CDT を拡張したところですが、さすがに場違いすぎるので別の機会に紹介できればと思います。
mruby を使いはじめたものの、気がつくと周辺整備ばかりしていて、結局 mruby を使ったコードはほとんど書けていません。
ようやくデバッガの目処がついたので、今度こそ mruby を使って何か作ることができそうです。
何かお気づきの点がありましたら、 https://github.com/yurie/rubima50/issues にいただけると幸いです。
最後になりましたが、この原稿は SESSAME メンバー、たいやき部部員のみなさんにレビューしていただきました。この場を借りて御礼申し上げます。(レビューしていただいた後にサンプルコードを追加したので気がついたことがあればこっそり教えてください!)
著者について
チーム yamanekko のサブリーダー (リーダーは猫のちーちゃん)
組込み方面で “たのしい mruby” の実現に向けて日々模索中。
主に組込み向けの mrbgems を作りながら、Eclipse を mruby 用にカスタマイズしています。
最近手がけているのは、EV3RT の API を mruby 用に移植すること。
現時点では mi1 と mi2 の 2 種類がありますが、mi のみ指定すると最新のもの (mi2) が指定されたことになります。 https://sourceware.org/gdb/onlinedocs/gdb/Interpreters.html#Interpreters
引用する際にシンプルに表示したかったため使用しただけです。
まだ何も設定していませんから、ここで試した場合は、プログラムは最後まで実行されて終了します。びっくりしないでね:)
nomitory ではまだ実装していませんが・・・
この機能を使用するには、mrbconf.h で #define ENABLE_DEBUG を有効にします。
Ruby の実装例は https://github.com/yurie/rubima50/blob/master/rubycode.rb と https://github.com/yurie/rubima50/blob/master/rubima2.c を使用しています。
変数一覧を返す関数を mruby 側で作成しておき、 -data-evaluate-expression で呼んでいるだけですが
EV3 用の RTOS(Real-Time Operating System)