コグノスケ

RISC-V QEMUのデバッグ用ビルド方法

目次: RISC-V

たまにRISC-V向けのQEMUの動きを見たいときがあって、デバッグビルドをするのですが、やり方を忘れがちなのでメモしておきます。

$ mkdir build
$ cd build

$ ../configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-softmmu,riscv64-linux-user \
    --disable-docs --enable-debug

...

qemu 5.2.50

                   Install prefix: /usr/local
                   BIOS directory: share/qemu
                    firmware path: /usr/local/share/qemu-firmware
                 binary directory: bin
                library directory: lib
                 module directory: lib/qemu
                libexec directory: libexec
                include directory: include
                 config directory: /usr/local/etc
            local state directory: /usr/local/var
                 Manual directory: share/man
                    Doc directory: /usr/local/share/doc

...

                 thread sanitizer: NO
                         rng-none: NO
                    Linux keyring: YES
                     FUSE exports: NO
                       FUSE lseek: NO

  Subprojects
                    libvhost-user: YES

Found ninja-1.10.1 at /usr/bin/ninja

$ ninja

ビルドが成功するとbuildディレクトリ以下にqemu-system-riscv32やqemu-system-riscv64が生成されているはずです。

Debian TestingとZephyr SDKその1 - 自分でSDKをビルド

目次: Zephyr

開発用のマシンではDebian Testingを使っているのですが、久しぶりにdist-upgradeしたところPython 3.8が消えてしまいました。Python 3.9に移行したみたいです。

アップデート時は「そうなんだ、3.9になったんだな。」くらいの認識でスルーしまいたが、Zephyrを使おうとしたら異変に気づきました。なんとZephyr SDKのGDBが動きません。どうしてこうなった。

$ riscv64-zephyr-elf-gdb
riscv64-zephyr-elf-gdb: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory

Debianは元々Zephyr SDKのサポート範囲に入っていない（Ubuntuのみ）ですし、Debian Testingなんてサポートされるはずがないので、自力で解決する必要があります。

Zephyr SDKのビルド

Zephyr SDKのビルド手順は簡単ですが、Debian Testingだとうまくいきません。

$ git clone https://github.com/zephyrproject-rtos/sdk-ng
$ cd sdk-ng

$ ./go.sh riscv64
./go.sh: 行17: python: コマンドが見つかりません

Pythonが見つからず怒られます。Debian Testingは /usr/bin/pythonがなくなったため、go.shのpythonをpython3に書き換えてあげると動きます。他にもPython 3.8を想定している箇所があるので、Python 3.9に直します。

diff --git a/configs/riscv64.config b/configs/riscv64.config
index 295f2c0..a9fc301 100644
--- a/configs/riscv64.config
+++ b/configs/riscv64.config
@@ -46,5 +46,5 @@ CT_CC_LANG_CXX=y
 CT_CC_GCC_LIBSTDCXX_NANO=y
 CT_DEBUG_GDB=y
 CT_GDB_V_9_2=y
-CT_GDB_CROSS_PYTHON_BINARY="python3.8"
+CT_GDB_CROSS_PYTHON_BINARY="python3.9"
 CT_GDB_CROSS_BUILD_NO_PYTHON=y
diff --git a/go.sh b/go.sh
index e5442fa..7a45fd8 100755
--- a/go.sh
+++ b/go.sh
@@ -14,7 +14,7 @@ fi
 
 COMMIT="d7da3a9c7f0f3a90bb4c71b91aea6cbc2471a541"
 GITDIR=${PWD}
-JOBS=$(python -c 'import multiprocessing as mp; print(mp.cpu_count())')
+JOBS=$(python3 -c 'import multiprocessing as mp; print(mp.cpu_count())')
 
 unameOut="$(uname -s)"
 unameMachine="$(uname -m)"

SDKはbuild/output以下に生成されます。RISC-V 64であればbuild/output/riscv64-zephyr-elfです。生成されたバイナリが動くか確かめましょう。

$ cd build/output/riscv64-zephyr-elf/bin

$ ./riscv64-zephyr-elf-gdb
Segmentation fault

SEGVで死にました。うーん、だめそうですね……。次回以降、直せないかトライします。

Windowsの仮想メモリサイズの謎

目次: Windows

Windowsで「コミット済み」（＝仮想メモリの合計）の値を求める方法がさっぱりわかりません。タスクマネージャーの「パフォーマンス」タブには下記のように値が表示されています。

タスクマネージャー「コミット済み」の例

しかしタスクマネージャーの「詳細」タブに表示される、各プロセスのコミットサイズ（＝仮想メモリサイズのことらしい）を足しても全く足りません。どういうこと？？

タスクマネージャー「コミットサイズ」の例

コミットサイズが全然信用できない例を挙げれば、AMDのRadeonドライバ関連でAMDRSServ.exeというプロセスがいます。このプロセスをタスクマネージャーで見ると「5MBしか使ってないよ」とおっしゃっています。

AMDRSServ.exeのコミットサイズは5MB

ところがプロセスを強制終了させると、突然700MBほど（6.2GB → 5.5GB）仮想メモリが解放されます。700MBも使っているプロセスはありませんでしたが、700MBどこから来た？意味不明ですね。

AMDRSServ.exe強制終了前

AMDRSServ.exe強制終了後

たぶんカーネル側というかドライバ内で仮想メモリをでかく取ると「コミット済み」と「各プロセスのコミットサイズの合計」の乖離が激しくなるんじゃないか？と予想していますが、調べ方がわかりません。

Windowsを使っていて仮想メモリが枯渇するような事態に陥り、調べる必要が出てきたとしても、タスクマネージャーの表示してる「コミットサイズ」は全然信用できないってことです。ひどい作りだなあ、もう。