bfin-gdbproxyのバグの可能性が浮上

By 酔漢 - Last updated: 土曜日, 2月 11, 2012 - Save & Share - Leave a Comment

デバッガのバグという可能性は、最後まで疑いたくない物です。やりたいのはデバッガのデバッグではないので。

これまでの検証作業で、一つ気づいたことがありました。ベアメタル・アプリケーションが使用しているLDファイルは、32kBある命令メモリのうち、実際には下位16kBしか使っていません。と言うことは、ツールチェーンのリリース時に、小さなプログラムでしか試験をしていない可能性があります。そうすると、次のような事が考えられるわけです。

  1. 実はADSP-BF592の命令メモリ上位16kBはキャッシュに構成されており、デバッガから書き込み不能である。
  2. GDB ServerがADSP-BF592の命令メモリ上位16kBに書き込めない。

上の1は十中八九無視してかまいません。Blackfinは共通スペックとしてリセット後にすべてのキャッシュがディセーブルになっています。BF592のマニュアルをさらってみましたが、キャッシュがイネーブルであるという記述がありません。そもそも、BF592は外部メモリを持つことができませんので、キャッシュには意味がありません。

とすると、2です。ツールチェーンのデフォルトのLDスクリプトは、命令メモリの上位16kBをキャッシュと仮定するため、メモリにオブジェクトを配置できません。この制限のため、bfin-gdbproxyに見えないバグが潜んでいる可能性はあります。

試しに、sample1をスリムダウンしてみました。sample1のアプリケーション・タスクのループ内を削り、JSPカーネル内部のポストモーテム・ダンプをリンクから外すと、.textセクションのサイズが16kBを切ります。セクションサイズは以下のコマンドで確認します。

$ bfin-elf-readelf –S jsp

さて、これをbfin-elf-gdbでACB-BF592にロードしたところ、見事にstart:以下にプログラムが現れました。ということは、

bfin-gdbproxyにはバグがあり、命令メモリの上位16kB領域にプログラムをロードしようとすると、全体のロードに失敗する

と言う可能性を否めなくなってきました。

引き続き調べてみますが、Blackfin Koopに投げた方が早い気がしてきました。

類似の問題が報告されていた

Analog DevicesのフォーラムであるEngineerZoneに、 BF592 debug code > 16kBという、そのもののタイトルで同様の問題が報告されています。ただ、報告者は.text + .dataのサイズを問題視しており、R2011では解決積みとしています。私の手元ではR2011でも解決していません。.text + .dataというのは、報告者の勘違いでしょう。

解決しました

問題解決しました。ツールチェーン2011Rでは動作します。詳細はこちら

Posted in GNUツールチェーン • • Top Of Page

Write a comment