日報 2024.12.15
エリート飯。
電光表札ソフトウェア開発続き。
ずっと挑戦していたPi Zero向けクロスコンパイル、なんと有志の方が作っていただいているPi Zero用のコンパイラを使ったら一発で成功した。マジで感謝。もうこれでええわ。
armv6-rpi-linux-gnueabihf の GCC 14.2 x86-64 をダウンロード。
WSL経由でコンパイル実行。
armv6-rpi-linux-gnueabihf-g++ main.cpp
正常終了してa.outが出力されるのでPi Zeroに転送して実行…
イッた…！ 長い戦いにようやく終止符。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
./a.out Hello World i = 0 i = 1 i = 2 i = 3 i = 4 i = 5 i = 6 i = 7 i = 8 i = 9 |
たぶんなんですが、ARM公式で落とせるコンパイラには –with-mode=thumb オプションが入ってるのですが、こいつを抜いたコンパイラをビルドしてARMv6向けに作ればいけそう…？な感じがしている。
ああ、次はデバッグだ…。先ほどの有志のありがとうコンパイラにはgdbが無かったのでgdb-multiarchを使うといけそう。
WSLでgdb-multiarchのインストール。
$ sudo apt install gdb-multiarch
先日見た記事を参考にGDBデバッグ用ファイルを作る。
|
1 2 3 4 5 |
target extended-remote ラズパイのIP:5555 file ./a.out remote put ./a.out /home/d0/unko/a.out(ラズパイ側の実行ファイルパス) set remote exec-file /home/d0/unko/a.out(ラズパイ側の実行ファイルパス) start |
ラズパイでgdbserverをインストールして実行しておく。
|
1 |
$ sudo apt install gdbserver |
|
1 2 |
$ gdbserver --multi :5555 |
WSL側でデバッグ実行。
|
1 |
$ gdb-multi -x gdb_load |
イッた。
|
1 2 3 4 |
Temporary breakpoint 1, 0x00010584 in main () (gdb) n Single stepping until exit from function main, which has no line number information. |
WSL環境状態でプロジェクトを開きたいので、.code-workspaceを作って"remoteAuthority": "wsl+ubuntu" オプションをいれると行けるっぽい。wsl+ubuntuのとこは自分のwsl環境に合わせて適切に変える。
|
1 2 3 4 5 6 7 8 9 |
{ "folders": [ { "path": "." } ], "remoteAuthority": "wsl+ubuntu" } |
vscodeでワークスペースを開くと自動的にWSL環境で開始した。
が、ターミナルを開こうとするとカレントディレクトリがWindowsのパスになっててエラーになる。
code-workspace に terminal.integrated.cwd を追加してWSL側のパスを直接指定して対処。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "folders": [ { "path": "." } ], "remoteAuthority": "wsl+ubuntu", "settings": { "terminal.integrated.cwd": "/mnt/d/Users/dO/Data/Programming/Projects/murohouse-nameplate/testdbg", } } |
WSLのフルパス直接指定するのダサい。 ${workSpaceFolder} を使ってなんとかしたいけど、どうしてもWindows側のパスを取って来てしまうので今のところ対処しようが無かった。諦めてフルパス記入…。
まあ .code-workspace はユーザー環境設定ということで割り切って諦める。
- 自動でRemote WSLするVScodeのworkspaceを設定する #VSCode – Qiita
- terminal.integrated.cwd / ${workspaceFolder} does not work on WSL Remote (V2 on Ubuntu 20.04) · Issue #133981 · microsoft/vscode
で、ワークスペースをvscodeで開くとWSL状態で開くようにはなったが、
launch.jsonとかで ${workspaceFolder} を使うとやっぱりWindows側のパスを取得して来てしまうのでどうにも都合悪いので remoteAuthority は結局やめ。
remoteAuthority使わない方法をサーベイ。
remoteAuthority関連の設定を消して、.code-workspace にsettingsを追加してデフォルトのターミナルをwslに変更。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "folders": [ { "path": "." } ], "settings": { "terminal.integrated.defaultProfile.windows": "Ubuntu (WSL)", "terminal.integrated.profiles.windows": { "wsl":{ "path":["C:\\Windows\\System32\\wsl.exe"] } } } } |
VScodeでワークスペースを開き直すとターミナルがwslになっていることを確認して、code .とコマンドを実行すると新規のVSCodeウィンドウが開いてWSL環境でワークスペースが開く。毎回このコマンドを打たないといけなくなるのは我慢。良い案あれば情報求む。
プロジェクトのディレクトリに .vscode/launch.json を追加して設定を以下のようにする。
setupCommands の部分は作ったgdb_loadの中身。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
{ // 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": "(gdb) Launch", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/a.out", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "gdb-multiarch", "setupCommands": [ {"text": "target extended-remote 192.168.100.19:5555"}, {"text": "file ./a.out"}, {"text": "remote put ./a.out /home/d0/testdbg/a.out"}, {"text": "set remote exec-file /home/d0/testdbg/a.out"}, ] } ] } |
remoteAuthorityじゃないWSL環境の場合は ${workspaceFolder} がちゃんとWSLパスで取得できる。
Pi Zeroの方はあらかじめ gdbserver を実行しておき、VSCodeでF5でデバッグ実行。
イッた…。VSCodeのGUIで貼ったブレークポイントでちゃんとブレークできます。
ちなみにg++のコンパイル設定で -O0 -g3 を追加して最適化無効とデバッグ情報を付与する必要があるので注意。
ここまで行けたらMakefileの作成と、VSCodeのF5だけでビルド&デバッグ実行できるように整理していくだけ。
エリート飯。
本当に迷惑かけてます。すいません。
申し訳ないです。
おわい
