ARMv5ボードで開発していて、Intel MacOSXを使用してプログラムをデバッグしようとしています。
Linuxで問題なく試してみました（gnueabiツールチェーンを使用してバイナリをコンパイルしました）。ボード上でgdbserverを実行し、ホストマシン上で接続しましたが、すべて問題ありませんでした。
しかし、Mac OS Xでは、はるかにトリッキーなようです。ARMターゲットにもクロスコンパイルされたgdbが必要だと思いますが、すべてのツールチェーンをインストールしたくありません。
Mac OSはiOSリモートデバッグをサポートしているので、ARMリモートデバッグに使用できるgdbはありませんか？
そして別の質問：リモートデバッグのためにクロスコンパイルされたデバッガーが必要なのはなぜですか？アーキテクチャに依存せずに、サーバーとクライアントがネットワークで通信することはできませんか？
ありがとうございました。
正しいアーキテクチャ用に構成されたビルドgdbだけでなく、オブジェクト ファイル タイプも必要です。GNU/Linux システムが ELF を使用するのに対し、MacOSX/Darwin は MachO オブジェクト ファイルを使用することに注意してください。
を使用する場合gdbserver、gdbは開発ホストで実行され、ターゲットに対応するシンボル マップを構築するために実行可能ファイルとライブラリを読み取ります。gdbApple が出荷する (Darwin および MachO バイナリ用に構築された) が機能しないのは、このためです。
なぜ現状のままなのかというと、これは のアーキテクチャ上の制限でありgdb、binutilsついでにgcc言えば、一度に 1 つのターゲット環境しか処理できないためです。
リモート デバッグ シナリオでは、多くの場合、リンク トラフィックとターゲット メモリ フットプリントを最小限に抑える必要があります。通信リンクは、低速のシリアル回線である場合があることに注意してください。このため、可能な限り、gdbserver非常に低レベルの操作を処理する開発ホストで実行されます。
MacOSX 用の cross-gdb 環境を構築しても、特定の問題は発生しません。
Mach-O オブジェクト形式を使用しない限り、Apple ツールはほとんど役に立ちません。独自のツールチェーンを構築する必要があります。Macports がインストールされている場合、arm-elf-eabi ツールチェーンのポートが含まれているため、これは簡単です。http://www.macports.org/ports.php?by=name&substr=eabiを参照してください。