RISC-V カスタムのためのツールチェーン拡張 ― GNU Binutils と GCC の拡張・コミュニティへの参加編 (未完成版)

Copyright © 2024 Tsukasa OI. All Rights Reserved. 2024-03-06: RISC-V
勉強会@Online 1 RISC-V カスタムのためのツールチェーン拡張 GNU Binutils / GCC の拡張のやり方、そしてコミュニティにコントリビューター / コミッターとして参加する際の備忘録 (未完成版) 2024-03-06 / RISC-V 勉強会@Online Tsukasa OI

勉強会@Online 2 Legal Notice • この発表には FSF との契約に関する解説が含まれることがあります。 • ただし、それは FSF と私との間に結ばれた 3 本の契約書の内容に基づくものであり、それが他人の契約と等価であること、また仮に等価であったとしても、解説が正確であることを保証しません。 • 契約書の具体的内容と解説が矛盾する場合、実際の契約書の内容が優先します。

勉強会@Online 3 Parental Advisory • TL;DR: 適度な読み飛ばし推奨 • スライドには暴力的な量の情報が詰め込まれることがあります (というか詰め込まれています)。 • 興味を持った人が資料を見返したときに、だいたい最低限必要な情報が書かれている、を目指しています。 • そのため、発表では大幅な省略を行うことがあります。 • Sorry! • 体調不良により一部未完成部分があります。 • このスライドは、その未完成部分をそのまま掲出したものです。

勉強会@Online 4 自己紹介 • 大居司 (Tsukasa OI) – X (旧 Twitter): @a4lg • 2020-01 – 2023-01 : TRASIO / 研究員 (RISC-V を基盤としたセキュリティ技術開発を行う技術研究組合) • 2024-03 現在: 自宅療養、再就職活動中 • TRASIO の活動の中で RISC-V に本格的に入れ込み、業務外で RISC-V 関連のオープンソースソフトウェア開発・拡張、ツールチェーンエコシステムの調整をはじめとする議論に参加 (ボランティア) • GNU Binutils (write after approval committer) • GCC (write after approval committer; NEW!) • Linux 5.18 (Atish Patra 氏と合同で複数文字拡張のサポート) • QEMU 7.1 (Linux 5.17 以前との相性問題の解消) • ここ数ヶ月は目立った参加が無いが、他プロジェクトへの参加と趣味に近い方 (文系) の論文執筆にかかっていた

勉強会@Online 5 そもそもツールチェーンって? • ソフトウェア開発のための基盤の総称 • 最低でもアセンブラ、リンカ、コンパイラを総称することが多い (その他 libc、デバッガや補助ツール等を含めることもよくある) • GNU の場合一例: Binutils と GCC の 2 プロジェクト • アセンブラ: GNU Assembler (GAS / GNU as; Binutils 内) • リンカ: GNU Linker (ld; Binutils 内) • コンパイラ: GCC • LLVM (広義) の場合一例: LLVM リポジトリ内に一通り存在 • アセンブラ: LLVM (狭義) (場合によっては GNU as (Binutils 内) も) 元々コンパイラとアセンブラの中間となる共通基盤が起源だが、アセンブラ、場合によっては逆アセンブラ自体の機能も持つようになっている (MachineCode 中心) • リンカ: LLVM LLD (lld; LLVM リポジトリ内) などリンカに関しては GNU / LLVM ともに他選択肢を選ぶこともかなりある • コンパイラ: LLVM Clang (LLVM リポジトリ内)

勉強会@Online 6 そもそもツールチェーンって?: GNU Toolchain • GNU Binutils • オブジェクトファイルの生成や汎用的な取り扱い (主に BFD) • アセンブラ / 逆アセンブラに関する取り扱い • 前者は主に GNU Assembler (GAS / GNU as) • 後者は主に Opcodes ライブラリ • ただし、関連することも多い (主に前者が後者内の情報を利用) • これらをベースとした基本ツール • リンカの GNU Linker (ld) • オブジェクト内の情報を表示する objdump など • デバッガの GDB とはリポジトリを共有 • 一応別プロジェクト扱いだが、メンテナーの違い以外は実務上ほぼ共有 • GCC • C/C++ をはじめとするコンパイラ • Binutils とは概ね同期を取っているものの、基本的には技術的基盤からして別プロジェクト (Binutils 内機能の再実装も多い) LLVM の場合、条件次第でデバッガ (LLDB) 含むツールチェーンほぼ全体を同じ技術的基盤で扱うことが可能なのと対照的。

勉強会@Online 7 今回の話 • 第 1 部: GNU Binutils / GCC の拡張方法 • 前提: Binutils 2.42 / GCC 14 周辺のバージョン • 度々設計が変わるので、一部の知識はそのままは使えなくなる可能性あり • GNU Binutils への RISC-V 拡張 (拡張名)、命令、CSR の入れ方 • GCC への built-in 関数の入れ方、その他一部の拡張のやり方 • あと GCC 開発そのものに関する注意とか • (LLVM とも共通する) ベンダー拡張の行儀の良い入れ方 • 第 2 部: アップストリームへの開発に参加する • コントリビューターとしての参加方法 • コミッターとしての参加方法 • (普通の) コミッターになってもコントリビュータと同じくメンテナーの許可が要ることは変わらないのに、わざわざコミッターになる意義 (ネタバレ: 存在する)

勉強会@Online 8 今回の話を通じてやりたいこと • ツールチェーン開発者もっと増えろー!!!!!!!! • GCC の開発に (一応) 参加しだしたことで、Binutils / GCC にまたがる GNU Toolchain 全般の話をしやすくなった • 発表を見た人がやれることが増えた……らいいなぁ • Ventana Micro Systems 社の RISC-V CPU 向けベンダー拡張 (歴史的には機能的に全く同じ ZiCond 拡張の起源) を GCC に実装 (コードもほぼ共有) • ――を私はボランティアでやったけど、正直健全じゃないよね • 一応 Ventana の中の人曰く、Ventana 版 GCC では実装してたらしいけど…… • アップストリームに直接関われる人をもっと増やしたい • Binutils / GCC / LLVM ともに、参加の敷居は下がっている • 今回は対象にしないものの、例えば LLVM は過去独自ツールを使った変更管理を今まで実施していた (正直面倒な) ものが、 GitHub 上での Pull Request を使った管理に変更された • Binutils / GCC は開発スタイルこそ Linux 等と同じく ML ベースだが、アップストリーム開発に参加する際の FSF との契約が必須ではなくなった (Linux ライク; まだ契約も推奨はされてるのでそちらの方法もちょっと解説)

勉強会@Online 9 ツールチェーンの拡張 • GNU / LLVM どちらの場合も、ツールチェーンの拡張には一部 DSL を読み書きする必要がある • ……が、敢えて入りやすいのを挙げるなら GNU か • GNU も GCC の DSL は相当の前提知識を要するが、少なくとも Binutils 側の大部分は楽 • かつ、RISC-V 公式ツールとの相互運用性を確保しやすい • LLVM 側はアセンブラ命令を追加するだけでも、いきなり TableGen DSL をしっかり読み解く必要が出てくる • やり方をしっかり覚えればどちらでも似たようなことができることは理解してきたが、それでも楽な道ではない • あと内部構造ドキュメントも (双方ともに完全な理解のためには少なすぎるとしても) GNU GCC の方がやや充実している感がある

勉強会@Online 10 新しい拡張の追加 (1) • Binutils: bfd/elfxx-riscv.c • riscv_supported_vendor_x_ext テーブル • ベンダー拡張命令の場合。標準命令には別テーブルあり。 • riscv_implicit_subsets テーブルに、依存関係を追加 • 例えば CSR を持つ拡張の場合、Zicsr 拡張への依存を追加しておきたい • GCC: gcc/common/config/riscv/riscv-common.cc • riscv_ext_version_table テーブルに拡張を追加 • 標準・ベンダー拡張ともにこのテーブル内に記述する。 • riscv_implied_info テーブルに、拡張の依存関係を追加 • Binutils と同様だが、条件付き判定の機能は現在持たない。 • Binutils と GCC で二度手間があることに注意 • ここまでで出来るようになったこと • -march にベンダー拡張名を指定しても怒られなくなった • オブジェクトファイルに関連情報が追記されるようになった

勉強会@Online 11 新しい拡張の追加 (2) • スライド版は未完成

勉強会@Online 12 新しい拡張命令追加のための準備 (1) • Binutils: 新しい命令クラスの追加 • 必要な拡張の判定などに使用する enum 値 • 通常 INSN_CLASS_[拡張名] だが、その拡張と別拡張間に相互作用がある場合、別途命令クラスが必要になる • 標準命令クラスの場合: INSN_CLASS_F_AND_C (C および F 拡張 [ないし Zcf 拡張]) • Binutils: include/opcode/riscv.h • riscv_insn_class enum • 命令クラスを追加 • Binutils: bfd/elfxx-riscv.c • riscv_multi_subset_supports 関数 • 新しい命令クラスのサポート判定ロジックを追加 • riscv_multi_subset_supports_ext 関数 • 拡張不足時に表示するメッセージの断片を返すロジックを追加 • 複数拡張の相互作用が関わる場合、ここはやや難しい書き方になる

勉強会@Online 13 新しい拡張命令追加のための準備 (2) • ここでは XLoveTechMac 整数積和演算拡張を追加するとしよう • 命令クラス: INSN_CLASS_XLOVETECHMAC • 以下未完成

勉強会@Online 14 新しい命令を追加: riscv-opcodes に頼る (1) • riscv-opcodes • 命令エンコーディングを記述して、それに対応する命令デコーダ (Chisel / Spinal HDL / System Verilog) やソフトウェア向けの命令マッチ条件 (C / Rust / Go) などを出力する公式ツール群 • rv_[拡張名] または rv64_[拡張名] (64-bit 専用命令の場合) のようなファイル名を記述し、中に入れたい命令のエンコーディングを記述する • この出力の中の encoding.out.h は公式の C/C++ ベースツールが直接 encoding.h として #include する形式になっているほか、(一致しない箇所もあるものの) GNU Binutils に新規部分をほぼそのままコピー&ペーストできる • これが LLVM では出来ないので、GNU 側の利点でもある • https://github.com/riscv/riscv-opcodes

勉強会@Online 15 新しい命令を追加: riscv-opcodes に頼る (2) • 新命令の記述例 • ここでは XLoveTechMac 整数積和演算拡張の lt.mac 命令 (RV32/RV64 共有) を追加すると仮定しよう • 非圧縮命令 (1:0=3) についていえば、 6:2 が 10110 (0x16) または 11110 (0x1E) なのがベンダーカスタム命令 • 圧縮命令に (1:0≠3) についていえば、現在マニュアルに指定のある 79 (RV32C) または 111 (RV64C/RV128C) 個の 16-bit エンコーディングがベンダーカスタム用に予約 • ファイル rv_xlovetechmac を追加し、命令を記述 lt.mac rd rs1 rs2 31..25=0 14..12=1 6..2=0x16 1..0=3 31: 25 24: 20 19: 15 14: 12 11: 7 6: 2 1 0 0000000 rs2 rs1 001 rd 10110 11 lt.mac rd, rs1, rs2 (仮定) rd += rs1 * rs2

勉強会@Online 16 新しい命令を追加: riscv-opcodes に頼る (3) • 出力の encoding.out.h を見ると、対応する記述が (この部分はスライド版では未完成) • Binutils: include/opcode/riscv-opc.h の二箇所 (それぞれ別) に追加しよう • MATCH_*, MASK_* • DECLARE_INSN(...) • ここまでで出来たこと • 命令エンコーディングが追加され、必要に応じてハンドリングができるようになった • ただ、まだアセンブラも逆アセンブラも動く状態になっていない (肝心の DSL をまだ弄っていないため)

勉強会@Online 17 新しい命令を追加: GNU Binutils の RISC-V DSL (1) • Binutils: opcodes/riscv-opc.c • riscv_opcodes という巨大なテーブルが追加先 • 構造体の記述内容は以下の通り • 命令名 • サポートされる XLEN (例: 32 なら RV32 専用、0 なら汎用) • 命令クラス • DSL: 命令オペランド記述 • MATCH_* 値 • MASK_* 値 • オペコードのマッチ関数 • mask, match だけでは有効性が判断できない場合にカスタム関数を使用 • 通常は、match_opcode 関数を指定しておけば良い • その他フラグ (命令がエイリアスであるか否かなど; 必要ないなら 0) • 基本的に上からマッチするものが優先される • また同名の命令は同じ場所に固まっている必要がある

勉強会@Online 18 新しい命令を追加: GNU Binutils の RISC-V DSL (2) • ソースコードや他の命令内容を参照するのが賢いやり方だが――この仮定の命令の場合はシンプル (rd, rs1, rs2 オペランドともに既存の定義がある) {"lt.mac", 0, INSN_CLASS_XLOVETECHMAC, "d,s,t", MATCH_LT_MAC, MASK_LT_MAC, match_opcode, 0 }, • ここまで済んだら、アセンブルしてみよう! • Demo • ここまでで出来るようになったこと • 新規命令を追加し、アセンブル、逆アセンブルともに出来るようになった

勉強会@Online 19 新しい CSR を追加: riscv-opcodes に頼る • 新 CSR の記述例 • riscv-opcodes では、CSR は拡張名毎に分割されておらず、 csrs.csv もしくは csrs32.csv に追記する • ここでは、T-Head の CPU 依存拡張の mxstatus カスタム CSR を追加してみよう • 追加する内容は非常に簡単 (値と名前のみ) 0x7C0, "mxstatus" • Binutils: include/opcode/riscv-opc.h の二箇所 (それぞれ別) に追加するが…… • CSR_* の定義はそのままコピー • DECLARE_CSR(...) については、 GNU Binutils に合わせて追加パラメータの指定が必須 • CSR クラス (命令クラスと同様だが記述箇所が異なる) • 必要な特権アーキテクチャのバージョン (最低値、最大値 [exclusive])

勉強会@Online 20 新しい CSR を追加: GNU as に移植する • 未完成 • 予定内容: CSR クラスとそのハンドリングの追加

勉強会@Online 21 高度な命令の追加 • 未完成 (今回は完成品だけお見せする) 31: 30 29: 27 26: 25 24: 20 19: 15 14: 12 11: 7 6: 2 1 0 00 S2 S1 rs2 rs1 111 rd 11110 11 lt.dslliadd rd, rs1, shamt1, rs2, shamt2 (仮定) =S1 (0-3) =S2+4 (4-11) rd := (rs1 << shamt1) + (rs2 << shamt2) 2 次元配列のルックアップに役立ちそうなそうでもなさそうな仮想命令。

勉強会@Online 22 アップストリームに反映する前に: テストの記述 • 未完成

勉強会@Online 23 GCC 開発時の注意 • GCC の内部命令定義を弄ると、自動生成される巨大なソースコードが再生成、再コンパイルされる • あまりにも巨大なため、Makefile ではタイムスタンプ差があっても以前コンパイルしたソースと内容差がある場合のみ再コンパイルされる工夫が成されているほど • これのコンパイルも、これが絡むリンクも時間が非常にかかる • 5 分かかることも珍しくない • 速いマシン and/or 速いコンパイラとリンカを使おう • というわけで、発表者の私は GNU ツールチェーンの開発にもかかわらず主なコンパイルに Clang と mold を使用している

勉強会@Online 24 おまけ: 行儀の良いベンダー固有拡張の入れ方 • 拡張名 • X[ベンダー名または略称][拡張の固有名] • Cv OpenHW (CORE-V ブランドの方を略称として使用) • Sf SiFive • THead T-Head • Ventana Ventana • 例: XCvMac (CORE-V カスタムの整数積和命令拡張) • 命令名 • [ベンダー名略称(2字)].[命令名] • th T-Head など • 例: th.ff0 (T-Head 固有の count leading zero [find first 0] 命令) • 重要な情報や追加等は次を参照: https://github.com/riscv-non-isa/riscv-toolchain-conventions

勉強会@Online 25 おまけ: Visual Studio Code で開発を自然に • 私の場合、ワークスペースで以下を設定してます • Editor: Detect Indentation (editor.detectIndentation) false (チェックを外す ―― 必要ないかも) • Editor: Tab Size (editor.tabSize) = 8 • GNU インデントはソフトスペース 2、ハードスペース 8 だが、ここではハードスペースの方を設定 • C_cpp: Clang_format_fallback Style (C_Cpp.clang_format_fallbackStyle) { BasedOnStyle: GNU, UseTab: ForContinuationAndIndentation, SpaceAfterCStyleCast: true } • clang-format の GNU インデントは、何故かスペースを統一して使用する、 GNU Coding Style 標準そのままというよりは glibc 等に近い微妙に独自なスタイルを持つ (同スタイルは状況に合わせて変えても良いものなのだが、 GNU Coding Style ほぼそのままの Binutils / GCC との相性が微妙) • clang-format 側の GNU プリセットを GNU Coding Style そのままにする変更を提案したが、残念ながら却下されてしまった • というわけで、差分の主要な所は自分で整える

勉強会@Online 26 Binutils / GDB / GCC (に限らない) の承認と変更ソースコードリポジトリ (Git) コントリビューター (一般の貢献者) コミッター (write after approval committer) メンテナー詳細は省略するが、全体のメンテナーと各分野 (アーキテクチャ、モジュール、プログラム) 等限定のメンテナーが存在する要求|承認要求|承認承認された変更の書き込み担当範囲で任意の書き込み承認、変更プロセスだけ抜き出すとこんな感じ。その他は、メーリングリストで正式な承認以外も含めた議論が常時行われるほか、リポジトリの読み取り権限は全員に開放されている。また慣例的に、コミッターは承認された自身の変更反映のみを行い、承認された他人の変更のコミットは基本的には避けられる。

勉強会@Online 27 Binutils / GDB / GCC (に限らない) の更新 • 書き込み権限を持つのは、メンテナーとコミッター • うち、メンテナーは担当範囲で任意の書き込み権を持つ • また、自身の担当範囲での他人の変更の承認権を持つ • コミッターは原則としてメンテナーに承認された範囲での書き込み権 (write after approval) を持つ • 発表者が Binutils+GDB / GCC において属するのはここ • リポジトリへの書き込み権という意味では全体メンテナーにかなり近い書き込み権を既に与えられているが、ルール上濫用を禁止されている形 • 承認前の議論はコントリビューター含め、メーリングリスト内にて公開で行われる • ML にパッチを送信 • ML (など) において議論 • メンテナーによる承認もしくは却下 • メンテナーもしくはコミッターによるパッチの反映

勉強会@Online 28 コントリビューターの貢献: パッチの送信まで (1) • Binutils と GCC の場合、ChangeLog をコミットメッセージに入れる必要があるので、 git commit 時の工夫とセットアップ • GCC の場合、git のソースディレクトリで contrib/gcc-git-customization.sh を実行 • Binutils の場合: • GCC の contrib/prepare-commit-msg を .git/hooks 以下にコピー • コミット時に GCC_FORCE_MKLOG=1 と付けると、コミットメッセージに自動で ChangeLog のテンプレートが付与される

勉強会@Online 29 コントリビューターの貢献: パッチの送信まで (2) • git am コマンドを使用してパッチ (兼メールファイル) の集合 (パッチセット) を準備する • この辺は繰り返し適用すると結構面倒なので、私の場合は一部のワークフローを自動化したシェルスクリプトを作った (以下のような内容はテンプレート化することも多いので) • 送信するメーリングリストとその他宛先 • Cover letter の有無とその内容 (git am で作った cover letter の内容はデフォルトではスタブ) • Cover letter について • [PATCH v1 0/x] の 0/x なメール • パッチセットの一部だが、コミットを構成せずメッセージ専用 • 極めて重要な情報がないなら無い方が無難 • コミットメッセージだけで情報を伝えきれているなら必要ない • とはいえ、個別のコミットメッセージには馴染まない詳説や議論への個別回答を踏まえたパッチセットの変更履歴などは、必然的に cover letter に入れることになる

勉強会@Online 30 コントリビューターの貢献: パッチの送信まで (3) • SMTP(S) サーバーに直接接続できるようにしているなら git send-email コマンドが楽 • 適宜送信レート制御もしてくれる • なお私の環境の場合、SMTPS サーバーに TLS クライアント認証を入れているため、git send-email に独自パッチを施している • メールファイルを扱える既存ソフトでの送信も可だが、メールソフト側の「お節介」によって壊れることも • メールファイル: Windows の場合、.eml 拡張子相当 • 使えるなら git send-email を使うのが無難 • どうしても既存メールソフトを使う場合は、既存のガイドを参照してパッチを壊さないように注意 • この辺りは本番の送信前に十分テストすることを強く推奨 • 勝手に改行や、スペース削減などが行われていないか • パッチの変更されていない行において、行初に 1 個以上の空白があるか

勉強会@Online 31 コントリビューターの貢献: ML での基本 • メーリングリストにパッチセットを投稿 • 議論 (もしくは直接次項へ) • これについては、書き込み権の有無によらず参加可能 • 指摘された場合は必要に応じて対応するか、あるいはそのままにすべきこと等を主張して議論することになる • 特にその領域に関わることが多いメンテナーの強い否定的意見は暗に却下を意味するので、大人しく修正ないし撤回するか、必要ならば根気強く説得しよう • 承認もされず議論も進まない場合、例えば GDB の場合は最初のパッチセット送信から 2 週間以上経ってから 1 週間以上の間隔で催促 (ping) することが推奨されている • 見逃しや、皆が対応ができない状況は少なくない • メンテナーによる承認 • メンテナー (またはコミッター) が変更をリポジトリに反映 • 基本的にはメンテナーが行うはず

勉強会@Online 32 コントリビューターの貢献: 承認前後: GNU の場合 • 歴史的に、GNU の多くのプロジェクトは貢献の際、 FSF への著作権譲渡などを行う契約を要求してきた • 法的事務などについて FSF が主導で行いやすくするため • 私が経験した古い時代からの例外: GNU Autoconf Archive (ライセンス的問題がないなら著作権譲渡の必要無し) • ――が、(著作権譲渡は現在も推奨されているものの) それ以外の方法も一部 GNU プロジェクトで開かれてきた • 広い意味で、ここ数年の FSF 改革の一環 • Binutils と GCC は、ともに新しい方法を使用可能になった! • 具体的方法: Developer Certificate of Origin (DCO) の宣言 • これは現在 Linux カーネル開発で用いられる宣言方法と同じ • というより DCO 自体が Linux Foundation 発祥

勉強会@Online 33 コントリビューターの貢献: 2 種類の方法 FSF への著作権譲渡 DCO の宣言方法 (所要時間) (典型例: 一部バリエーションあり) FSF 窓口に対し当該プロジェクトへの全貢献に対して著作権を譲渡する等の旨を送信。互いに契約書のスキャンを送りあって契約の上、契約者と FSF 担当者双方の直筆サイン入りの PDF を双方が共有する (数週間) パッチのメッセージ欄に適切な Signed-off-by: 行を付加し、 Developer Certificate of Origin (DCO) の version 1.1 に同意したことを宣言する (貢献者=著作権者であればすぐ、そうでなくても手間は比較的少ない) 対象の単位一般にプロジェクト (Binutils+GDB の場合は両方) パッチ (コミット) 他OSS混入※ 不可 (著作権者単位での契約が大前提) ライセンス問題が生じない限り可著作権の帰属先・特筆事項 FSF ただし貢献自体についてはその貢献者に対し (OSS に限らない) 無制限かつ取り消し不能の使用権が許諾される一般的な著作権者 (貢献者やその勤務先) + 既存 OSS コードをコピー等していた場合、その著作権者責任・義務元著作権を契約者が持つこと等を宣言し、 FSF に譲渡する。また幾つかの限定的な協力義務が契約に明記されている。貢献のマージにライセンス上の問題が無いことを宣言する。これに違反した場合の明文化された規定は無い (法的判断が発生するまで不明確ではある) が、おそらく宣言者が最低でも限定的な責任を負いうる。 ※ 他OSS混入: 具体的には、FSF や (元) 著作権者としての契約者以外が著作権を保有する (かつパブリックドメインでもない) オープンソースソフトウェアやその他著作物の混入を指す。注意: riscv-opcodes の出力は著作物と見做されていない。

勉強会@Online 34 FSF との契約を結ぶ場合 (1) • プロジェクトへの貢献 (過去、もしくは過去未来両方) の著作権を FSF に譲渡し、かつ自身の貢献の利用を損なうような (例えば特許の) 権利行使をしないなどの旨を誓約、 FSF との契約を行う (典型的な事務処理: スキャンした PDF の往復に数週間) • 代わりに FSF はこれらの貢献を取り込んだ際の頒布は取り消し不能な広義の自由ライセンス、機械読み取り可能なソースコード形式で行うことなどを誓約する • またあまり知られていないが、 FSF は契約者に対して、貢献部分 (本来契約者が一次著作権を有していたであろう部分) の無制限、取り消し不能の利用権を許諾する • 実務的には FSF が著作権を持ち、その利用を妨害できないだけで、本来著作権者であり続けたであろう場合に行えるほとんどの行為 (例えば非 OSS への適用含む (!) 自ソースの再利用など) は、実は引き続き可能なままである。

勉強会@Online 35 FSF との契約を結ぶ場合 (2) • 契約対象・スタイルについては幾つかバリエーションあり • 「過去及び未来全ての」(当該プロジェクトに対する) 貢献の譲渡 • 特別な理由がない限りはこれを使うべき • 「過去全ての」(当該プロジェクトに対する) 貢献の譲渡 • 追加で必要になる場合があるもの • 貢献者の雇用主に対して: 雇用主に生じたあらゆる所有権の主張が放棄されている旨の声明文 (disclaimer) • その他特別例 • プログラム全体を寄贈する (新規プロジェクト専用) • 自分から契約を結ぶ場合には、FSF の関連文書と、以下からダウンロードできるテンプレートを参照 https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright

勉強会@Online 36 DCO を宣言する場合 (1) • Linux Foundation が Linux 向けに確立した方法: Developer Certificate of Origin (開発者としての出自証明) • 以下抄訳 (私が宣言する事項): a. この貢献は全面的ないし部分的に私によるものであり、かつ私はファイル内に示されたオープンソースライセンスで送信する権利を保有している。または、 b. この貢献は既存の、私が知り得る限りでは適切なオープンソースライセンスの作品を元としており、(後略)。または、 c. (a), (b), (c) のいずれかを証した他人から私に直接送信されたものを改変無しに送信したものである。 d. 加えて、私はプロジェクト及びこの貢献が公開のものであり、貢献記録 (sign-off※を含め、共に送信した私の個人情報を含む) は無期限に記録、またプロジェクトのオープンソースライセンスに整合する形で再頒布が行われることに同意する。上記は version 1.1 (2006 年公開の最新版) のものであり、 Linux / Binutils / GCC ともにこのバージョンを想定。 ※ sign-off (サインオフ): DCO への同意宣言の呼称。

勉強会@Online 37 DCO を宣言する場合 (2) • 具体的方法: パッチに適切な行を記述して宣言する Signed-off-by: Name of You <email@address> • この行は主に送信者を示す (必ずしも著作権者とは限らない) • Git を利用している (かつ名前とメールアドレスを適切に設定している) 場合必要なのは git commit の -s オプション (sign-off) のみ • 標準のコミットメッセージに上記の行が含まれるようになるため、それを保つか適切に改変しつつコミットする • 典型的には最終行 (付近)、かつコミットメッセージ本文とは 1 行離す • ブランチ内で追加を忘れたコミットがあった場合は、 git rebase -i などを活用しよう • 貢献を会社従業員として行う場合は事前確認を忘れずに! • この場合著作権者が会社になるため、会社の適切な承認無しにやると DCO 宣言の (a) に反してしまう

勉強会@Online 38 コントリビューターからコミッターへ • 通常のコミッター (非メンテナー) は、メンテナーの承認が得られた変更だけをコミットする権限を持つ • この点ではコントリビューターの時とほぼ同じではある • 例外: typo を含む自明な修正は独断で適用できる • 特に役立つ場面としては、送信時 – 承認時のコミット差に起因する rebase コンフリクトの独断による解決 • では何が違うのか? (超巨大なメリット): コミッターによる変更適用は基本的に自身が行う → 承認された変更を「いつ適用するのか」自己判断できる • メンテナーとのミスコミュニケーションによる “勝手な” 変更の取り込みにある程度待ったをかけられる • 複数プロジェクトに対してほぼ同時に行う必要がある変更について中途半端に適用された結果のリグレッションを防げる • 幸いにも / 不幸にも私は両方のケースに関わったので、どちらも紹介することにします……

勉強会@Online 39 事故発生例1: Zicbom / Zicboz 拡張 (1) • 両拡張は策定 (ratification) 文書にアセンブリ言語での構文が明確に書かれており、実装者側としては助かる • ただし結果的には、一部の人から「策定 (ratification) の条件にツールチェーンへのパッチの存在を入れておくべき完璧とも言える好例」とも評されることとなった。 • ……が、メモリを弄る命令であるにも関わらず構文がメモリを弄る命令っぽくない • 例: Atomic (AMO) 命令の場合 amoswap.w.aq t0, t0, 0(a0) • 例: RISC-V CMO 文書 (version 1.0.0) の場合 cbo.clean a0 • RISC-V / LLVM ツールチェーン側に主に関わる Alex Bradbury 氏が策定後のアセンブリ構文変更を提案 • 提案構文: cbo.clean 0(a0) 全て a0 レジスタの指すメモリアドレスに対する操作。

勉強会@Online 40 事故発生例1: Zicbom / Zicboz 拡張 (2) • GNU 側で同拡張の実装をしていた私としては Bradbury 氏の意見には中立 – 弱い反対を表明しつつ、両方の案については試す価値があると判断 • 私は Binutils のメーリングリストに両案 (原案 / 変更案) を投稿しつつ、RISC-V CMO 側の議論に追従する方向へ ① 現状を理解している私が Binutils について原案を推す (CMO 側の変更が承認されれば改めて変更案を推す) ② CMO 策定メンバーが再集合して助けてくれる (議論が完了するまでは Binutils の変更は保留してもらう) 某メンテナー: 「変更案の方を取り入れといたよ (超意訳)」 ③ 未確定な方をマージされる。現実は奇妙である。(事故発生)

勉強会@Online 41 事故発生例1: Zicbom / Zicboz 拡張 (3) • これにより、私はいずれかの対応を急ぐことを迫られた • Binutils 側に原案への差し戻しか削除を承認してもらう • RISC-V CMO 側に Bradbury 氏案を承認してもらう • どちらにせよ、関係者へ事情説明と釈明を行い、事態を動かす必要が出てきた • 放置したままだと Binutils 側がリリースされてしまう • 結果的解決: 後者がやや有力となった (原因の一部には上述事故もある) ところで Bradbury 氏案を強力に推進する方向で決め打ち、 CMO 策定メンバーを急かしつつ文面整備等を実施 • 最終的に変更は承認され、RISC-V CMO 文書の version 1.0.1 でアセンブリ言語構文が正式に変更された • 原因: ミスコミュニケーション (事前の説明不足)

勉強会@Online 42 事故発生例2: Zmmul 拡張 (1) • M 拡張 (乗算/除算) のサブセットとして Zmmul 拡張 (乗算のみ) が策定され、対応を行った • この際少しエンバグしてしまったが、それは本題とは別 • 対応するにあたって、同じリポジトリで開発される 2 プロジェクト、Binutils と GDB の両方をほぼ同時に変更する必要があった • GDB は RISC-V アーキテクチャ含む一部アーキテクチャー向けの命令シミュレータ機能を持ち、 Zmmul 拡張に対応する Binutils 側への変更は、 M 拡張に対応していた命令シミュレータの実装に影響を及ぼす • つまり、パッチセット 2 個承認の上で両方同時に変更したい • 事故発生: 事前説明にもかかわらず、人的ミスにより Binutils 側のパッチだけが承認後、適用されてしまう • 結果、RISC-V の命令シミュレータがコンパイル不能に

勉強会@Online 43 事故発生例2: Zmmul 拡張 (2) • 過ぎてしまったことは仕方がないし命令シミュレータ自体の優先度は GDB でも低い方だが、何故か GDB 側の承認が遅々として進まなかった • 原因: GDB 側の RISC-V arch のメンテナー 2 人が別々の理由で承認を出せていなかった • A 氏: そもそも自身が (GDB 本体に加えて) 命令シミュレータ側の RISC-V arch メンテナーでもあることを知らず、承認範囲外だと思い込んでいた • B 氏: GDB の全体メンテナーも兼ねる人物であり、単純にレビューが追いついていなかった • RISC-V GNU ツールチェーンに関するオンライン定例会議へ参加していた A 氏をその場で捕まえて事情説明。後に B 氏も交えて、確かに A 氏の承認範囲でもあることを確認、ただその時には既に B 氏の余裕ができていたこともあり、 B 氏が承認・マージ (私の拙い英文に対する校正を含む修正あり)

勉強会@Online 44 コミッターへ! (Binutils+GDB / GCC 共通) (1) • 特に事故 2 (Zmmul 拡張でのリグレッション) の発生が、私自身がコミッターになることの強い動機となった • 私の落ち度があまり無いが、自分の変更が事故を起こす • 前提: Binutils+GDB / GCC はどちらも Sourceware 上でホストされるプロジェクトである • 必要なもの (共通): 既存メンテナー 1 人の推薦 • 私の場合、最初に目指した Binutils / GDB は全体メンテナーの方、 GCC は RISC-V arch メンテナーの方に推薦を頂いた (特に GCC の方はメンテナーの方からコミッター権の話を頂いた) • 注意: Binutils / GDB はプロジェクトとしては別だが、コミッター権限としては両プロジェクトが共有するという形になっている。 • 最初そのことを知らず、Binutils と GDB「両方の」メンテナーの方に承認を求めるメールを送ってしまった (お二人からは共に快い返事を頂いたが結果的に Binutils メンテナーの方の推薦のみ使用する形になってしまった)

勉強会@Online 45 コミッターへ! (Binutils+GDB / GCC 共通) (2) • Sourceware で初めてコミッターになる場合 • Web フォームに所定事項を記入し、アカウント作成を要請 (この際、推薦を頂いたコミッターのメールアドレスも入力) • 確認が済むと、所定事項の中に書かれたユーザー名と、上で記入した公開鍵に対応する SSH 鍵でのログインが可能に • 2 回目以降の場合 • Sourceware 管理者にメールで権限追加を要請 (対象のプロジェクトと推薦コミッターのメールアドレスを記入) • コミッターになった後に必要な儀式 (GDB と GCC の場合) • 対応プロジェクトの MAINTAINERS ファイルに自身の名前とメールアドレスを記述 • 必要な儀式であると同時に、Sourceware に対するコミットが正しくできることのテストにもなる • (Binutils の場合はメンテナーの場合のみ必要)

勉強会@Online 46 コミッターへ! (Binutils+GDB / GCC 共通) (3) • 関連リンク: • https://sourceware.org/ FAQ: I need an account on sourceware for git/svn/cvs write access to project XYZ?

勉強会@Online 47 コミッターになったら……? (1) • 基本的にやることはコントリビューターと一緒 • 基本、コミット権を持つか否かだけ • ML で大きい顔をするのは良い考えではない • ただし、承認されたパッチセットは自分で適用できる • 前述の通り、タイミングを揃えて適切なタイミングで適用可 • 事故を起こしにくくなる • パッチセットの適用は、feature ブランチでの rebase → master での fast forward マージが基本 • GitHub においてありがちな、マージコミットの生成は避ける

勉強会@Online 48 コミッターになったら……? (2) • 副作用: GCC コミッターの場合、既存功績次第でお仕事の紹介が来ることがたまにある • この発表時点で 2 件 (超大企業と中堅企業) • Binutils / GDB への貢献ではこの手のはまだ見たことがない • それ目当てにコミッターになるのは難しいはずだが、なれた場合、それはそれで自分の世界を広げやすくなるかも?

勉強会@Online 49 Thanks! Any comments?

RISC-V カスタムのためのツールチェーン拡張 ― GNU Binutils と GCC の...

RISC-V カスタムのためのツールチェーン拡張 ― GNU Binutils と GCC の拡張・コミュニティへの参加編 (未完成版)

More Decks by a4lg

Other Decks in Programming

Featured

Transcript