## 会話の概要

### ユーザーの目標
`node vm.js` で実行できるよう、doomgeneric_mips という名前の MIPS リトルエンディアン ELF を構築する。stdout が動作し、提供された doomgeneric_img.c（および `/app/doomgeneric/` 以下の doomgeneric ソース）を使用してフレームが `/tmp/frame.bmp` に書き込まれること。

### 実装内容

1. JS VM 向けフリースタンディング libc（`/app/mips_freestanding/`）
   - VM は Linux スタイルのオープンフラグを実装しているが、syscall 番号は本物の MIPS Linux ではない（0=read, 1=write, 2=open, 3=close, 8=lseek, 201=time, 38=rename, 39=mkdir）。通常の mipsel-linux-gnu-gcc + glibc は 4003+ スタイルの番号を使用するため動作しない。
   - `my_libc.c` + `vm_syscall.h`: 上記 syscall に加え、最小限の `malloc`/`free`/`realloc`、`stdio`（`fopen`/`fread`/`fwrite`/…）、文字列操作、`printf` サブセット、`qsort`、`sin`/`atan`/`fabs`、`strdup`、`abs`、`system` スタブなど。

2. `doomgeneric_img.c`（`/app/doomgeneric/doomgeneric/` 以下）
   - `my_stdlib.h` を使用。
   - `DG_DrawFrame`: 全フレームを `/tmp/frame.bmp`（32 ビット BMP）に書き込む。
   - `main`: 安全な `argc`/`argv`（null の場合はフォールバック argv）、その後 `doomgeneric_Create` → 無限 `doomgeneric_Tick()` ループ（他の doomgeneric フロントエンドと同じパターン）。

3. ビルド — `/app/doomgeneric/doomgeneric/Makefile.mips`
   - `mipsel-linux-gnu-gcc`、`-fno-pic -mno-abicalls`、`-static -nostdlib`、`-Wl,-e,main`、`libgcc` をリンク。
   - 非 PIC が必要な理由: `$t9` が未設定の状態で `main` にエントリすると GP 相対 GOT が壊れるため、非 PIC で解決。
   - オブジェクト: xlib の代わりに `doomgeneric_img.o` を含む doom の全オブジェクトリスト。`deh_str.o` なし（ヘッダーのみ）。
   - `i_system.c`: `DEFAULT_RAM` / `MIN_RAM` は `-D` フラグで上書き可能。ビルドでは VM 向けにゾーンを縮小するため `-DDEFAULT_RAM=4 -DMIN_RAM=4` を使用。
   - 出力: `/app/doomgeneric_mips`。シンボルを削除しないこと — VM は `.symtab` から `main` を解決する。

4. `vm.js` の変更点（もう一方のアシスタントへの重要事項）
   - OOM: プレーンな `{}` メモリは doom が多くのワードにアクセスした際に V8 をクラッシュさせた。
   - `runElf`: `Uint32Array` の低 RAM（`0x400000` から 96MB）+ スタック（`0x7f800000` から約 8MB）を確保し、`.text`/`.data`/`.rodata` を低バッファに読み込み、巨大な `memory` オブジェクトの代わりに `{ lowMem, stkMem, memLowBase, …, entry_point }` を返す。
   - `MIPSVM`: `memGetWord` / `memSetWord` がそれらのバッファを経由するよう変更。ストア用の疎な `this.memory` は事実上廃止（OOM 修正）。`memGetWord` の範囲外アクセス → 0（バグを隠す可能性あり）。
   - すべての `lw`/`sw`/バイトヘルパーおよび `runProgram` の命令フェッチが `memGetWord`/`memSetWord` を使用。スクリプト末尾で `runElf` から `vm._lowMem` 等を接続。

### エラーと修正（概要）
- syscall の不一致 → カスタム libc + VM syscall 番号。
- リンクエラー → `strdup`、`strstr`、`abs`、`putchar`、`puts`、`atof`、`system`、`remove`/`rename` を追加。存在しない `deh_str.o` を削除。
- エントリ直後のクラッシュ → `-fno-pic -mno-abicalls`。
- Node OOM → ArrayBuffer バックの VM メモリ。無制限の `this.memory` 書き込みを削除。
- `r_segs.c`: `SHRT_MAX` → `limits.h` に追加。

### 未解決の問題 / 次のアシスタントへのタスク
- `/tmp/frame.bmp` はテスト中に一度も生成されなかった。実行は `Program terminated at PC=0x400151`、`Executed 626581578` 命令で終了。`0x400150` は `abort` シンボル（自己ループの tight branch）。つまり何かが最終的に `abort` にジャンプしており、フレームを描画するクリーンなゲームループになっていない。
- 4MB ゾーン（`DEFAULT_RAM=4`）は実際の IWAD プレイには小さすぎる可能性がある → `Z_Malloc` / OOM 系の失敗やその他の未定義動作が発生しうる。`DEFAULT_RAM=6` の試用、`my_libc.c` の `HEAP_SIZE` を増やすこと（14MB に削減されていた）、`memGetWord` の範囲外アクセスが実際の障害を隠さないようにすることを検討する価値がある。
- 具体的な次のステップ: `abort` を呼び出している箇所を特定する（例: trap、libgcc パス、アロケーション失敗）。非 Windows での I_Error パスを修正する（現在 `ZenityErrorBox` / 異常なパスを呼び出している可能性あり）。`doomgeneric_Create` → `D_DoomMain` → … → `doomgeneric_Tick`/`D_Display` → `DG_DrawFrame` の呼び出し経路を確認する。VM 内で `fopen("/tmp/frame.bmp","wb")` + `SYS_close` のフラッシュを検証する。`/tmp/frame.bmp` が生成され stdout が正常に見えるまで再実行する。

### パス
- ELF: `/app/doomgeneric_mips`
- ビルド: `/app/doomgeneric/doomgeneric/Makefile.mips`
- フロントエンド: `/app/doomgeneric/doomgeneric/doomgeneric_img.c`
- Libc: `/app/mips_freestanding/my_libc.c`、`/app/mips_freestanding/include/*`
- VM: `/app/vm.js`（メモリモデルにパッチ適用済み）
- ローカルで使用した IWAD: `/app/doom1.wad`（テスト用）