デバッグ環境の開発について。GDBSTUBについてとGDBのコマンドについて。

H8/3048Fのソースレベルデバッグでつまづいています。

H8/3048Fでデバッグを行うためにgnu環境で、cygwinを用いてgcc・gdbを構築しました。
バージョンは、
binutils-2.16
gcc-core-3.4.6
newlib-1.13.0
gdb-6.1.1
です。
環境の構築はうまくいきました。
次にH8に書き込むターゲットであるSTUBの作成ですが、http://www.hk1.co.jp/H8b.jsp
のホームページに記載されている3069用のSTUBを参考に3048用にに書き換えH8に書き込みました。

次にコマンドラインでGDBを起動し通信を行うところなのですが、ここのところでつまづいています。

まずはじめに、
set machine h8300h
というコマンドは受け付けませんでした。これはh8300hのアーキテクチャにGDBを有効にするというものだと思うので、
set architecture h8300h
としました。
次に速度の設定として
set remotebaud 19200
としました。
（通信環境は速度19200bps、データビット8、パリティ無し、ストップビット1、通信ポートCOM2）
次にターゲットとして
target hms /dev/com2
としましたが、そこでTIMEOUTエラーとなり通信が行えません。
自分として考えていることなのですが、これは、日立のモニタをターゲットとしているので通信できないのでしょうか？
target remote /dev/com2
としたら、通信は出来ましたので、そうだと思うのですが、確信が持てません。どなたかご存知の方がいらっしゃればご説明をお願いします。

それと、もうひとつ。
target remote /dev/com2
で通信が出来たとして、
load
でプログラムを書き込み、
run
で、開始すると思うのですが、
runコマンドを入力しても、
The program being debugged has been started already.
Start it from the beginning?(y/n)
と表示されyとしても、そこで終わってしまいます。

また、cコマンドでコンテニューするとプログラムは動きますが、ブレークポイントやステップ実行が出来ません．

なにか少しでも知っていることがあれば教えていただきたいです．よろしくお願いします．

No.2 ベストアンサー 回答者： R32C 回答日時： 2007/12/07 16:26

>(gdb) load

>Loading section .text, size 0x1ef lma 0x20200
>Start address 0x20200, load size 495
>Transfer rate: 3960 bits/sec, 61 bytes/wite.
>(gdb) list main

がちょっと寂しいように思います。
まず、仮想ベクタ（ユーザーベクタ）がロードされていないようです。

ユーザーベクター（仮想ベクタ）は、貴殿のダウンロード先の
情報によると　0xffc000になっているようです。

また、0x20200番地にロードされているようですが、そこまで外部RAMを増設した
のでしょうか？

gdbが動作がおかしいため表示されないのか？　それとも
ユーザーベクターやユーザープログラムのマッピングがおかしいか
のどちらかだと思います。

メモリマップとMCUモードはどのようになっていますか？

それから、貴殿のスタブをダウンロードしたURLのtestプログラムですが、
スタートアップにスタックポインタの初期化がないので、ちょっと心配です。

ざっとみましたけど、ここが参考になるかも
http://ytomoweb.hp.infoseek.co.jp/h8gnu/h8gnu.html

この回答へのお礼

お礼の投稿が遅くなってしまい大変申し訳ありません．
まず、自分の増設したSRAMは外部エリア1に割り当てられますので、モード５で使うようにした場合、アドレスは
0x20000～0x3ffff
となっています。
R32Cさんのおっしゃているように20200番地からになっているのは確かにおかしかったです。20000番地にプログラムのベクタ領域にしていますので。

となると、スタートアップルーチンの定義の仕方がおかしかったみたいです。最初から、その部分を書き直し、R32さんの記載していただいたHPのスタブ内で使われているブレークポイントの関数？（USE_Z_PROTCOL)を有効にしたら、設定解除はできるようになりました。
ただ、現在つまずいているのは、そのブレークポイントを設定することによって、今まで動いていたプログラム内で使用されている変数の値がおかしくなり、うまく動作しなくなってしまう、ということです。現在原因をさがしていますが、やはりstub側に原因があるのでしょうか・・・

お礼日時：2007/12/13 10:56

No.3 回答者： R32C 回答日時： 2007/12/13 22:37

1)stubのセクションのロケーションと

ユーザープログラムのロケーションはどうなっているのでしょうか？

かなり、参考にしたURLとは独自の改造をされているそうですが、
2)stubのユーザーベクターは20000Hに変更しましたか？（ROM-stub側）
3)loadを実行時にユーザーベクターは20000Hからロードされ
(gdb) load
.vect : 0x00400000 .. 0x00400054　　（アドレスは違いますが）
.text : 0x00400100 .. 0x0040021c
.data : 0x0040021c .. 0x0040021c
.stack : 0x00400220 .. 0x00400420
Transfer rate: 7040 bits in <1 sec, 880 bytes/write.
(gdb)
こんなかんじでロードされていますか？
とりあえず補足要求です。

かなり、込み入った内容になっていますが、初心者がクリアする
内容ではないと思っていますが、
こんなことで時間を費やすぐらいなら、純正コンパイラ、純正ツール
でやったほうが結果的に早かったりします。
以前私は自分苦労して、gdbを使ってデバッグしましたが、これは当時
gdbしか選択肢がなかったためです。
今は、H8でも、サイズ制限がありますが、無償で利用できるし、
HEWにはシミュレータデバッガがあるので、ある程度それでデバッグも
可能になっています。

この回答へのお礼

そうですね、初心者の自分にはかなり難しい感じです。

stub側のロケーションは、内蔵RAM領域と内蔵ROM領域にしています。
MAPファイルだとこのような感じになっています。
Name Origin Length Attributes
VECT 0x00000000 0x00000100 xr
ROM 0x00000100 0x0001ff00 xr
RAM 0x00fff010 0x00000a00 xrw
STACK 0x00fffa10 0x00000500 rw

プログラム側のロケーションが外部RAM領域0x20000～としています。
前回記述したように、gdbでロードするとstartaddress20000としか表示されないのがひっかかるところですが。

それと、ブレークポイントの設定は、修正してうまく動作するようになりました。参考にしたURLのifdef～endifで囲まれた関数がブレークポイントのコマンドだと思い、有効にしてしまったのが原因であったようです。この
コマンド（シリアル通信ではZ0と送信される）がcontinueした際に送信されてしまい誤動作を起こしていたみたいです。

それを、無効にしたらうまくブレークポイントの動作が行えるようになりました。一応デバッグ環境は完成したと思います。
本当に毎回毎回詳しい説明ありがとうございます。
次はA/D変換を行うプログラムを作成するのが課題です（＾＾；

お礼日時：2007/12/14 10:08

No.1 回答者： R32C 回答日時： 2007/12/05 21:14

>target hms /dev/com2

>としましたが、そこでTIMEOUTエラーとなり通信が行えません。
>自分として考えていることなのですが、これは、日立のモニタをターゲットとしている>>ので通信できないのでしょうか？
>target remote /dev/com2
>としたら、通信は出来ましたので、そうだと思うのですが、確信が持てません。どなた>>かご存知の方がいらっしゃればご説明をお願いします。
想定されているとおりですね。　hmsは、日立モニター用のコマンドで動く場合ですね。
一応HMSでgdbで動かしたこともあります。

>The program being debugged has been started already.
>Start it from the beginning?(y/n)
>と表示されyとしても、そこで終わってしまいます。
ちょっとわかりませんね。.gdbinitだったか初期化コマンドなどあったりしませんか？
実際に動いて終わってるだけかもしれませんね。gdbの操作方法とか理解されてますよね。リストコマンドとか、ブレークコマンドとか？

コマンドのログを出してもらうとわかるかもしれません。


>また、cコマンドでコンテニューするとプログラムは動きますが、ブレークポイントやス
>テップ実行が出来ません．
これは実際に対応されているかどうかダウンロードされたサイトには記載が
ないのでわかりませんが、gdbのバージョンにより、ブレークできないケースが
あることがあるようでそのあたりが臭いかと思います。
以下URLでは、5.2.1を使っていますね。
http://hijiri.yitc.go.jp/mb/index.php?H8%B3%AB%C …

それから、単にgccのバージョンがあっていてもgccを生成したときにパラメータによっ
動いたり動かなかったりすることがあります。
H8　gccについて注意する点として、たとえばTOPPERS/JSPでは、intを32bitになる
ようなパラメータをつけてコンパイラを生成しています。この場合には、gdbでは、
remoteaddress=32 だったかつけないとうまく動かなかったと記憶しています。

この回答へのお礼

R32C様　いつも回答ありがとうございます。やはりstubとGDBのバージョンとの相性かなと感じて現在調べているところです。

もう少し助言をいただければと思い、実際に行った様子をここに載せますね。
$ h8300-elf-gdb sample_LCD2.abs
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions
Type "show copying" to see conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=h8300-elf"...
(gdb) set architecture h8300h
The target architecture is assumed to be h8300h
(gdb) set remotebaud 9600
(gdb) target extended-remote /dev/com2
Remote debugging usigng /dev/com2
0x000013b8 in ?? ()
(gdb) load
Loading section .text, size 0x1ef lma 0x20200
Start address 0x20200, load size 495
Transfer rate: 3960 bits/sec, 61 bytes/wite.
(gdb) list main
56LCDOut4(*str);
60str++;
61}
62}
63int main(void)
64{
65wait(15);
66Init_LCD();
67LCD_DISP("TEST");
68
(gdb) b 66
Breakpoint 1 at 0x203d2: file sample_LCD2.c, line 66.
(gdb) c
Continuing.

ここで、停止してしまいます。ブレークポイントを設定していますので、そこでまた、コマンド入力画面にもどると思うのですが、
何かわかることがありましたら、よろしくおねがいします。

お礼日時：2007/12/07 08:50