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

src/cmd/cc/pgen.c は、Goコンパイラの一部であり、C言語のコードを生成する際に使用されるファイルです。特に、Cgo（GoとCの相互運用機能）によってGoからC関数を呼び出す際の、引数の処理やガベージコレクション（GC）のためのポインタマップ生成に関連するコードが含まれています。このファイルは、GoランタイムがC関数呼び出し時にメモリを正確に管理するために重要な役割を担っています。

コミット

このコミットは、以前のコミット CL 11788043 / 62d06cccc261 を元に戻す（undo）ものです。CL 11788043 は、CL 11683043 を元に戻したコミットでした。つまり、このコミット ad5cd931d8f7738752fbd471081b15e9931e7d2b は、CL 11683043 で導入された変更を再度有効にするものです。CL 11788043 が引き起こしたARMビルドの破損が、別のコミット CL 11888043 によって修正されたため、CL 11788043 を元に戻すことが可能になりました。

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

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

元コミット内容

undo CL 11788043 / 62d06cccc261

Reason for breakage fixed with CL 11888043.

««« original CL description
undo CL 11683043 / bb75d03e6ccb

Broke arm build.
R=dave

««« original CL description
cc: generate argument pointer maps for C functions.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/11683043
»»»

R=golang-dev
CC=golang-dev
https://golang.org/cl/11788043
»»»

TBR=dave
CC=golang-dev
https://golang.org/cl/11789043

変更の背景

このコミットは、GoコンパイラのCコード生成部分における、C関数の引数ポインタマップ生成に関する一連の変更と巻き戻しの最終段階です。

CL 11683043: 最初に、C関数の引数に対してポインタマップを生成する機能が導入されました。これは、GoのガベージコレクタがCgoを介して呼び出されるC関数スタック上のポインタを正確に識別し、追跡するために必要です。
CL 11788043: しかし、この変更（CL 11683043）はARMアーキテクチャでのビルドを破損させました。そのため、CL 11788043 は CL 11683043 を元に戻す形でコミットされました。
CL 11888043: その後、ARMビルドの破損の原因が特定され、CL 11888043 によってその問題が修正されました。
本コミット (CL 11789043): ARMビルドの破損が修正されたため、CL 11788043（CL 11683043 を元に戻したもの）を元に戻すことが可能になりました。これにより、C関数の引数ポインタマップ生成機能が再び有効になり、GoのGCがCgoのシナリオでより堅牢に動作するようになります。

この一連の経緯は、Goのクロスコンパイルと異なるアーキテクチャ（特にARMのような組み込みシステムでよく使われるもの）での互換性を維持することの複雑さを示しています。

前提知識の解説

GoのGC (Garbage Collection) とポインタマップ

Goは、自動メモリ管理（ガベージコレクション）を採用しています。GCは、プログラムが不要になったメモリ領域を自動的に解放し、メモリリークを防ぎます。GCが正しく動作するためには、ヒープ上に存在するポインタを正確に識別し、到達可能なオブジェクトを追跡する必要があります。

GoのGCは、スタックやヒープ上のポインタをスキャンして、到達可能なオブジェクトをマークします。このスキャンを効率的かつ正確に行うために、「ポインタマップ」が使用されます。ポインタマップは、特定のメモリ領域（例えば、関数のスタックフレームや構造体）のどのオフセットにポインタが含まれているかを示すビットマップのようなデータ構造です。これにより、GCはメモリ領域全体をスキャンするのではなく、ポインタが確実に存在する場所だけをチェックできます。

`FUNCDATA_GC`

FUNCDATA_GC は、Goの関数に関連付けられたメタデータの一種で、その関数のスタックフレーム内のポインタのレイアウトを記述するポインタマップを指します。Goランタイムは、関数が呼び出された際にこの FUNCDATA_GC を参照し、GCがスタックをスキャンする際に利用します。Cgoを介してC関数が呼び出される場合、GoランタイムはC関数のスタックフレームもGCの対象として考慮する必要があるため、C関数の引数やローカル変数にポインタが含まれる場合、その情報もポインタマップとして提供される必要があります。

Goコンパイラの`cc`コマンド (Cgoとの関連)

Goのビルドシステムには、Cgoという機能があります。Cgoを使用すると、GoプログラムからC言語のコードを呼び出したり、C言語のコードからGoの関数を呼び出したりできます。Cgoは、GoとCの間のインターフェースコードを生成するために、Goコンパイラの一部として cmd/cc (Cコンパイラ) を使用します。src/cmd/cc/pgen.c は、この cc コマンドがCgoによって生成されるCコードのプロローグ/エピローグや、Goランタイムとの連携に必要なメタデータ（ポインタマップなど）を生成する部分に関連しています。

ARMビルドの特殊性

ARMアーキテクチャは、モバイルデバイスや組み込みシステムで広く使用されています。x86/x64アーキテクチャと比較して、レジスタの使用方法、スタックフレームのレイアウト、アライメント要件など、異なるABI（Application Binary Interface）を持つことがあります。Goのようなクロスプラットフォーム言語では、異なるアーキテクチャ向けにコードを生成する際に、これらのABIの違いを正確に処理する必要があります。ポインタマップの生成のような低レベルの最適化やGC関連の機能は、ABIのわずかな違いによってビルドが破損する可能性があります。

CL (Change List) の概念

Goプロジェクトでは、変更は「Change List (CL)」として提出され、レビュープロセスを経てマージされます。各CLには一意の番号が割り当てられ、Gitコミットハッシュとは別にGoのコードレビューシステム（Gerrit）で管理されます。コミットメッセージに CL XXXXXXXX のように記載されるのは、このCL番号を指します。

技術的詳細

このコミットの技術的詳細は、GoランタイムがCgoを介して呼び出されるC関数のスタックフレームをどのようにGC可能にするかという点に集約されます。

`pgen.c`の役割

src/cmd/cc/pgen.c は、Goコンパイラの cc コマンドがCgoによって生成されるCコードの関数プロローグとエピローグ、およびGoランタイムが必要とするメタデータ（特にGC情報）を生成する部分です。C関数がGoから呼び出される際、GoのGCはC関数のスタックフレームもスキャンして、そこに存在するGoのポインタ（例えば、Goのオブジェクトへの参照）を識別する必要があります。このファイルは、そのためのポインタマップを生成するロジックを含んでいます。

ポインタマップの生成ロジック (`pointermap`, `pointermap_type`)

このコミットによって再導入された主要な関数は pointermap と pointermap_type です。

pointermap_type(Type *t, int32 offset, int32 baseidx): この関数は、与えられた型 t とその引数リスト内でのオフセット offset に基づいて、ポインタマップのビットを生成します。
- 基本型（TCHAR, TINT, TFLOAT など）はポインタではないため、0を返します。
- ポインタ型（TIND）や配列型（TARRAY、Cでは参照渡しされるためポインタとして扱われる）の場合、そのオフセットがポインタのサイズ（ewidth[TIND]）の倍数であることを確認し、対応するビットをセットします。idx はポインタのインデックス（オフセット0からの相対位置）を表し、baseidx は現在のビットマップがカバーする範囲の開始インデックスです。
- 構造体（TSTRUCT）の場合、そのメンバーを再帰的に走査し、それぞれのメンバーのポインタマップをOR結合して返します。
- 共用体（TUNION）の場合、すべての共用体メンバーが同じポインタマップを持つことを要求します。これは、共用体のどのメンバーがアクティブであるかに関わらず、GCがポインタを正確に識別できるようにするためです。もし異なるポインタマップを持つメンバーが存在すれば、エラー（yyerror）を発生させます。
pointermap(Sym *gcsym, int32 off): この関数は、C関数の引数リスト全体のポインタマップを計算し、そのデータを gcsym（GCメタデータ用のシンボル）に格納します。
- 可変長引数関数（hasdotdotdot()）の場合、ポインタマップの生成を諦め、nptrs=0 としてGC情報を生成します。これは、可変長引数の型情報がコンパイル時に完全に不明であるため、安全側に倒した挙動です。
- 引数リストのサイズに基づいて、ポインタの総数 nptrs を計算します。
- nptrs を gcsym に格納します。
- 32ビットごとのチャンクでポインタマップを生成します。i はポインタのインデックス、s は引数リスト内のバイトオフセットです。
- Cの呼び出し規約で構造体が隠れた最初の引数（ポインタ）によって返される場合、そのポインタもマップに含めます。
- thisfn->down を走査して、関数の各引数について pointermap_type を呼び出し、ビットマップ m を構築します。
- 構築されたビットマップ m を gcsym に格納します。
- 最終的に、gcsym に格納されたGCデータの総サイズを返します。

C関数の引数におけるポインタの扱い

Cgoでは、GoからC関数を呼び出す際に、GoのポインタがC関数に渡されることがあります。GoのGCは、これらのポインタがC関数のスタックフレーム上に存在する場合でも、それらを追跡できる必要があります。pointermap 関数は、C関数の引数リストを解析し、どの位置にポインタが存在するかを示すビットマップを生成することで、この要件を満たします。これにより、GCはC関数の実行中であっても、Goのヒープオブジェクトへの参照を正確に識別し、誤って解放されることを防ぎます。

`gextern`と`nodconst`

gextern(Sym *s, Node *n, int32 off, int32 width): これは、Goコンパイラのバックエンドで、外部シンボル s にデータを書き込むための関数です。ここでは、gcsym にGCポインタマップのデータ（nptrs やビットマップ）を書き込むために使用されます。
nodconst(int64 v): これは、定数ノードを作成するためのヘルパー関数です。gextern に渡される nptrs やビットマップの値は、この関数によって定数ノードとして表現されます。

`FUNCDATA_GC`のデータ構造

FUNCDATA_GC は、関数に関連付けられたGCメタデータであり、その関数のスタックフレーム内のポインタのレイアウトを記述します。具体的には、以下の情報を含みます。

stkoff: スタックフレームのサイズ（ローカル変数と引数を含む）。
nptrs: スタックフレーム内のポインタの総数。
ptrs[...]: ポインタのビットマップ。各ビットは、スタックフレーム内の特定のオフセットにポインタが存在するかどうかを示します。このビットマップは、32ビット（または64ビット）のチャンクに分割されて格納されます。

このコミットでは、FUNCDATA_GC シンボルの生成と、それにポインタマップデータを格納するロジックが、codgen 関数のより適切な位置（関数の引数処理が完了した後）に移動されています。

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

このコミットのコアとなる変更は、src/cmd/cc/pgen.c において、以前に削除されていた pointermap 関数と pointermap_type 関数が再導入され、FUNCDATA_GC シンボルへのポインタマップデータの書き込みロジックが修正された点です。

具体的には、以下のコードブロックが再導入または変更されています。

static int32 pointermap(Sym *gcsym, int32 offset); の前方宣言の追加。

codgen 関数内で、FUNCDATA_GC シンボルの生成と初期化が、引数処理の開始直後に移動されました。

+static int32 pointermap(Sym *gcsym, int32 offset);
+
 int
 hasdotdotdot(void)
 {
@@ -101,7 +103,21 @@ codgen(Node *n, Node *nn)

 	p = gtext(n1->sym, stkoff);
 	sp = p;
-	
+	
+	/*
+	 * generate funcdata symbol for this function.
+	 * data is filled in at the end of codgen().
+	 */
+	snprint(namebuf, sizeof namebuf, "gc·%d", ngcsym++);
+	gcsym = slookup(namebuf);
+	gcsym->class = CSTATIC;
+
+	memset(&nod, 0, sizeof nod);
+	nod.op = ONAME;
+	nod.sym = gcsym;
+	nod.class = CSTATIC;
+	gins(AFUNCDATA, nodconst(FUNCDATA_GC), &nod);
+
 	/*
 	 * isolate first argument
 	 */
@@ -139,17 +155,6 @@ codgen(Node *n, Node *nn)
 		maxargsafe = xround(maxargsafe, 8);
 	sp->to.offset += maxargsafe;
 	
-	snprint(namebuf, sizeof namebuf, "gc·%d", ngcsym++);
-	gcsym = slookup(namebuf);
-	gcsym->class = CSTATIC;
-
-	memset(&nod, 0, sizeof nod);
-	nod.op = ONAME;
-	nod.sym = gcsym;
-	nod.class = CSTATIC;
-
-	gins(AFUNCDATA, nodconst(FUNCDATA_GC), &nod);
-
 	// TODO(rsc): "stkoff" is not right. It does not account for
 	// the possibility of data stored in .safe variables.
 	// Unfortunately those move up and down just like
@@ -162,8 +167,7 @@ codgen(Node *n, Node *nn)
 	off = 0;
 	gextern(gcsym, nodconst(stkoff), off, 4); // locals
 	off += 4;
-	gextern(gcsym, nodconst(0), off, 4); // nptrs
-	off += 4;
+	off = pointermap(gcsym, off); // nptrs and ptrs[...]
 	gcsym->type = typ(0, T);
 	gcsym->type->width = off;
 }

これにより、FUNCDATA_GC シンボルがより早く生成され、その後の pointermap 関数によってデータが埋められる構造になります。

pointermap 関数と pointermap_type 関数がファイルの末尾に再導入されました。これらの関数は、C関数の引数リストを走査し、ポインタの場所を示すビットマップを生成するロジックを含んでいます。

@@ -633,3 +637,105 @@ bcomplex(Node *n, Node *c)
 	boolgen(n, 1, Z);
 	return 0;
 }
+
+// Makes a bitmap marking the the pointers in t.  t starts at the given byte
+// offset in the argument list.  The returned bitmap should be for pointer
+// indexes (relative to offset 0) between baseidx and baseidx+32.
+static int32
+pointermap_type(Type *t, int32 offset, int32 baseidx)
+{
+
+	Type *t1;
+	int32 idx;
+	int32 m;
+
+	switch(t->etype) {
+	case TCHAR:
+	case TUCHAR:
+	case TSHORT:
+	case TUSHORT:
+	case TINT:
+	case TUINT:
+	case TLONG:
+	case TULONG:
+	case TVLONG:
+	case TUVLONG:
+	case TFLOAT:
+	case TDOUBLE:
+		// non-pointer types
+		return 0;
+	case TIND:
+	case TARRAY: // unlike Go, C passes arrays by reference
+		// pointer types
+		if((offset + t->offset) % ewidth[TIND] != 0)
+			yyerror("unaligned pointer");
+		idx = (offset + t->offset) / ewidth[TIND];
+		if(idx >= baseidx && idx < baseidx + 32)
+			return 1 << (idx - baseidx);
+		return 0;
+	case TSTRUCT:
+		// build map recursively
+		m = 0;
+		for(t1=t->link; t1; t1=t1->down)
+			m |= pointermap_type(t1, offset, baseidx);
+		return m;
+	case TUNION:
+		// We require that all elements of the union have the same pointer map.
+		m = pointermap_type(t->link, offset, baseidx);
+		for(t1=t->link->down; t1; t1=t1->down) {
+			if(pointermap_type(t1, offset, baseidx) != m)
+				yyerror("invalid union in argument list - pointer maps differ");
+		}
+		return m;
+	default:
+		yyerror("can't handle arg type %s\n", tnames[t->etype]);
+		return 0;
+	}
+}
+
+// Compute a bit vector to describe the pointer containing locations
+// in the argument list.  Adds the data to gcsym and returns the offset
+// of end of the bit vector.
+static int32
+pointermap(Sym *gcsym, int32 off)
+{
+	int32 nptrs;
+	int32 i;
+	int32 s;     // offset in argument list (in bytes)
+	int32 m;     // current ptrs[i/32]
+	Type *t;
+
+	if(hasdotdotdot()) {
+		// give up for C vararg functions.
+		// TODO: maybe make a map just for the args we do know?
+		gextern(gcsym, nodconst(0), off, 4); // nptrs=0
+		return off + 4;
+	}
+	nptrs = (argsize() + ewidth[TIND] - 1) / ewidth[TIND];
+	gextern(gcsym, nodconst(nptrs), off, 4);
+	off += 4;
+
+	for(i = 0; i < nptrs; i += 32) {
+		// generate mask for ptrs at offsets i ... i+31
+		m = 0;
+		s = align(0, thisfn->link, Aarg0, nil);
+		if(s > 0 && i == 0) {
+			// C Calling convention returns structs by copying
+			// them to a location pointed to by a hidden first
+			// argument.  This first argument is a pointer.
+			if(s != ewidth[TIND])
+				yyerror("passbyptr arg not the right size");
+			m = 1;
+		}
+		for(t=thisfn->down; t!=T; t=t->down) {
+			if(t->etype == TVOID)
+				continue;
+			s = align(s, t, Aarg1, nil);
+			m |= pointermap_type(t, s, i);
+			s = align(s, t, Aarg2, nil);
+		}
+		gextern(gcsym, nodconst(m), off, 4);
+		off += 4;
+	}
+	return off;
+	// TODO: needs a test for nptrs>32
+}

コアとなるコードの解説

このコミットによって再導入された pointermap および pointermap_type 関数は、GoのガベージコレクタがCgoを介して呼び出されるC関数のスタックフレームを正確にスキャンするために不可欠な役割を果たします。

pointermap_type: この関数は、Cの型システムをGoのGCポインタマップにマッピングする中心的なロジックです。Cの構造体や共用体、ポインタ型など、複雑なデータ型を再帰的に解析し、どのオフセットにポインタが存在するかを示すビットマスクを生成します。特に、共用体に対する厳格なチェック（すべてのメンバーが同じポインタマップを持つこと）は、GCの正確性を保証するために重要です。もし共用体のメンバー間でポインタのレイアウトが異なると、GCが誤ったメモリを解放したり、重要なポインタを見落としたりするリスクがあるため、コンパイル時にエラーとして検出されます。
pointermap: この関数は、C関数の引数リスト全体を対象に、pointermap_type を利用してポインタマップを構築します。C関数の引数は、GoのGCにとっては「外部」のメモリ領域ですが、Goのヒープオブジェクトへの参照を含む可能性があります。この関数は、引数リストの各要素を走査し、ポインタが存在するオフセットをビットマップとして記録します。このビットマップは FUNCDATA_GC シンボルに格納され、GoランタイムがC関数を呼び出す際に、そのスタックフレームをGCスキャンの対象に含めるために使用されます。可変長引数関数に対する制限（ポインタマップを生成しない）は、型情報が不明な場合の安全策です。

これらの関数が再導入されたことで、GoのGCはCgoを介したC関数呼び出しにおいても、より堅牢に動作するようになります。これにより、GoとCの相互運用性におけるメモリ安全性とGCの正確性が向上します。

参考にした情報源リンク

Goのガベージコレクションに関する公式ドキュメントやブログ記事 (一般的なGCの概念とポインタマップについて)
GoのCgoに関する公式ドキュメント (Cgoの仕組みとGo-C間のデータ受け渡しについて)
Goコンパイラのソースコード (特に src/cmd/cc ディレクトリ内のファイル)
ARMアーキテクチャのABIに関する情報 (異なるアーキテクチャでのビルド問題の背景について)