wxWidgets によるプログラミングは細々と続けています。制作は主に Mac/Xcode 上で行い、動くようになったらクロスコンパイラで Windows 32bit/64bit 版をそれぞれ作成し、VMWare 上の Windows で動作確認する、という流れです。クロスコンパイラ（mingw-w64）の環境整備は以前に書きました：「Mac OS 10.14 で wxWidgets 開発（その１）」「（その２）」。
Windows 上の開発環境は、MSYS2 版の mingw-w64 です。以前はこの環境で Windows 用バイナリをビルドしていたのですが、Mac 版の mingw-w64 によるクロスコンパイルが十分に実用的なので、現在はビルドシステムとしては使っていません。
ただ、デバッグの環境は、どうしても Windows 上でやらないといけないのです。そこで、MSYS2 のターミナルを開いて、そこで gdb を立ち上げていました。
wxWidgets 関係のプロジェクトをまとめたフォルダ wxMyProjects を VMWare で共有しています。これは Windows 上では z:wxMyProjects としてアクセスできますが、実際に cd すると //vmware-host/Shared Folders/wxMyProjects という名前になります。途中に半角スペースが入っているのが絶妙にウザいのですが、まあ今のところ大きな実害はないようです。
ブレークポイントを設定したいのですが、Mac と Windows でフォルダの構成が違うので、ソースコードが見つかりません。これは、ホームディレクトリの .gdbinit ファイルに下のように指定することで、解決できます。substitute-path の次に書くのが Mac 上でのフォルダパス、その次に書くのが Windows 上でのフォルダパスです。なお、MSYS2のホームディレクトリは、MSYS2のインストールディレクトリの中の home/ユーザー名 というディレクトリです。
set substitute-path /Users/nagata/Development/wxMyProjects z:/wxMyProjects
これでソースコードデバッグができるようになります。
走っている Windows プログラムを止めて GDB に制御を移すには、F12 を押します。VMWare 上の Windows でもちゃんと機能しました。
一応これでデバッグ作業はできるのですが、一つ大きな問題があります。MSYS2 のターミナルと GNU readline の相性が悪くて、タブ補完やヒストリ機能がまるっきり使えないのです。これは作業効率を著しく落とします。また、gdb が「y or n」で聞いてくるところをスキップされることもあります。例えば、プログラム動作中にブレークポイントで止めて、そのまま GDB を終了させると、普通は「y or n」で確認を求められるのですが、この環境だと問答無用で Yes と答えたことになってしまいます。「ハイかYesで答えなさい」ってやつかよ。「input not from terminal」とか言ってますけど、こっちはターミナルのつもりなんですが……
これを回避するため、いろいろ調べたのですが、実は解決法は簡単でした。MSYS2 のターミナルじゃなくて、Windows の PowerShell を使えばいいのです。
背景色が邪魔で一部情報が読めなかったりしますが、これは設定を変えればいいだけなので、大きな問題ではありません。
PowerShell で MSYS2 のコマンドを使うためには、パスを通しておく必要があります。スタートメニュー→設定→システム→詳細情報（左の列の一番下）→システムの詳細設定→環境変数→ユーザー環境変数の Path を選んで編集→ C:\msys64\mingw64\bin\ を追加、という手順です。これはスクリーンショットで説明するほどでもないでしょう。
emacs の GDB モードも使えることがわかりました。
ソースコードが表示できます。画面上でブレークポイントの設定もできます。ただ、PowerShell 上の gdb に比べると、動作がかなり遅いので、常用するには厳しいかなと思っています。ソースコード自体は Xcode で見ればいいしね。
