Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 15768] ファイルの概要

このコミットは、GoランタイムにおけるOS固有およびアーキテクチャ固有のコード、特にシグナルハンドリングに関連する部分の大規模なリファクタリングと整理を目的としています。主な変更点は、ファイル名の変更と、シグナルハンドリングロジックの再編成です。これにより、コードの重複を減らし、将来的なメンテナンスと機能追加を容易にしています。

コミット

commit e9d62a6d81ee380acda593edec0d3a05295254ec
Author: Russ Cox <rsc@golang.org>
Date:   Thu Mar 14 11:35:13 2013 -0700

    runtime: refactor os-specific code
    
    thread_GOOS.c becomes os_GOOS.c.
    
    signal_GOOS_GOARCH.c becomes os_GOOS_GOARCH.c,
    but with non-GOARCH-specific code moved into os_GOOS.c.
    
    The actual arch-specific signal handler moves into signal_GOARCH.c
    to avoid per-GOOS duplication.
    
    New files signal_GOOS_GOARCH.h provide macros for
    accessing fields of the very system-specific signal info structs.
    
    Lots moving, but nothing changing.
    This is a preliminarly cleanup so I can work on the signal
    handling code to fix some open issues without having to
    make each change 13 times.
    
    Tested on Linux and OS X, 386 and amd64.
    Will fix Plan 9, Windows, and ARM after the fact if necessary.
    (Plan 9 and Windows should be fine; ARM will probably have some typos.)
    
    Net effect: -1081 lines of code.
    
    R=golang-dev, r
    CC=golang-dev
    https://golang.org/cl/7565048

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/e9d62a6d81ee380acda593edec0d3a05295254ec

元コミット内容

runtime: refactor os-specific code

thread_GOOS.c は os_GOOS.c に変更されます。

signal_GOOS_GOARCH.c は os_GOOS_GOARCH.c に変更されますが、アーキテクチャ非依存のコードは os_GOOS.c に移動されます。

実際のアーキテクチャ固有のシグナルハンドラは、OSごとの重複を避けるために signal_GOARCH.c に移動されます。

新しいファイル signal_GOOS_GOARCH.h は、非常にシステム固有のシグナル情報構造体のフィールドにアクセスするためのマクロを提供します。

多くの移動がありますが、内容は変更されていません。 これは、シグナルハンドリングコードの未解決の問題を修正するために、各変更を13回行う必要がないようにするための予備的なクリーンアップです。

LinuxとOS X、386とamd64でテスト済みです。 必要であれば、後でPlan 9、Windows、ARMを修正します。 (Plan 9とWindowsは問題ないはずです。ARMにはいくつかのタイプミスがあるかもしれません。)

正味の効果: -1081行のコード。

変更の背景

このコミットの主な背景は、Goランタイムのシグナルハンドリングコードにおける重複の削減と、将来的なメンテナンスの簡素化です。コミットメッセージに明記されている通り、Goのランタイムは様々なオペレーティングシステム（GOOS）とCPUアーキテクチャ（GOARCH）をサポートしており、シグナルハンドリングのような低レベルの機能は、それぞれの組み合わせに対して固有の実装が必要となることが多々ありました。

しかし、これにより多くのコードが重複し、バグ修正や新機能の追加の際に、同じ変更を複数のファイルにわたって手動で適用する必要がありました。これは「各変更を13回行う必要がないようにする」という表現に集約されており、開発効率を著しく低下させる要因となっていました。

このリファクタリングは、シグナルハンドリングのロジックをOS固有の部分とアーキテクチャ固有の部分に明確に分離し、共通のコードを再利用可能な形で集約することで、この問題を解決しようとするものです。これにより、Goランタイムのシグナル処理部分の構造が整理され、よりクリーンで保守性の高いコードベースが実現されます。

前提知識の解説

Goランタイム

Goランタイムは、Goプログラムの実行を管理する中核的なコンポーネントです。これには、ゴルーチン（軽量スレッド）のスケジューリング、メモリ管理（ガベージコレクションを含む）、チャネル通信、そしてオペレーティングシステム（OS）との低レベルな相互作用（システムコール、シグナルハンドリングなど）が含まれます。Goプログラムは、OSが提供するプリミティブを直接利用するのではなく、ランタイムを介してこれらの機能にアクセスします。

シグナル（Unix系システム）

シグナルは、Unix系OSにおいてプロセスに非同期的に通知を送信するためのソフトウェア割り込みの一種です。これらは、様々なイベント（例：プログラムのエラー、ユーザーからの割り込み、子プロセスの終了など）に対応するために使用されます。

  • 一般的なシグナル:
    • SIGSEGV (Segmentation Fault): 無効なメモリアクセス。
    • SIGBUS (Bus Error): ハードウェアエラーによるメモリアクセス。
    • SIGILL (Illegal Instruction): 不正なCPU命令の実行。
    • SIGFPE (Floating-Point Exception): 浮動小数点演算エラー（例：ゼロ除算）。
    • SIGPROF (Profiling Timer Expired): プロファイリングタイマーの期限切れ。
    • SIGINT (Interrupt): ユーザーからの割り込み（Ctrl+Cなど）。
    • SIGHUP (Hangup): 制御端末の切断。
  • シグナルハンドリング: プロセスは、特定のシグナルを受信したときに実行されるカスタム関数（シグナルハンドラ）を登録できます。これにより、デフォルトの動作（例：プログラムの終了）を上書きし、エラーからの回復やクリーンアップ処理を行うことが可能になります。sigactionシステムコールは、シグナルハンドラを設定するための主要なメカニズムであり、シグナルの動作に関する詳細な制御（例：シグナル情報構造体 siginfo_t の取得、代替シグナルスタックの使用 SA_ONSTACK、システムコールの中断からの再開 SA_RESTART）を可能にします。
  • ucontext_t / mcontext_t / siginfo_t: シグナルハンドラが呼び出される際、OSはシグナルに関する情報と、シグナル発生時のプロセスのCPU状態（レジスタの値など）をハンドラに渡します。
    • siginfo_t: シグナルの種類、発生原因、関連するアドレスなどの詳細情報を含みます。
    • ucontext_t: シグナル発生時のプロセスのコンテキスト（CPUレジスタ、シグナルマスク、スタック情報など）を保持する構造体です。この中にアーキテクチャ固有のレジスタ情報を含む mcontext_t が含まれます。シグナルハンドラはこれらの情報を用いて、シグナル発生時のプログラムの状態を検査し、必要に応じて変更することができます。

OS固有（GOOS）とアーキテクチャ固有（GOARCH）のコード

Goはクロスプラットフォーム開発を強力にサポートしており、異なるOS（Linux, macOS, Windowsなど）やCPUアーキテクチャ（amd64, arm, 386など）向けにコンパイルできます。Goランタイムの低レベルな部分は、OSやアーキテクチャに依存するC言語やアセンブリ言語で記述されています。

  • GOOS: Goがターゲットとするオペレーティングシステムを指します（例：linux, darwin (macOS), windows, freebsd, netbsd, openbsd, plan9）。
  • GOARCH: GoがターゲットとするCPUアーキテクチャを指します（例：amd64, 386, arm）。

これまでのGoランタイムでは、シグナルハンドリングのような機能が signal_GOOS_GOARCH.c のようなファイルで実装されており、OSとアーキテクチャの組み合わせごとに個別のファイルが存在していました。これは、OS固有のシステムコールとアーキテクチャ固有のレジスタ操作の両方が必要となるためですが、共通のロジックが重複する原因となっていました。

thread_GOOS.c から os_GOOS.c への変更

ファイル名が thread_GOOS.c から os_GOOS.c に変更されたのは、これらのファイルが単にスレッド関連の機能だけでなく、より広範なOS固有の機能（シグナルハンドリングの設定など）を扱うようになったことを反映しています。これにより、ファイルの内容と役割がより明確になります。

技術的詳細

このコミットは、Goランタイムのシグナルハンドリングサブシステムを根本的に再構築し、モジュール性と保守性を向上させています。主要な技術的変更点は以下の通りです。

  1. ファイル命名規則の変更と役割の再定義:
    • thread_GOOS.c から os_GOOS.c へのリネーム: これは単なるファイル名の変更以上の意味を持ちます。thread_GOOS.c は主にスレッド作成や管理といったOS固有の低レベルなスレッド関連機能を含んでいましたが、リファクタリング後は os_GOOS.c となり、シグナルハンドラの設定 (runtime·setsig, runtime·getsig) や代替シグナルスタックの管理 (runtime·signalstack) など、より広範なOS固有の機能を含むようになりました。これにより、OS固有の一般的なランタイム機能を集約する場所としての役割が明確化されました。
    • signal_GOOS_GOARCH.c の分割と再配置: これがこのコミットの最も重要な変更点です。
      • OS固有だがアーキテクチャ非依存のコードの os_GOOS.c への移動: 以前は signal_GOOS_GOARCH.c に含まれていた、特定のOSに依存するがCPUアーキテクチャには依存しないシグナル関連のロジック（例：sigactionシステムコールの呼び出しラッパーなど）が、対応する os_GOOS.c ファイルに移動されました。これにより、OS固有の機能は os_GOOS.c に集約され、アーキテクチャ固有のコードとの分離が図られました。
      • 純粋なアーキテクチャ固有のシグナルハンドラの signal_GOARCH.c への移動: 実際のシグナルハンドラ関数 (runtime·sighandler) やレジスタダンプ関数 (runtime·dumpregs) など、CPUアーキテクチャにのみ依存するコードは、signal_386.c, signal_amd64.c, signal_arm.c といった新しいファイルに移動されました。これにより、例えばLinux/amd64とFreeBSD/amd64で共通のamd64アーキテクチャ固有のシグナルハンドラコードを共有できるようになり、大幅なコード重複の削減が実現されました。
  2. signal_GOOS_GOARCH.h の導入:
    • これらの新しいヘッダーファイルは、OS固有かつアーキテクチャ固有のシグナル情報構造体（ucontext_tなど）のフィールドにアクセスするためのマクロ（例：SIG_EAX, SIG_RIP）を提供します。これにより、signal_GOARCH.c ファイル内の共通のシグナルハンドラコードは、これらのマクロを介して抽象化されたレジスタ情報にアクセスできるようになり、OSごとの構造体の違いを意識する必要がなくなりました。これは、アーキテクチャ固有のハンドラをOS非依存にするための重要な抽象化レイヤーです。
  3. コードの重複排除と行数削減:
    • コミットメッセージにある通り、このリファクタリングにより「-1081行のコード」という大幅な行数削減が達成されました。これは、共通ロジックの集約と重複コードの削除による直接的な効果であり、コードベース全体の軽量化と理解の容易さに貢献しています。
  4. 将来のメンテナンスの簡素化:
    • このリファクタリングの最大の目的は、シグナルハンドリングコードの変更を容易にすることです。以前は、シグナル関連のバグ修正や機能追加を行う際に、OSとアーキテクチャのすべての組み合わせに対して個別に変更を適用する必要がありました。新しい構造では、OS固有の変更は os_GOOS.c に、アーキテクチャ固有の変更は signal_GOARCH.c に、そして共通の抽象化は signal_GOOS_GOARCH.h に集中させることができます。これにより、変更の影響範囲が明確になり、開発者は「各変更を13回行う」という手間から解放されます。

このコミットは、Goランタイムの内部構造をより堅牢でスケーラブルなものにするための重要な一歩であり、低レベルなシステムプログラミングにおける設計原則（関心の分離、抽象化）がどのように適用されたかを示す好例です。

コアとなるコードの変更箇所

このコミットにおけるコアとなるコードの変更箇所は、主に以下のファイルのリネーム、移動、新規作成、および内容の変更に集約されます。

  1. ファイルのリネーム:

    • src/pkg/runtime/thread_darwin.c -> src/pkg/runtime/os_darwin.c
    • src/pkg/runtime/thread_freebsd.c -> src/pkg/runtime/os_freebsd.c
    • src/pkg/runtime/thread_linux.c -> src/pkg/runtime/os_linux.c
    • src/pkg/runtime/thread_netbsd.c -> src/pkg/runtime/os_netbsd.c
    • src/pkg/runtime/thread_openbsd.c -> src/pkg/runtime/os_openbsd.c
    • src/pkg/runtime/thread_plan9.c -> src/pkg/runtime/os_plan9.c
    • src/pkg/runtime/thread_windows.c -> src/pkg/runtime/os_windows.c
    • src/pkg/runtime/signal_plan9_386.c -> src/pkg/runtime/os_plan9_386.c
    • src/pkg/runtime/signal_plan9_amd64.c -> src/pkg/runtime/os_plan9_amd64.c
    • src/pkg/runtime/signal_windows_386.c -> src/pkg/runtime/os_windows_386.c
    • src/pkg/runtime/signal_windows_amd64.c -> src/pkg/runtime/os_windows_amd64.c

  2. 新規ファイルの作成:

    • src/pkg/runtime/signal_386.c (386アーキテクチャ共通のシグナルハンドラ)
    • src/pkg/runtime/signal_amd64.c (amd64アーキテクチャ共通のシグナルハンドラ)
    • src/pkg/runtime/signal_arm.c (ARMアーキテクチャ共通のシグナルハンドラ)
    • src/pkg/runtime/signal_darwin_386.h
    • src/pkg/runtime/signal_darwin_amd64.h
    • src/pkg/runtime/signal_freebsd_386.h
    • src/pkg/runtime/signal_freebsd_amd64.h
    • src/pkg/runtime/signal_freebsd_arm.h
    • src/pkg/runtime/signal_linux_386.h
    • src/pkg/runtime/signal_linux_amd64.h
    • src/pkg/runtime/signal_linux_arm.h
    • src/pkg/runtime/signal_netbsd_386.h
    • src/pkg/runtime/signal_netbsd_amd64.h
    • src/pkg/runtime/signal_netbsd_arm.h
    • src/pkg/runtime/signal_openbsd_386.h
    • src/pkg/runtime/signal_openbsd_amd64.h
    • src/pkg/runtime/signal_unix.c (Unix系OS共通のシグナル関連定義)
    • src/pkg/runtime/signal_unix.h (Unix系OS共通のシグナル関連定義)

  3. ファイルの削除:

    • src/pkg/runtime/signal_darwin_386.c (内容が signal_386.c と os_darwin.c に分割・移動)
    • src/pkg/runtime/signal_darwin_amd64.c (内容が signal_amd64.c と os_darwin.c に分割・移動)
    • src/pkg/runtime/signal_freebsd_386.c (内容が signal_386.c と os_freebsd.c に分割・移動)
    • src/pkg/runtime/signal_freebsd_amd64.c (内容が signal_amd64.c と os_freebsd.c に分割・移動)
    • src/pkg/runtime/signal_freebsd_arm.c (内容が signal_arm.c と os_freebsd.c に分割・移動)
    • 同様に、linux, netbsd, openbsd 向けの signal_GOOS_GOARCH.c ファイルも削除されています。

  4. 内容の変更:

    • os_GOOS.c ファイル:
      • thread_GOOS.c からリネームされたこれらのファイルには、signal_unix.h がインクルードされるようになりました。
      • runtime·setsig, runtime·getsig, runtime·signalstack といった、OS固有のシグナルハンドラ設定および代替スタック管理関数が追加（または移動）されました。これらの関数は、OSの sigaction や sigaltstack システムコールをラップしています。
    • os_GOOS.h ファイル:
      • 以前 thread_GOOS.c に関連していたシグナル関連の関数宣言（例: runtime·setsig, runtime·sighandler）が削除されました。これらの宣言は、新しい signal_unix.h や signal_GOOS_GOARCH.h に移動されたか、あるいはアーキテクチャ固有の signal_GOARCH.c ファイル内で直接定義されるようになりました。
    • signal_GOARCH.c ファイル (例: signal_386.c, signal_amd64.c, signal_arm.c):
      • これらのファイルには、runtime·dumpregs (レジスタダンプ) と runtime·sighandler (実際のシグナルハンドラ) の実装が含まれています。
      • これらの実装は、対応する signal_GOOS_GOARCH.h で定義されたマクロ（例: SIG_EIP, SIG_RIP, SIG_ESP, SIG_RSP）を使用して、シグナルコンテキスト（Siginfo, ctxt）からCPUレジスタの値にアクセスします。これにより、同じ runtime·sighandler のロジックが異なるOSで再利用可能になります。
      • runtime·sighandler は、SIGPROF の処理、致命的なシグナル（SigPanic フラグを持つもの）に対するパニックの開始、およびシグナル通知 (SigNotify) の処理を行います。
    • signal_GOOS_GOARCH.h ファイル:
      • これらのファイルは、特定のOSとアーキテクチャの組み合わせにおけるシグナルコンテキスト構造体（Ucontext, Mcontext など）から、汎用的なレジスタ名（例: EAX, RIP, ESP）に対応する値を抽出するためのマクロを定義しています。これにより、signal_GOARCH.c のコードがOS固有の構造体の詳細から分離されます。
    • src/cmd/dist/build.c:
      • ビルドシステムが、新しい signal_GOOS_GOARCH.h ファイルを適切にコピーするように変更が加えられました。

これらの変更は、Goランタイムのシグナルハンドリング部分の構造を大幅に改善し、コードの重複を排除し、将来の拡張とメンテナンスを容易にすることを目的としています。

コアとなるコードの解説

このコミットの核心は、Goランタイムのシグナルハンドリングロジックを、OS固有の部分とアーキテクチャ固有の部分に明確に分離し、共通化することにあります。

signal_GOOS_GOARCH.h の役割

これらのヘッダーファイルは、シグナルハンドラがシグナル発生時のCPUの状態（レジスタの値など）にアクセスするための抽象化レイヤーを提供します。例えば、signal_darwin_386.h には以下のようなマクロが定義されています。

#define SIG_REGS(ctxt) (((Ucontext*)(ctxt))->uc_mcontext->ss)

#define SIG_EAX(info, ctxt) (SIG_REGS(ctxt).eax)
#define SIG_ESP(info, ctxt) (SIG_REGS(ctxt).esp)
#define SIG_EIP(info, ctxt) (SIG_REGS(ctxt).eip)
// ... 他のレジスタマクロ

これらのマクロは、ucontext_t 構造体（またはそれに相当するOS固有のコンテキスト構造体）の内部にあるアーキテクチャ固有のレジスタセット（mcontext_t や ss など）から、特定のレジスタ（eax, esp, eip など）の値を取り出す方法を定義しています。

これにより、signal_386.c のようなアーキテクチャ固有のシグナルハンドラファイルは、OSごとの ucontext_t の内部構造の違いを意識することなく、SIG_EIP(info, ctxt) のように汎用的なマクロを使ってプログラムカウンタにアクセスできるようになります。これは、コードの再利用性を高める上で非常に重要です。

signal_GOARCH.c (例: signal_386.c, signal_amd64.c) の runtime·sighandler

これらのファイルには、各アーキテクチャに共通のシグナルハンドラである runtime·sighandler 関数が実装されています。この関数は、OSからシグナルを受信した際に呼び出され、以下の主要な処理を行います。

  1. シグナル情報の取得: sig (シグナル番号), info (シグナル詳細情報), ctxt (シグナルコンテキスト), gp (現在のGoルーチン) を引数として受け取ります。
  2. プロファイリングシグナル (SIGPROF) の処理:
    • もし受信したシグナルが SIGPROF であり、かつ現在のGoルーチンがランタイムの内部Goルーチン (m->g0 や m->gsignal) でない場合、runtime·sigprof 関数を呼び出してプロファイリングデータを記録します。
  3. 致命的なシグナル (SigPanic フラグを持つシグナル) の処理:
    • SIGSEGV, SIGBUS, SIGILL, SIGFPE など、プログラムの異常終了を引き起こす可能性のあるシグナルを受信した場合、Goのパニックメカニズムをトリガーします。
    • gp->sig, gp->sigcode0, gp->sigcode1, gp->sigpc といったGoルーチン構造体のフィールドにシグナル情報を格納します。これにより、パニック発生時に詳細なシグナル情報をGoコードから参照できるようになります。
    • 特に重要なのは、シグナル発生時のプログラムカウンタ（SIG_EIP(info, ctxt) や SIG_RIP(info, ctxt)）をスタックにプッシュし、プログラムカウンタを runtime·sigpanic 関数に設定する部分です。これにより、シグナルハンドラから戻った際に runtime·sigpanic が実行され、Goのパニック処理が開始されます。これは、C言語のシグナルハンドラからGoのランタイムに制御を移すための重要なメカニズムです。
  4. ユーザーシグナル (SI_USER) や通知シグナル (SigNotify) の処理:
    • ユーザーが kill コマンドなどで明示的に送信したシグナルや、ランタイムがGoルーチンに通知すべきシグナルを受信した場合、runtime·sigsend を呼び出してGoのシグナル処理メカニズムに渡します。
  5. 終了シグナル (SigKill) の処理:
    • SIGKILL のような即時終了を意味するシグナルを受信した場合、runtime·exit(2) を呼び出してプロセスを終了します。
  6. トレースバックとレジスタダンプ:
    • 致命的なシグナルでパニックが発生した場合、runtime·startpanic() を呼び出してパニック処理を開始し、runtime·printf でシグナル名やPC（プログラムカウンタ）を出力します。
    • runtime·gotraceback() が真の場合、runtime·traceback を呼び出してGoルーチンのスタックトレースを出力し、runtime·dumpregs を呼び出してシグナル発生時のCPUレジスタの値をダンプします。これはデバッグに非常に役立つ情報です。

os_GOOS.c の runtime·setsig, runtime·getsig, runtime·signalstack

これらの関数は、OS固有のシグナル管理インターフェースを提供します。

  • runtime·setsig(int32 i, GoSighandler *fn, bool restart):
    • 指定されたシグナル番号 i に対して、シグナルハンドラ fn を設定します。
    • SA_SIGINFO (詳細なシグナル情報を取得), SA_ONSTACK (代替シグナルスタックを使用), SA_RESTART (システムコールの中断からの再開) などのフラグを設定します。
    • sa.sa_tramp (または sa.sa_restorer) に runtime·sigtramp を設定します。これは、OSのシグナルディスパッチャから実際のGoのシグナルハンドラ (runtime·sighandler) を呼び出すためのアセンブリコードへのポインタです。
    • 最終的にOSの sigaction システムコールを呼び出して、シグナルハンドラを登録します。
  • runtime·getsig(int32 i):
    • 指定されたシグナル番号 i に現在設定されているシグナルハンドラを取得します。
    • OSの sigaction システムコールを呼び出して、現在のハンドラ情報を取得します。
    • runtime·sigtramp が設定されている場合は、Goの内部ハンドラである runtime·sighandler を返します。
  • runtime·signalstack(byte *p, int32 n):
    • 代替シグナルスタックを設定します。これは、通常のスタックが破損した場合や、シグナルハンドラが非常に深いスタックを必要とする場合に、安全にシグナルを処理するために使用されます。
    • OSの sigaltstack システムコールを呼び出して、スタックポインタ p とサイズ n を設定します。

これらの関数は、OS固有の sigaction や sigaltstack の詳細を抽象化し、Goランタイムの他の部分がシグナルハンドリングを設定するための統一されたインターフェースを提供します。

全体像

このリファクタリングにより、Goランタイムのシグナル処理は以下のような階層構造を持つことになります。

  1. OS固有のインターフェース (os_GOOS.c): runtime·setsig など、OSのシステムコールを直接呼び出してシグナルハンドラを設定する。
  2. OS/アーキテクチャ固有の抽象化 (signal_GOOS_GOARCH.h): ucontext_t などのOS固有のコンテキスト構造体からレジスタ値を抽出するためのマクロを提供する。
  3. アーキテクチャ固有のシグナルハンドラ (signal_GOARCH.c): runtime·sighandler のような実際のシグナル処理ロジックを実装し、signal_GOOS_GOARCH.h のマクロを使ってレジスタ情報にアクセスする。

この分離により、Goランタイムは異なるプラットフォーム間でシグナルハンドリングコードをより効率的に共有・管理できるようになり、Goのクロスプラットフォーム対応能力をさらに強化しています。

関連リンク

参考にした情報源リンク