この従来の Fortran コードを A9 プロセッサを搭載したボードで実行していますが、gdb を使用すると奇妙な動作をすることに気付きました。全停止モードの場合、スレッドは引き続き実行され、非停止モードに切り替えると gdb がクラッシュするようです。また、Fortran コードのシンボルでウォッチポイントを実行することもできません。これがポートによるものなのか、バイナリが同じツールチェーンに属していないためなのかはわかりません。ただし、C 型としてキャストされたアドレスにウォッチポイントを設定することはできます。
rootfs ビルド中にステージ ディレクトリにインストールされた CodeSourcery からのツールチェーン バイナリを取得し、アプリケーション ビルドの一部として、Linaro バイナリが targetroot のライブラリの一部を上書きします。上書きされるライブラリは、アプリケーションに必要なライブラリ (の一部?) と、アプリケーションがリンクされているライブラリ (libstdc++、libgfortran、および libpthread) だけです。
CodeSourcery または Linaro の gdb を使用しても同等に機能するように見えますが、Linaro コンパイラでハードウェア支援ウォッチポイントを設定しようとはしませんでした。どちらも、文書化された動作の外で動作するように構成されているようには見えません.
それでいいの？つまり、実行されますが、gdb が少なくともわずかに壊れている場合、他のユーティリティが何であるかわかりません。Eclipse+Photran と TCF Agent の利用について知りたいのですが、CodeSourcery ツールチェーンがどこから来たのかを調べていたところ、Yocto にたどり着きました。自宅で Yocto を使用していくつかのビルドを試してみましたが、このすべてがセットアップされた VM を持ち込んで、rootfs に組み込まれたツールチェーンを使用してアプリケーションを最初から実行してみる価値があるかどうか疑問に思っています。
何かを切り替えるにはおそらく遅すぎますが、よりスムーズな作業環境を手に入れることができれば、修正を提出するときにソースを現在のソリューションに戻すことができます.