reli-sendaiphp-20260313

2026 年 3 月 13 日の第 2 回仙台 PHP 勉強会で使ったスライド

Transcript

1. PHP で PHP 処理系の情報を読みとるツールの近況 Claude Code で stripped ZTS binary 対応を進めた話 @sji_ch 1
2. 自己紹介 sji という名前を使うことが多い 仙台在住、生まれも育ちも仙台 現在は株式会社カオナビにて、 フルリモートで働いてます Reli という PHP 製の PHP プロ ファイラを作っています 2
3. これまでの Reli 発表 PHP で PHP のプロファイラをつくろう（PHPerKaigi 2022 ） PHP で PHP のメモリプロファイラをつくろう（PHP Conference Japan 2023 ） PHP で読む楽しいコアダンプ（PHPerKaigi 2024 ） 3
4. その後 その後 1 〜2 年くらいほぼ触っていませんでした やる気が出ずグダグダしていました 4
5. 今日の話 Reli の超短いおさらい 今回ぶつかった問題 stripped ZTS binary 対応でやったこと Claude Code が何に効いたか 5
6. Reli とは https://github.com/reliforp/reli-prof PHP 処理系が何をしているかを外から読むための CLI ツール 無修正のスクリプトの挙動を観測したい 拡張入れるとかライブラリ入れるとかしない 実行中の処理系プロセスのメモリ内容やコアダンプを解析する FFI 経由で C 言語と同様にシステムコールを呼んだり メモリ上の処理系内 C 言語構造体を PHP で解析したり 6
7. 何がうれしいか 中で何が起きているか見たい ハングや詰まり方の調査に使いたい 性能やメモリの様子を外から観測したい 7
8. そこそこできてたこと ゲテモノだが案外動いてた 性能計測 トラブルシュート メモリ使用状況の確認 8
9. できてなかったこと スレッドセーフ版（ZTS ）の PHP 処理系の対応 デバッグビルドについては 対応できていた かつて ZTS の PHP 処理系は利 用シーンがあまりなかった 比較的新しい PHP ランタイム FrankenPHP が ZTS 前提 docker から使えるのがデバ ッグ情報のない本番ビルド 9
10. stripped ZTS binary をやっつける 10
11. binary ？ 人間向けのテキストデータじゃないやつ マシンが実行するための機械語で書かれた実行ファイルとかはバイナリ 実行ファイルは大本はバイナリでなくテキストデータだったり C のようなテキスト言語のソースコードを機械語のバイナリに変換 11
12. stripped とは 解析の手掛かりになる名前情報（シンボル情報）が落ちている状態 ソースコード上のどの名前がバイナリのどの部分、という痕跡 処理系のファイル容量はやや軽くなる でも読む側は困る そりゃ誰も不法にバイナリ読むやつに配慮しないよね 12
13. stripped で何が困るか 名前で引けない部分がある 実行時に必要ない部分が消える 一部の名前情報は実行にも必要なので strip しても残る この範囲で用が足りてればそれでいい 実行には必要ないが外からの解析には必要、という情報があると困る 別の足掛かりが必要 13
14. ZTS とは マルチスレッド対応版の PHP 処理系 スレッドごとに別々の処理系内部情報を持つ 欲しい情報がスレッドごとに分かれる 場所の辿り方が素直でなくなる 14
15. ZTS で何が困るか スレッドごとの領域（TLS ）をちゃんと見ないといけない 「TLS 内の何バイト目に処理系内部状態があるか」が strip で消える 実際には処理系内部状態へのポインタ、たった 8 バイトのデータ 処理系内部情報へたどり着けなくなる 通常の処理系（非 ZTS ）では strip で消えない情報で全部足りてた部分 デバッグビルドに限っては strip されないので ZTS でも対応できてた 15
16. つまり今回の問題 名前で引けない 欲しい場所も素直に分からない それでも中を読めるようにしたい 16
17. 嘘ついたわ 本当の問題はやる気 やる気さえあれば可能、という手は思いついていた 処理系バイナリをじっと見つめてたらある日に思いついた PoC まで作って「お、動くじゃーん」となり満足 そこから余裕の 2 年くらい放置 17
18. 久しぶりに触ってみた きっかけ Claude Code のチャットに Reli の話を振ってみていた 実装継承やってる箇所をな んとかしたいんだよなーみ たいな、関係ない話 わりと会話の成立が楽しかった PHP でメモリを読もうみた いなニッチな話の通じる相 手があまりいない 18
19. 今回の基本方針 一発で正解を引くのは諦める 候補を探す 候補が本物っぽいか検証する 19
20. 発想の転換 「名前で解決する」から 「ローラー作戦で候補を絞って確かめる」へ 20
21. スレッドごとの領域（TLS ） TLS （Thread Local Storage ）のどこかに ZTS の処理系情報が居る 各スレッドの TLS 自体がどこにあるかは CPU の情報を読むとわかる 名前情報があれば名前で TLS 内の位置を引ける 名前がなければローラー作戦でしらみ潰しに見る、は非効率？ 21
22. PHP 処理系の TLS ブロックは大きくない TLS 側の探索範囲がそこまで大きくない バイナリじっと見てたら TLS 全体で 0x13c バイトとかしかなかった 総当たりでも候補を試せる 22
23. 総当りとは まじで総当りする TLS ブロックの先頭から 8 バイトずつずらして順に試す だめなら次の 8 バイトあとの位置 どこかに正解が埋まってる 23
24. 掘り出した正解をどうやって見分けるか 見た位置が正解だ、とどう確認すればよいか 偶然それっぽい値を踏むかもしれない 検証が必要 24
25. 検証の考え方 辿った先が PHP の内部状態と仮定した場合に自然か 複数の条件で確かめる 25
26. まず見るもの 実際に Executor Globals （PHP 処理系内部状態の中心）が辿れるか 処理系内に絶対あるであろう欲しい値へ到達できるか 明らかに変なら捨てて次の 8 バイトへ 26
27. 処理系内に絶対あるやつら uninitialized_zval 未定義変数や配列の値へアクセスした際にとれる null error_zval 処理系内でエラー状態を表すための値 グローバル定数 PHP_VERSION PHP 内部に定義済みの全定数をおさめた連想配列がある ハッシュ表のような複雑なデータ構造を正常に引けるならほぼ確 27
28. 要するに 候補探索 内部状態の検証 複数の手掛かりが揃ったら採用 28
29. 今回の PR 内容 stripped ZTS binary 対応を追加 issue と以前に PoC まで作った PR を Claude Code に教えた やる気の足りない俺にかわって コード整理をやってくれた 「コードの整理改善しよう と思ってたけど詳細忘れた」 みたいなぶん投げ 29
30. Claude Code さんの活躍 コードの全体構造を確認 PoC 実装内にやっつけでコピペされた重複コードを発見 重複コードの部品化・共通化で循環参照が発生する箇所の解消 元の部品粒度がびみょかった箇所の解消 静的解析器に怒られながら型の整合性をとる テストの修正 30
31. Claude Code が効いたところ リファクタ 共通化 補助コードの追加 型エラーの修正 31
32. Claude Code が効いたところ 2 仮説の言語化 受け答えするラバーダック 机に向かわせてくれる雑談相手 32
33. 逆に人間が握ったところ ニッチな分野へのそもそもの対応方針決め 型エラーの方針決め 静的解析器のバグとかあると困るもよう コードについてのお気持ち問題 「ここは E2E っぽいテストを志向してるのでモック使わないで」みたいな 33
34. 低レイヤでも会話が成立した 「PHP で別プロセスのメモリを読みながら実行ファイルの ELF バイナリ解析して る自作ツールが strip された ZTS バイナリだと処理系内部状態を得るためのアド レスがシンボル解決できずに困っているんだけどブルートフォースでなんとかし てやるぜ」 この話をされた人間のいくらかはたぶん途中で理解のレールから脱落する AI 先生はわりと普通に通じるしコードの整理までできる 自分から同等の対応案を出してはこないけど話せば分かるやつ 34
35. 小学生並みの感想 ニッチな話題とアイディアに適切な相槌が出てくるのスゴい やり取り自体がちょっと楽しかった 俺にやる気がなくてもかわりにやる気を出してくれるの良い 35
36. 注意したいところ 検証の設計は必要 今回のプロジェクトは静的解析の型カバー率が 100% テストもいくらかは書いてた それでも自動検証をすり抜けた誤りもある 36
37. おわり ご清聴ありがとうございました 37