前編の ZYNQのLinuxアプリをVSCodeでビルドする方法 でビルド方法を紹介したので、次はデバッグできるようにしましょう。
VSCode側の設定
C++のプログラムを編集している画面でF5を押します。Launchのキーだそうですが、launchがまだ設定されていないので下のようなメニューが開きます。GDBかWindowsかはどちらでもいい(どうせ後で書き換えるから)のですが、とりあえずはC++ (GDB/LLDB) を選んでおきましょう。
launch.json が作られるので、以下のように書き換えます。
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Remote unit test",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}\\${fileBasenameNoExtension}.elf",
"MIMode": "gdb",
"miDebuggerPath": "D:/Xilinx/SDK/2018.3/gnu/aarch32/nt/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gdb.exe",
"miDebuggerServerAddress": "cszmini:9999",
"args": [],
"cwd": "${workspaceFolder}",
"stopAtEntry": false,
"setupCommands": [
{
"description": "gdb の再フォーマットを有効にする",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
]
}
環境に応じて書き換えるべきポイントは以下の2点です。
デバッガのパスの設定
Windows上のARM用GDBのパスを指定します。
"miDebuggerPath": "D:/Xilinx/SDK/2018.3/gnu/aarch32/nt/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gdb.exe",
ターゲットのアドレスの設定
ターゲットのIPアドレス(またはホスト名)と、ポート番号を指定します。
"miDebuggerServerAddress": "cszmini:9999",
"miDebuggerServerAddress": "192.168.1.4:12345",
のようにします。
とりあえず実行
F5を押すとlaunchに書かれたコマンドが実行されます。この時点ではターゲットボードでLinuxは動いていないのでエラーダイアログが出ます。
Linux側の準備
apt install gdbserverで、gdbserverをインストールしておきます。
Linuxのシェル上で、
# gdbserver localhost:9999 ./test.elf
と入力します。上のコマンドはgdbserverを起動して、ポート9999で待ち受けてtest.elfをアタッチします。
VSCodeでいざLaunch
いよいよVSCodeでF5を押してデバッグ開始です。
VSCode上でgdbが起動し、リモートのターゲットボードに接続されます。ステップ実行や変数の参照ができ、デバッグできるようになります。
対するLinux側ではプログラムがリモート操作されてステップ実行されています。
プログラムが終了するか、VSCodeで □ を押すと終了します。
もっと便利にしたい
ユーザ作成のライブラリを使う
ユーザが作成したライブラリを使うには、プロジェクトのフォルダにライブラリを入れ、tasks.jsonのargsに-Lと-lオプションを追加します。次の設定ではcszapiというライブラリが使われるようになります。
"args": [
"-g",
"${file}",
"-L${workspaceFolder}",
"-lcszapi",
"-o",
"${fileDirname}\\${fileBasenameNoExtension}.elf"
],
また、ヘッダファイルのIntelliSenseが動くようにするにはc_cpp_properties.jsonを編集して、インクルードパスを通すようにします。
これでユーザ作成のライブラリが使えるようになります。
ビルドが終わったら自動的にターゲットにコピーしたい
クロスコンパイルなので、出来上がったプログラムはターゲットボード上にコピーしなければなりません。毎回毎回scpや、エクスプローラでCTRL+C,CTRL+Vするのも面倒なので、tasks.jsonに自動化の処理を書いてあげましょう。
tasks.jsonは、"tasks": [で複数のタスクを登録できるようになっていますが、"group": { "kind": "build", "isDefault": true}が付いているタスクが CTRL*SHIFT+B で実行されるようになっています。
また、各タスクには "dependsOn": というパラメータが設定できて、これを使うとタスクの依存関係を設定できます。
つまり、ターゲットボード上にファイルを転送するというDeployというisDefaultなタスクを作り、DeployはBuildに依存するようにすれば、CTRL+SHIFT+Bでビルドとファイルコピーが可能になります。
{
// tasks.json 形式の詳細についての資料は、
// https://go.microsoft.com/fwlink/?LinkId=733558 をご覧ください
"version": "2.0.0",
"tasks": [
{
"label": "Deploy",
"type": "shell",
"command": "cp",
"args": [
"${fileDirname}\\${fileBasenameNoExtension}.elf",
"\\\\cszmini\\Share"
],
"problemMatcher": [],
"dependsOn": "Build by ARM g++",
"group": {
"kind": "build",
"isDefault": true
}
},
{
"type": "shell",
"label": "Build by ARM g++",
"command": "D:/Xilinx/SDK/2018.3/gnu/aarch32/nt/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-g++.exe",
"args": [
"-g",
"${file}",
"-L${workspaceFolder}",
"-lcszapi",
"-o",
"${fileDirname}\\${fileBasenameNoExtension}.elf"
],
"options": {
"cwd": "D:/Xilinx/SDK/2019.1/gnu/aarch32/nt/gcc-arm-linux-gnueabi/bin"
},
"problemMatcher": [
"$gcc"
],
"group": "build"
}
]
}
dependsOnの参照はlabelを使って行われるようです。
F5でビルドとgdbの起動ができるようにしたい
launch.jsonのconfigurationsに登録されたタスクに、"preLaunchTask": というパラメータを設定しておけば、このタスクが実行される前に実行すべきタスクを指定できます。
したがって、"preLaunchTask": "Deploy"と書けば、GDB接続の前にDeployタスクが実行されて、ビルドとファイルの転送が行われます。
しかし、Linux上ではgdbserverプロセスを走らせなければならないのですが、このgdbserverを起動する前にtest.elfはターゲットボード上になければなりません。また、gdbserverを停止するにはリモートで接続してプログラムが終了するかkillするしかなく、ちょっと面倒です。
結論を言うと、preLaunchTaskを書いてビルドを自動実行するのではなく、リモートデバッグの場合は「ビルド＆ファイル転送」と「デバッガ起動」は分けたほうがいいです。
少々面倒ですが、プログラムを書いてからそれを実行するまでに
-
CTRL+SHIFT+Bでビルド＆実行ファイル転送 - Linux上でgdbserver起動
-
F5でデバッグ開始
と、3ステップ必要です。gdbは巨大なプログラムだから、ちゃんと調べればファイル転送できるのかな？
GLIBCのバージョンが合わないとどうなる？
GLIBCのバージョンが合わない場合、つまりUbuntu 14のシステムをXSDK 2019.1に入っているarm-linux-gnueabihf-gdbでデバッグしようとすると、
readchar: Got EOF
というエラーが出てGDBが接続できません。
実際にやってみると
こうなります。
まとめ
VSCodeでZYNQのLinuxで動くARMのプログラムが書けて、デバッグまでできるようになりました。
これでXSDKを卒業できるかな！？