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

このコミットは、Go言語のリンカ (cmd/ld) と低レベルリンキングライブラリ (liblink) における、命令選択とレイアウトに関する重要な変更を導入しています。主な目的は、これらの処理をコンパイラとアセンブラに移行し、オブジェクトファイルの構造を簡素化することです。

コミット

commit a9f6db58cea016957391f3ca9d36247177895e96
Author: Russ Cox <rsc@golang.org>
Date:   Mon Dec 16 12:51:58 2013 -0500

    cmd/ld: move instruction selection + layout into compilers, assemblers
    
    - new object file reader/writer (liblink/objfile.c)
    - remove old object file writing routines
    - add pcdata iterator
    - remove all trace of "line number stack" and "path fragments" from
      object files, linker (!!!)
    - dwarf now writes a single "compilation unit" instead of one per package
    
    This CL disables the check for chains of no-split functions that
    could overflow the stack red zone. A future CL will attack the problem
    of reenabling that check (issue 6931).
    
    This CL is just the liblink and cmd/ld changes.
    There are minor associated adjustments in CL 37030045.
    Each depends on the other.
    
    R=golang-dev, dave, iant
    CC=golang-dev
    https://golang.org/cl/39680043

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

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

元コミット内容

Go言語のリンカ (cmd/ld) とリンキングライブラリ (liblink) において、命令選択とレイアウトの責任をコンパイラとアセンブラに移管する変更。

主な変更点：

新しいオブジェクトファイル読み書きルーチン (liblink/objfile.c) の導入。
古いオブジェクトファイル書き込みルーチンの削除。
pcdata イテレータの追加。
オブジェクトファイルおよびリンカから「行番号スタック」と「パスフラグメント」の痕跡を完全に削除。
DWARFデバッグ情報において、パッケージごとにコンパイル単位を生成するのではなく、単一のコンパイル単位を生成するように変更。

このコミットでは、スタックのレッドゾーンをオーバーフローさせる可能性のある no-split 関数の連鎖チェックを一時的に無効にしています（Issue 6931）。この問題は将来のコミットで再有効化される予定です。

このコミットは liblink と cmd/ld の変更のみを含み、CL 37030045 と相互に依存しています。

変更の背景

このコミットの背景には、Goツールチェーンのアーキテクチャを改善し、リンカの複雑性を軽減するという大きな目標があります。以前のGoツールチェーンでは、リンカが命令選択（アセンブリ命令の最終的な選択）やコードレイアウトの一部を担当していました。これは、リンカがオブジェクトファイルの低レベルな詳細に深く関与していることを意味します。

しかし、このような設計はいくつかの問題を引き起こしていました。

複雑性の集中: リンカが多くの役割を担うことで、そのコードベースが肥大化し、保守が困難になっていました。
最適化の機会の損失: 命令選択やレイアウトは、コンパイラやアセンブラがより多くのコンテキストを持つため、それらの段階で行う方が効率的で、より良い最適化が可能になる場合があります。
オブジェクトファイルの複雑性: リンカが低レベルな情報を処理するために、オブジェクトファイル自体が「行番号スタック」や「パスフラグメント」といったリンカ固有の複雑なメタデータを持つ必要がありました。これはオブジェクトファイルのフォーマットを不必要に複雑にし、ツールチェーン全体の理解を妨げていました。
デバッグ情報の生成: DWARFデバッグ情報の生成もリンカの責任の一部でしたが、パッケージごとにコンパイル単位を生成するアプローチは、大規模なプロジェクトでデバッグ情報のサイズを増大させる可能性がありました。

このコミットは、これらの問題を解決するために、リンカの役割をより純粋な「リンク」機能に限定し、命令選択とレイアウトの責任をコンパイラとアセンブラに委譲することを目指しています。これにより、ツールチェーンの各コンポーネントがより専門化され、全体としての効率性、保守性、最適化の可能性が向上します。特に、「行番号スタック」や「パスフラグメント」の削除は、オブジェクトファイルのフォーマットを大幅に簡素化し、Goのツールチェーンのクリーンアップにおける重要な一歩となります。

前提知識の解説

このコミットを理解するためには、以下の概念について基本的な知識が必要です。

Goツールチェーンの構成要素:
- コンパイラ (cmd/compile): Goのソースコードをアセンブリコード（または中間表現）に変換します。
- アセンブラ (cmd/asm): アセンブリコードをオブジェクトファイルに変換します。
- リンカ (cmd/ld): 複数のオブジェクトファイルとライブラリを結合し、実行可能ファイルや共有ライブラリを生成します。
- liblink: リンカが使用する低レベルのリンキングライブラリ。
オブジェクトファイル: コンパイラやアセンブラによって生成される中間ファイルで、機械語コード、データ、シンボル情報、リロケーション情報などが含まれます。Goのオブジェクトファイルは、一般的なELFやMach-Oとは異なる独自のフォーマットを持つことがあります。
命令選択 (Instruction Selection): コンパイラのバックエンドやアセンブラの段階で行われる処理で、高レベルな操作（例: x = y + z）を、ターゲットアーキテクチャの具体的な機械語命令（例: ADD R1, R2, R3）に変換するプロセスです。このコミット以前は、リンカがこのプロセスの一部に関与していました。
コードレイアウト (Code Layout): 生成された機械語コードをメモリ上でどのように配置するかを決定するプロセスです。これには、関数の配置順序、データセクションの配置などが含まれます。リンカは最終的なレイアウトを決定する上で重要な役割を果たしますが、このコミットではその責任の一部がコンパイラ/アセンブラに移行されます。
pcdata: Goのランタイムが使用するメタデータの一種で、プログラムカウンタ (PC) の値に基づいて、スタックフレームのレイアウト、ガベージコレクションのポインタ情報、行番号情報などを効率的にルックアップするために使用されます。pcdata は、PC値とそれに対応するデータのマッピングを圧縮形式で格納します。このコミットで導入される「pcdata イテレータ」は、この圧縮された pcdata を効率的に走査するためのメカニズムです。
行番号スタック (Line Number Stack) とパスフラグメント (Path Fragments): これらは、Goの古いオブジェクトファイルフォーマットで使用されていた、ソースコードのファイルパスと行番号情報を表現するためのメカニズムです。特に、#line ディレクティブなどによってソースファイルがインクルードされる際に、その履歴を追跡するために「スタック」のような構造が用いられていました。しかし、これは複雑で、デバッグ情報の生成を非効率にしていました。このコミットでは、これらの概念が完全に削除され、よりシンプルで効率的な方法に置き換えられます。
DWARF (Debugging With Attributed Record Formats): Unix系システムで広く使われている標準的なデバッグ情報フォーマットです。コンパイルされたプログラムのソースコードレベルでのデバッグを可能にするために、変数、関数、型、ソースファイルと行番号のマッピングなどの情報を提供します。
- コンパイル単位 (Compilation Unit, CU): DWARFにおけるデバッグ情報の基本的な単位です。通常、一つのソースファイル（またはその一部）がコンパイルされて一つのオブジェクトファイルになる場合、そのオブジェクトファイルに対応するデバッグ情報がCUとして表現されます。このコミットでは、Goのリンカがパッケージごとに複数のCUを生成するのではなく、単一のCUを生成するように変更されます。これは、デバッグ情報の管理とサイズに影響を与えます。
スタックレッドゾーン (Stack Red Zone): 一部のアーキテクチャ（特にx86-64）において、関数プロローグでスタックポインタを調整する前に、スタックポインタのすぐ下にある小さな領域（通常128バイト）を一時的に使用できるという最適化の概念です。この領域は「レッドゾーン」と呼ばれ、関数呼び出しの際に上書きされる可能性があるため、注意が必要です。no-split 関数（スタックチェックを行わない関数）が連鎖すると、このレッドゾーンがオーバーフローするリスクがあり、このコミットではそのチェックが一時的に無効化されています。

これらの概念を理解することで、このコミットがGoツールチェーンの内部構造に与える影響と、それがもたらすメリットをより深く把握できます。

技術的詳細

このコミットは、Goツールチェーンのバックエンド、特にリンカとオブジェクトファイルの処理方法に根本的な変更をもたらします。

1. 命令選択とレイアウトのコンパイラ/アセンブラへの移行

変更の目的: 以前はリンカが一部の命令選択やコードレイアウトの最終決定に関与していましたが、この変更により、これらの責任がコンパイラ (cmd/compile) とアセンブラ (cmd/asm) に完全に移管されます。
メリット:
- 効率性の向上: コンパイラとアセンブラは、ソースコードのセマンティクスやターゲットアーキテクチャの特性についてより詳細な知識を持っているため、より効率的な命令選択とコードレイアウトを行うことができます。
- リンカの簡素化: リンカは、オブジェクトファイルの結合、シンボル解決、リロケーション処理といった、より純粋なリンキングタスクに集中できるようになります。これにより、リンカのコードベースが簡素化され、保守性が向上します。
- 最適化の機会: コンパイラ/アセンブラの段階でより多くの情報に基づいて命令選択が行われることで、より高度な最適化（例: 命令スケジューリング、レジスタ割り当ての改善）が可能になる場合があります。

2. 新しいオブジェクトファイルリーダー/ライター (`liblink/objfile.c`)

導入の理由: 命令選択とレイアウトの責任が移行されたことに伴い、オブジェクトファイルのフォーマットも変更されるため、新しいフォーマットに対応するための読み書きルーチンが必要になります。
機能: liblink/objfile.c は、新しい、より簡素化されたオブジェクトファイルフォーマットを解析し、リンカが処理できる内部表現に変換する役割を担います。また、リンカが生成する最終的なオブジェクトコードを書き出す際にも使用されます。
影響: この変更は、Goのオブジェクトファイルフォーマットが内部的に進化していることを示しており、将来的なツールチェーンの拡張性や効率性向上に寄与します。

3. `pcdata` イテレータの追加

pcdata の役割: pcdata は、Goのランタイムがスタックトレース、ガベージコレクション、デバッグなどの目的で、プログラムカウンタ (PC) に基づいて特定の情報を効率的に取得するために使用する圧縮されたデータです。
イテレータの目的: pcdata は通常、可変長エンコーディングやデルタエンコーディングを用いて圧縮されています。pcdata イテレータは、この圧縮されたデータを透過的にデコードし、PC値とそれに対応する値のペアを簡単に走査できるようにするための抽象化レイヤーを提供します。
メリット: ランタイムやデバッグツールが pcdata をより簡単に、かつ効率的に利用できるようになります。これにより、スタックトレースの生成やデバッグ情報の取得が高速化される可能性があります。

4. 「行番号スタック」と「パスフラグメント」の削除

問題点: Goの古いオブジェクトファイルフォーマットでは、ソースファイルのパスと行番号情報を表現するために「行番号スタック」と「パスフラグメント」という複雑なメカニズムが使用されていました。これは、特にCgoのような外部CコードをGoにリンクする際に、#line ディレクティブによってソースファイルがインクルードされる履歴を追跡するために設計されていました。しかし、このメカニズムは非常に複雑で、デバッグ情報の生成を非効率にしていました。
変更の目的: このコミットは、これらの複雑なメカニズムを完全に廃止し、よりシンプルで直接的な行番号情報表現に移行します。
メリット:
- オブジェクトファイルの簡素化: オブジェクトファイルのフォーマットが大幅に簡素化され、解析と生成が容易になります。
- デバッグ情報の効率化: デバッグ情報の生成がより効率的になり、デバッグツールの開発が容易になります。
- ツールチェーンのクリーンアップ: 長年Goツールチェーンの複雑性の原因となっていた要素が取り除かれ、全体的な設計が改善されます。

5. DWARFコンパイル単位の変更（パッケージごとから単一へ）

以前の挙動: 以前のGoリンカは、Goの各パッケージに対して個別のDWARFコンパイル単位 (CU) を生成していました。
変更後の挙動: このコミット以降、リンカはGoプログラム全体に対して単一のDWARFコンパイル単位を生成します。
影響:
- デバッグ情報のサイズ: 単一のCUにまとめることで、デバッグ情報のメタデータのオーバーヘッドが削減され、最終的な実行可能ファイルのサイズがわずかに減少する可能性があります。
- デバッグツールの処理: デバッグツールは、複数のCUを処理する代わりに、単一のCUを解析するだけでよくなるため、デバッグ情報のロードと解析が高速化される可能性があります。
- Goの特性の反映: Goのプログラムは、複数のパッケージから構成されていても、最終的には単一のバイナリとしてリンクされるため、単一のCUはGoのプログラム構造をより自然に反映していると言えます。

6. `no-split` 関数のスタックレッドゾーンチェックの一時的無効化

背景: no-split 関数は、スタックの拡張チェックを行わない関数です。これらの関数が連鎖して呼び出されると、スタックのレッドゾーン（関数プロローグで一時的に使用される領域）をオーバーフローさせるリスクがあります。
一時的無効化の理由: このコミットは、リンカの内部構造に大きな変更を加えるため、既存のスタックチェックメカニズムとの互換性の問題が発生した可能性があります。このチェックを一時的に無効にすることで、主要な変更を先行してマージし、後続のコミットでこの問題を解決するアプローチが取られています（Issue 6931）。
重要性: これは一時的な措置であり、スタックオーバーフローの潜在的なリスクを伴うため、将来のコミットでこのチェックが再有効化されることが重要です。

これらの技術的詳細は、Goツールチェーンの進化におけるこのコミットの重要性を示しています。リンカの役割を再定義し、オブジェクトファイルのフォーマットを簡素化することで、Goのコンパイルとリンクのプロセスがより効率的で、保守しやすくなっています。

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

このコミットは、Goリンカの複数のファイルにわたる広範な変更を含んでいますが、特に以下のファイルがコアとなる変更箇所です。

src/liblink/objfile.c (新規追加):
- このファイルは、新しいオブジェクトファイルフォーマットの読み書きを担当するルーチンを実装しています。これは、古いオブジェクトファイル書き込みルーチンが削除されたことと、命令選択とレイアウトがコンパイラ/アセンブラに移行されたことに伴う、最も重要な追加ファイルです。
- ldobjfile 関数などが含まれ、オブジェクトファイルからシンボル、コード、データ、pcdata などの情報を読み込む役割を担います。
include/link.h:
- Hist2 構造体（古い行番号スタック関連）の削除。
- Pciter 構造体（pcdata イテレータ）の追加と関連関数の宣言 (pciterinit, pciternext)。
- Link 構造体から histfrog, histfrogp, histgen, histcopy, hist2, nhist2, maxhist2 といった古い行番号スタック関連のフィールドの削除。
- LinkArch 構造体から ldobj, nopout, zfile, zhist, zprog, zname といった古いオブジェクトファイル処理関連の関数ポインタの削除。
- LinkArch に thechar (アーキテクチャ文字 '5', '6' など) の追加。
- asm5.c 関連の関数 (chipfloat5, chipzero5) の宣言追加。
- ld.c 関連の関数 (addlib, linkgetline) のシグネチャ変更。
- objfile.c 関連の関数 (ldobjfile, linkwriteobj) の宣言追加。
- rdobj*.c (古いオブジェクトファイル読み込みルーチン) 関連の関数宣言の削除。
src/cmd/ld/dwarf.c:
- dwarfaddfrag, decodez, clearhistfile, addhistfile, inithist, searchhist, guesslang といった、古い「行番号スタック」と「パスフラグメント」に関連する関数が大幅に削除またはコメントアウトされています。
- writelines 関数が大幅に書き換えられ、pcdata イテレータ (pciterinit, pciternext) を使用して行番号情報を処理し、単一のDWARFコンパイル単位を生成するように変更されています。
- writeframes 関数も pcdata イテレータを使用するように変更されています。
src/cmd/ld/go.c:
- markflood 関数から Prog* p のループが削除され、s->pcln (Pcln構造体) を介して funcdata をマークするように変更されています。これは、命令選択とレイアウトがリンカから分離されたことによる変更です。
- isz, addz といった古い行番号スタック関連の関数が削除されています。
- deadcode 関数から古い行番号スタック関連の処理が削除されています。
src/cmd/ld/lib.c:
- addlib 関数のシグネチャが変更され、pathname 引数が追加されています。
- ldobj 関数内で、古い ctxt->arch->ldobj の呼び出しが ldobjfile に置き換えられています。
- dostkcheck 関数に // TODO コメントが追加され、no-split 関数のスタックチェックが無効化されていることが明示されています。
- headtype, headstr といった、リンカのヘッダタイプを扱う関数が src/liblink/sym.c に移動されたため、このファイルからは削除されています。
- main 関数から patch(), follow(), dostkoff(), span(), pcln() といったリンカの主要なパスの呼び出しが削除されています。これは、これらの処理が新しいオブジェクトファイルフォーマットの読み込みと同時に行われるか、あるいはコンパイラ/アセンブラに移行されたためです。
src/cmd/ld/pcln.c:
- getvarint 関数が削除され、pcdata のデコードが Pciter 構造体と pciternext 関数に委譲されています。
- renumberfiles 関数が Pciter を使用するように変更されています。
- pclntab 関数内で、関数の引数サイズとフレームサイズの計算方法が変更され、ctxt->cursym->text への直接アクセスが削除されています。
src/liblink/obj*.c (例: src/liblink/obj5.c, src/liblink/obj6.c, src/liblink/obj8.c):
- これらのファイルは、各アーキテクチャ（ARM, AMD64, 386）固有のオブジェクトファイル書き込みルーチンを含んでいましたが、新しい objfile.c に置き換えられたため、大幅に削除されています。
src/liblink/rdobj*.c (例: src/liblink/rdobj5.c, src/liblink/rdobj6.c, src/liblink/rdobj8.c):
- これらのファイルは、各アーキテクチャ固有のオブジェクトファイル読み込みルーチンを含んでいましたが、新しい objfile.c に置き換えられたため、ファイル自体が削除されています。

これらの変更は、Goツールチェーンのリンカとオブジェクトファイル処理のアーキテクチャを根本的に再構築するものであり、リンカの役割をより明確にし、デバッグ情報の生成を効率化することを目的としています。

コアとなるコードの解説

このコミットのコアとなる変更は、Goリンカの内部アーキテクチャを刷新し、特にオブジェクトファイルの処理とデバッグ情報の生成方法を近代化することにあります。

1. `liblink/objfile.c` の導入と古いオブジェクトファイル処理の削除

役割: liblink/objfile.c は、Goの新しいオブジェクトファイルフォーマットを読み書きするための中心的なコンポーネントです。以前は、各アーキテクチャ (5l, 6l, 8l など) ごとにオブジェクトファイルの読み書きルーチンが分散していましたが、このコミットにより、それらの機能が objfile.c に集約されました。
実装の詳細:
- ldobjfile(Link *ctxt, Biobuf *b, char *pkg, int64 len, char *path): この関数は、指定された Biobuf (バイナリI/Oバッファ) からオブジェクトファイルの内容を読み込み、リンカの内部データ構造 (LSym など) に変換します。これにより、リンカはアーキテクチャに依存しない統一された方法でオブジェクトファイルを処理できるようになります。
- linkwriteobj(Link *ctxt, Biobuf *b): リンカが最終的に生成するオブジェクトコードを、新しいフォーマットで書き出す役割を担います。
影響: この変更により、Goのオブジェクトファイルフォーマットがより抽象化され、リンカのコードベースが大幅に簡素化されました。また、将来的に新しいアーキテクチャやオブジェクトファイルフォーマットの変更に対応する際の柔軟性が向上します。

2. `pcdata` イテレータ (`Pciter`) の導入

背景: Goのバイナリには、プログラムカウンタ (PC) に関連する様々なメタデータ（例: スタックフレーム情報、ガベージコレクションのポインタマップ、行番号情報）が pcdata として格納されています。これらのデータは通常、サイズを削減するために圧縮された形式で保存されています。
Pciter 構造体と関連関数:
```
typedef struct Pciter
{
    Pcdata d;
    uchar *p;
    uint32 pc;
    uint32 nextpc;
    int32 value;
    int start;
    int done;
} Pciter;

void pciterinit(Pciter*, Pcdata*);
void pciternext(Pciter*);
```
- Pciter 構造体は、pcdata の走査状態を保持します。d は元の Pcdata、p は現在の読み込み位置、pc と nextpc は現在のPC範囲、value はそのPC範囲に対応する値を示します。done は走査が完了したかどうかを示します。
- pciterinit(Pciter* it, Pcdata* d): Pciter を初期化し、指定された Pcdata を走査できるように準備します。
- pciternext(Pciter* it): イテレータを次の pcdata エントリに進めます。これにより、it->pc, it->nextpc, it->value が更新され、次のPC範囲とその値が提供されます。

利用例 (src/cmd/ld/dwarf.c の writelines 関数):

// ...
Pciter pcfile, pcline;
// ...
pciterinit(&pcfile, &s->pcln->pcfile); // ファイル情報用のpcdataを初期化
pciterinit(&pcline, &s->pcln->pcline); // 行番号情報用のpcdataを初期化
while(!pcfile.done && !pcline.done) {
    // ...
    // pcfile.value や pcline.value を使用してファイルや行番号情報を取得
    // ...
    putpclcdelta(epc - pc, pcline.value - line); // PCと行番号のデルタを書き込む
    pc = epc;
    line = pcline.value;
}

影響: pcdata イテレータの導入により、pcdata のデコードロジックがリンカの他の部分から分離され、コードの可読性と保守性が向上しました。また、pcdata の処理がより効率的になり、デバッグ情報の生成やランタイムでの情報取得が高速化されます。

3. 「行番号スタック」と「パスフラグメント」の完全削除

背景: 前述の通り、これらはGoの古いオブジェクトファイルフォーマットにおける複雑な行番号情報表現でした。
削除されたコードの例 (src/cmd/ld/dwarf.c):
- dwarfaddfrag, decodez, clearhistfile, addhistfile といった、パスフラグメントや行番号スタックを管理する関数が削除されました。
- inithist, searchhist といった、行履歴を初期化・検索する関数も削除されました。
影響: この削除は、Goツールチェーンの歴史的な負債を解消する重要なステップです。オブジェクトファイルのフォーマットが大幅に簡素化され、デバッグ情報の生成プロセスがより直接的で効率的になりました。これにより、Goのツールチェーン全体の理解とメンテナンスが容易になります。

4. DWARFコンパイル単位の変更 (`src/cmd/ld/dwarf.c`)

変更点: writelines 関数内で、以前はパッケージごとに複数のDWARFコンパイル単位を生成していたロジックが、Goプログラム全体で単一のコンパイル単位を生成するように変更されました。
実装の詳細:
- dwinfo = newdie(&dwroot, DW_ABRV_COMPUNIT, estrdup("go")); のように、ルートとなるコンパイル単位が一つだけ作成されます。
- ファイル名情報は、ctxt->filesyms (リンカが認識するファイルシンボル) から取得され、DWARFのファイル名テーブルに書き込まれます。
影響: デバッグ情報のサイズが削減され、デバッグツールの処理が簡素化されます。これは、Goのプログラムが単一のバイナリとしてリンクされるという特性とより整合性が取れています。

これらのコアとなるコード変更は、Goツールチェーンの内部構造を大幅に改善し、将来の機能拡張やパフォーマンス最適化のための強固な基盤を築いています。

参考にした情報源リンク

Goのソースコード (特に上記の変更されたファイル)
DWARF Debugging Information Format Standard: DWARFの仕様に関する公式ドキュメント。コンパイル単位や行番号情報の構造について詳細が記述されています。
- https://dwarfstd.org/
Goのリンカに関する議論やドキュメント（Goの公式ブログやデザインドキュメントなど、当時の情報源）
- 当時のGoのリンカの設計に関する情報は、Goのメーリングリストやデザインドキュメントに散見されます。
Goのオブジェクトファイルフォーマットに関する情報（Goのソースコード内のコメントや、関連するデザインドキュメント）
- Goのオブジェクトファイルフォーマットは公開された仕様書があるわけではないため、主にソースコードの解析や関連するコミット履歴から理解する必要があります。
コンパイラとリンカの一般的な概念に関する情報（コンピュータサイエンスの教科書やオンラインリソース）
- 命令選択、コードレイアウト、pcdata、スタックレッドゾーンなどの概念は、コンパイラ設計やシステムプログラミングの一般的な知識に基づいています。
Goのランタイムに関する情報（Goのソースコード内の runtime パッケージや、関連するデザインドキュメント）
- pcdata の利用方法やスタック管理の詳細は、Goのランタイムの内部実装を理解する上で重要です。

これらの情報源は、このコミットがGoツールチェーンに与える影響を深く理解するために参照されました。

comemo