WinGDB + VS2017を使用したブレークポイントの問題

Question

私はTI MSP430マイクロコントローラ用にCを開発しており、TIのIDEおよび独自のツールチェーンからSublime Text + make + gccのよりunix-yワークフローに移行しました。私は今、WinGDB（Visual Studio with gdb backend）でデバッグをセットアップしようとしています。バックスラッシュ/フォワードスラッシュの問題があると思われるブレークポイントにはこの問題が1つありますが、修正方法はわかりません。

私は、ステップスルービューの解体などをすることができ、問題なくデバッグを開始することができます。しかし、私はF9を使用して、ソースファイルにブレークポイントを設定しようとすると、それはhovertextで無効として表示：

The breakpoint will not currently be hit. No source file named d:Documentsccs workspacesmsp430 scratch\013cxmain.c. 

Location: main.c, line 13 ('main(void)') 

しかし、WinGDBデバッガシェルでgdbコマンドを使って作業ブレークポイントを設定してクリアすることはできますが、ソースの隣に小さな赤い丸が表示されることはありません。

main.cへのパスはD：¥Documents¥ccs workspaces¥msp430 scratch¥vcx¥main.cです。エスケープシーケンス\ vは垂直タブに対応しているか、アスキーでは\ 013の8進数に対応しています。だから私は、バックスラッシュがどこかで何かをねじっていると推測しています（窓に感謝します）。

この問題を解決するにはどのようなアイデアが必要ですか？

Answer 1

あなたのエラーは通常、コードがコンパイラによって最適化されたときに生成されます（a = 2;など）。しかし、主な問題（s）はあなたのクロスツールチェーンに関連している可能性が - このlinkにWinGDBに実装クロスツールチェーンは、ARMためCodeSourceryのG ++ Liteのツールチェーンでは、あなたのマイクロながら、MSP430 は、ARMデバイスではないです。 （ARMデバイスであるMSP432があります）。 多分あなたはこれを見ることができます：www。 Arduinoに似たEnergia.nuは、MSP430のいくつかのバージョンで動作します。

Answer 2

ファイルに生成されたデバッグレコードで、デバッガにどのファイルがどのオペコードのグループになったのかを伝える正しいことです。あなたが前方を使用するようにビルドプロセスを変更しようとすることができ

は、あなたのツールチェーンをGCCそれがD:/Documents/ccs workspaces/msp430 scratch/vcx/main.c という名前のファイルを見つける必要があります基づいているので、どこでもスラッシュしかし、あなたはまた、理由はあなたのパスにスペースの問題を抱えているプロジェクトを再構築する可能性がありますすべてのスペースがアンダースコアに置き換えられます。つまり、D:\Documents\ccs workspaces\msp430 scratch\vcx\main.cがD:\Documents\ccs_workspaces\msp430_scratch\vcx\main.cなどに移動すると、のスペースがすべての問題を引き起こす可能性があります。パス内のスペースをエスケープすることは可能ですが、パスを避けるだけの方が良いでしょう。

私はまた、Code::Blocksを見てみることをお勧めします。VSとはかなり違いますが、クロスプラットフォームと組み込み開発用にIDEとデバッグ環境を提供することははるかに良い仕事です。 フリーでクロスプラットフォームでオープンソースそのものです。 GDBと非常によく似ており、プロジェクトで使用するビルドツールチェーンをカスタマイズすることができます。それには、MSP340用のGNU GCC、などの多くのプリセットも付属していますので、が非常に役立ちます。