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

このコミットは、Go言語のツールチェインにおけるアセンブラ（cmd/5a, cmd/6a, cmd/8a）とリンカ（cmd/6l）にFUNCDATAディレクティブのサポートを追加するものです。これにより、Goランタイムが関数に関するメタデータ（特にガベージコレクションのためのスタックマップ情報など）を効率的に管理できるようになります。

コミット

commit 8c741c97f710c1e197cd7d2d02d8380dbb759859
Author: Russ Cox <rsc@golang.org>
Date:   Thu Jul 18 15:38:19 2013 -0400

    cmd/6a, cmd/6l: make FUNCDATA work

    R=ken2
    CC=golang-dev
    https://golang.org/cl/11397043

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

https://github.com/golang/go/commit/8c741c97f710c1e197cd7d2d02d8380dbb759859

元コミット内容

cmd/6a, cmd/6l: make FUNCDATA work

このコミットは、Goのアセンブラ（cmd/5a, cmd/6a, cmd/8a）とリンカ（cmd/6l）にFUNCDATAディレクティブの機能を追加し、正しく動作するようにするものです。

変更の背景

Go言語のランタイムは、ガベージコレクション（GC）やスタック管理などの高度な機能を提供するために、実行中のプログラムに関する詳細なメタデータを必要とします。特に、GCが正確に動作するためには、スタック上のどの場所がポインタを含んでいるかを正確に知る必要があります。この情報は「スタックマップ」として知られています。

以前のGoのツールチェインでは、このような関数ごとのメタデータをアセンブラレベルで効率的に指定するメカニズムが不足していた可能性があります。FUNCDATAディレクティブは、アセンブラで書かれた関数に対して、ランタイムが必要とする特定のデータ（例えば、スタックマップのオフセットや、GCに関連する情報への参照）を関連付けるためのものです。

このコミットは、Goランタイムの進化、特に正確なGCの実装と最適化の一環として、アセンブラとリンカがこの重要なメタデータを適切に処理できるようにするために導入されました。これにより、Goのランタイムがより堅牢で効率的なガベージコレクションを実行できるようになります。

前提知識の解説

Goのアセンブラ (cmd/5a, cmd/6a, cmd/8a)

Go言語は、一部のパフォーマンスクリティカルな部分や、特定のハードウェア機能へのアクセスが必要な部分でアセンブリ言語を使用します。Goのツールチェインには、各アーキテクチャ（例: 5aはARM、6aはx86-64、8aはARM64）に対応する独自のアセンブラが含まれています。これらのアセンブラは、Goの特殊な構文とディレクティブを解釈し、オブジェクトファイルを生成します。

リンカ (cmd/6l)

Goのリンカは、アセンブラやコンパイラによって生成されたオブジェクトファイルを結合し、実行可能ファイルを生成します。この過程で、リンカはシンボル解決、アドレスの再配置、そしてランタイムが必要とするメタデータの埋め込みなど、様々な処理を行います。

Yacc/Bison (.yファイル) と Lex/Flex (.lファイル)

• Yacc (Yet Another Compiler Compiler): 構文解析器（パーサ）を生成するためのツールです。文法規則を記述した.yファイル（またはBisonの場合は.yや.yy）を読み込み、C言語のソースコード（通常y.tab.c）を生成します。このソースコードには、入力ストリームが文法規則に合致するかどうかを判断するロジックが含まれます。
• Lex (Lexical Analyzer Generator): 字句解析器（レキサ/スキャナ）を生成するためのツールです。正規表現とそれに対応するアクションを記述した.lファイル（またはFlexの場合は.lや.lex）を読み込み、C言語のソースコード（通常lex.yy.c）を生成します。このソースコードは、入力ストリームをトークン（単語や記号の最小単位）に分割します。

Goのアセンブラは、これらのツール（またはそれに相当する内部実装）を使用して、アセンブリコードを解析しています。

PCDATAとFUNCDATAディレクティブ

• PCDATA (PC Data): プログラムカウンタ（PC）に関連付けられたデータを示すディレクティブです。Goのランタイムでは、主にGCのスタックマップ情報の一部として使用されます。特定のPCオフセットにおいて、スタック上のどのレジスタやメモリ位置がポインタを含んでいるかを示すために使われます。
• FUNCDATA (Function Data): 関数に関連付けられたデータを示すディレクティブです。PCDATAと同様に、GCやその他のランタイム機能のために、関数全体または関数内の特定のポイントに関するメタデータを指定するために使用されます。例えば、関数が使用するスタックフレームのサイズや、GCがスキャンする必要があるポインタの場所などを示すことができます。

これらのディレクティブは、Goの正確なガベージコレクションを可能にする上で不可欠な情報を提供します。GCは、実行中のプログラムのスタックとヒープをスキャンして到達可能なオブジェクトを特定しますが、その際にどの値がポインタであるかを正確に知る必要があります。PCDATAやFUNCDATAは、この「ポインタであるかどうかの情報」をコンパイル時に埋め込むためのメカニズムです。

技術的詳細

このコミットの主要な変更点は、Goのアセンブラの構文解析器と字句解析器にFUNCDATAディレクティブのサポートを追加することです。

1. 字句解析器の変更 (lex.c):

   • FUNCDATAという新しいキーワードが認識され、対応するトークンタイプ（LTYPEF）が割り当てられます。これにより、アセンブラがFUNCDATAという文字列を特別な意味を持つディレクティブとして認識できるようになります。

2. 構文解析器の変更 (a.y):

   • FUNCDATAディレクティブの文法規則が追加されます。具体的には、FUNCDATAの後に2つの引数（インデックスと値）が続く形式が定義されます。
   • FUNCDATAの引数に対する型チェックが導入されます。
     • 最初の引数（インデックス）は整数定数である必要があります。
     • 2番目の引数（値）はシンボル参照（D_EXTERNまたはD_STATIC）である必要があります。これは、FUNCDATAが通常、特定のデータ構造やGC関連のテーブルへの参照を指すためです。
   • outcode関数が呼び出され、解析されたFUNCDATAディレクティブがオブジェクトファイルに適切にエンコードされるようになります。outcodeは、アセンブラの命令やディレクティブを中間表現に変換し、最終的なオブジェクトファイルに書き込むための内部関数です。

3. 生成されたパーサファイル (y.tab.c, y.tab.h):

   • a.yとlex.cの変更に伴い、YaccとLexによって生成されるy.tab.cとy.tab.hファイルが更新されます。これには、新しいトークン定義、文法規則に対応する状態遷移テーブル、および関連する定数の変更が含まれます。特に、LTYPEFトークンの数値が定義され、パーサの状態数やルール数も更新されています。

これらの変更により、GoのアセンブラはFUNCDATAディレクティブを含むアセンブリコードを正しく解析し、その情報をオブジェクトファイルに埋め込むことができるようになります。リンカは、これらのオブジェクトファイルからFUNCDATA情報を抽出し、最終的な実行可能ファイルに統合することで、GoランタイムがGCなどの目的でこのメタデータを利用できるようになります。

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

このコミットのコアとなる変更は、主にGoのアセンブラのYacc文法ファイル（a.y）とLexer定義ファイル（lex.c）に集中しています。

src/cmd/5a/a.y (ARMアセンブラの文法定義)

--- a/src/cmd/5a/a.y
+++ b/src/cmd/5a/a.y
@@ -50,11 +50,11 @@
 %left	'*' '/' '%'
 %token	<lval>	LTYPE1 LTYPE2 LTYPE3 LTYPE4 LTYPE5
 %token	<lval>	LTYPE6 LTYPE7 LTYPE8 LTYPE9 LTYPEA
-%token	<lval>	LTYPEB LTYPEC LTYPED LTYPEE LTYPEF
+%token	<lval>	LTYPEB LTYPEC LTYPED LTYPEE
 %token	<lval>	LTYPEG LTYPEH LTYPEI LTYPEJ LTYPEK
 %token	<lval>	LTYPEL LTYPEM LTYPEN LTYPEBX LTYPEPLD
 %token	<lval>	LCONST LSP LSB LFP LPC
-%token	<lval>	LTYPEX LTYPEPC LR LREG LF LFREG LC LCREG LPSR LFCR
+%token	<lval>	LTYPEX LTYPEPC LTYPEF LR LREG LF LFREG LC LCREG LPSR LFCR
 %token	<lval>	LCOND LS LAT
 %token	<dval>	LFCONST
 %token	<sval>	LSCONST
@@ -322,10 +322,23 @@ inst:
 /*
  * PCDATA
  */
-|\tLTYPEPC imm ',' imm
+|\tLTYPEPC gen ',' gen
 	{
+\t\tif($2.type != D_CONST || $4.type != D_CONST)
+\t\t\tyyerror("arguments to PCDATA must be integer constants");
 \t\toutcode($1, Always, &$2, NREG, &$4);
 \t}
+/*
+ * FUNCDATA
+ */
+|\tLTYPEF gen ',' gen
+\t{
+\t\tif($2.type != D_CONST)
+\t\t\tyyerror("index for FUNCDATA must be integer constant");
+\t\tif($4.type != D_EXTERN && $4.type != D_STATIC)
+\t\t\tyyerror("value for FUNCDATA must be symbol reference");
+ \t\toutcode($1, Always, &$2, NREG, &$4);
+\t}
 /*
  * END
  */

src/cmd/5a/lex.c (ARMアセンブラの字句解析定義)

--- a/src/cmd/5a/lex.c
+++ b/src/cmd/5a/lex.c
@@ -415,6 +415,7 @@ struct
 
 	"USEFIELD",	LTYPEN, AUSEFIELD,
 	"PCDATA",	LTYPEPC,	APCDATA,
+	"FUNCDATA",	LTYPEF,	AFUNCDATA,
 
 	0
 };

同様の変更がsrc/cmd/6a/a.y, src/cmd/6a/lex.c, src/cmd/8a/a.y, src/cmd/8a/lex.cにも適用されています。

コアとなるコードの解説

src/cmd/5a/a.y の変更点

1. トークン定義の追加:

   • %token <lval> LTYPEF が追加され、FUNCDATAディレクティブに対応するトークンLTYPEFが定義されています。これにより、パーサはFUNCDATAというキーワードを認識できるようになります。
   • 既存のLTYPEFトークンが削除され、新しいLTYPEFがLTYPEPCの隣に移動しています。これは、トークンの数値IDの再割り当てによるものです。

2. FUNCDATA文法規則の追加:

   • inst: ルール内に新しいプロダクション | LTYPEF gen ',' gen が追加されています。これは、FUNCDATAディレクティブがgen型の2つの引数をカンマで区切って取ることを示しています。
   • このプロダクションに対応するアクションブロックが追加されています。
     • if($2.type != D_CONST): 最初の引数（インデックス）が定数型（D_CONST）であることを検証します。定数でない場合はエラーを報告します。
     • if($4.type != D_EXTERN && $4.type != D_STATIC): 2番目の引数（値）が外部シンボル（D_EXTERN）または静的シンボル（D_STATIC）への参照であることを検証します。これは、FUNCDATAが通常、ランタイムが参照するシンボルを指すためです。シンボル参照でない場合はエラーを報告します。
     • outcode($1, Always, &$2, NREG, &$4);: FUNCDATAディレクティブとその引数をoutcode関数に渡します。この関数は、アセンブラの命令やディレクティブをオブジェクトファイルに書き込む役割を担っています。$1はLTYPEFトークン、&$2は最初の引数（インデックス）、&$4は2番目の引数（値）を指します。

src/cmd/5a/lex.c の変更点

1. キーワードの追加:
   • struct 配列に "FUNCDATA", LTYPEF, AFUNCDATA, のエントリが追加されています。
   • これは、字句解析器が入力ストリームでFUNCDATAという文字列を見つけたときに、それをLTYPEFトークンとして認識し、AFUNCDATAというアクションを実行するように指示します。AFUNCDATAは、FUNCDATAディレクティブの内部表現を構築するためのアセンブラ内部の定数または関数であると推測されます。

これらの変更により、GoのアセンブラはFUNCDATAディレクティブを正しく解析し、その情報をオブジェクトファイルに埋め込むことができるようになります。この情報は、Goランタイムがガベージコレクションやその他のランタイム機能のために必要とするメタデータの一部となります。

関連リンク

• Go言語の公式リポジトリ: https://github.com/golang/go
• Goのコードレビューシステム (Gerrit): https://go-review.googlesource.com/
• このコミットのGerritチェンジリスト: https://golang.org/cl/11397043

参考にした情報源リンク

• Go Assembly Language (Goアセンブリ言語のドキュメント): https://go.dev/doc/asm
• Goのガベージコレクションに関する資料 (例: "Go's garbage collector: in theory and in practice"): https://go.dev/blog/go15gc (これはGo 1.5のGCに関するものですが、GCの基本的な概念とスタックマップの重要性を理解するのに役立ちます)
• Yacc/Bisonのドキュメント: https://www.gnu.org/software/bison/manual/
• Lex/Flexのドキュメント: https://github.com/westes/flex/wiki
• Goのツールチェインの内部構造に関する議論やドキュメント (Goのソースコードやデザインドキュメント): https://go.googlesource.com/go/+/refs/heads/master/src/cmd/ (特にcmd/internal/objやcmd/linkのコードが関連します)
• GoのPCDATAとFUNCDATAに関する議論 (GoのメーリングリストやIssueトラッカー): golang-devメーリングリストのアーカイブやGoのIssueトラッカーでPCDATAやFUNCDATAを検索すると、より詳細な背景情報が見つかる可能性があります。

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

このコミットは、Go言語のツールチェインにおけるアセンブラ（cmd/5a, cmd/6a, cmd/8a）とリンカ（cmd/6l）にFUNCDATAディレクティブのサポートを追加するものです。これにより、Goランタイムが関数に関するメタデータ（特にガベージコレクションのためのスタックマップ情報など）を効率的に管理できるようになります。

コミット

commit 8c741c97f710c1e197cd7d2d02d8380dbb759859
Author: Russ Cox <rsc@golang.org>
Date:   Thu Jul 18 15:38:19 2013 -0400

    cmd/6a, cmd/6l: make FUNCDATA work

    R=ken2
    CC=golang-dev
    https://golang.org/cl/11397043

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

https://github.com/golang/go/commit/8c741c97f710c1e197cd7d2d02d8380dbb759859

元コミット内容

cmd/6a, cmd/6l: make FUNCDATA work

このコミットは、Goのアセンブラ（cmd/5a, cmd/6a, cmd/8a）とリンカ（cmd/6l）にFUNCDATAディレクティブの機能を追加し、正しく動作するようにするものです。

変更の背景

Go言語のランタイムは、ガベージコレクション（GC）やスタック管理などの高度な機能を提供するために、実行中のプログラムに関する詳細なメタデータを必要とします。特に、GCが正確に動作するためには、スタック上のどの場所がポインタを含んでいるかを正確に知る必要があります。この情報は「スタックマップ」として知られています。

以前のGoのツールチェインでは、このような関数ごとのメタデータをアセンブラレベルで効率的に指定するメカニズムが不足していた可能性があります。FUNCDATAディレクティブは、アセンブラで書かれた関数に対して、ランタイムが必要とする特定のデータ（例えば、スタックマップのオフセットや、GCに関連する情報への参照）を関連付けるためのものです。

このコミットは、Goランタイムの進化、特に正確なGCの実装と最適化の一環として、アセンブラとリンカがこの重要なメタデータを適切に処理できるようにするために導入されました。これにより、Goのランタイムがより堅牢で効率的なガベージコレクションを実行できるようになります。

前提知識の解説

Goのアセンブラ (cmd/5a, cmd/6a, cmd/8a)

Go言語は、一部のパフォーマンスクリティカルな部分や、特定のハードウェア機能へのアクセスが必要な部分でアセンブリ言語を使用します。Goのツールチェインには、各アーキテクチャ（例: 5aはARM、6aはx86-64、8aはARM64）に対応する独自のアセンブラが含まれています。これらのアセンブラは、Goの特殊な構文とディレクティブを解釈し、オブジェクトファイルを生成します。

リンカ (cmd/6l)

Goのリンカは、アセンブラやコンパイラによって生成されたオブジェクトファイルを結合し、実行可能ファイルを生成します。この過程で、リンカはシンボル解決、アドレスの再配置、そしてランタイムが必要とするメタデータの埋め込みなど、様々な処理を行います。

Yacc/Bison (.yファイル) と Lex/Flex (.lファイル)

• Yacc (Yet Another Compiler Compiler): 構文解析器（パーサ）を生成するためのツールです。文法規則を記述した.yファイル（またはBisonの場合は.yや.yy）を読み込み、C言語のソースコード（通常y.tab.c）を生成します。このソースコードには、入力ストリームが文法規則に合致するかどうかを判断するロジックが含まれます。
• Lex (Lexical Analyzer Generator): 字句解析器（レキサ/スキャナ）を生成するためのツールです。正規表現とそれに対応するアクションを記述した.lファイル（またはFlexの場合は.lや.lex）を読み込み、C言語のソースコード（通常lex.yy.c）を生成します。このソースコードは、入力ストリームをトークン（単語や記号の最小単位）に分割します。

Goのアセンブラは、これらのツール（またはそれに相当する内部実装）を使用して、アセンブリコードを解析しています。

PCDATAとFUNCDATAディレクティブ

• PCDATA (PC Data): プログラムカウンタ（PC）に関連付けられたデータを示すディレクティブです。Goのランタイムでは、主にGCのスタックマップ情報の一部として使用されます。特定のPCオフセットにおいて、スタック上のどのレジスタやメモリ位置がポインタを含んでいるかを示すために使われます。
• FUNCDATA (Function Data): 関数に関連付けられたデータを示すディレクティブです。PCDATAと同様に、GCやその他のランタイム機能のために、関数全体または関数内の特定のポイントに関するメタデータを指定するために使用されます。例えば、関数が使用するスタックフレームのサイズや、GCがスキャンする必要があるポインタの場所などを示すことができます。

これらのディレクティブは、Goの正確なガベージコレクションを可能にする上で不可欠な情報を提供します。GCは、実行中のプログラムのスタックとヒープをスキャンして到達可能なオブジェクトを特定しますが、その際にどの値がポインタであるかを正確に知る必要があります。PCDATAやFUNCDATAは、この「ポインタであるかどうかの情報」をコンパイル時に埋め込むためのメカニズムです。

技術的詳細

このコミットの主要な変更点は、Goのアセンブラの構文解析器と字句解析器にFUNCDATAディレクティブのサポートを追加することです。

1. 字句解析器の変更 (lex.c):

   • FUNCDATAという新しいキーワードが認識され、対応するトークンタイプ（LTYPEF）が割り当てられます。これにより、アセンブラがFUNCDATAという文字列を特別な意味を持つディレクティブとして認識できるようになります。

2. 構文解析器の変更 (a.y):

   • FUNCDATAディレクティブの文法規則が追加されます。具体的には、FUNCDATAの後に2つの引数（インデックスと値）が続く形式が定義されます。
   • FUNCDATAの引数に対する型チェックが導入されます。
     • 最初の引数（インデックス）は整数定数である必要があります。
     • 2番目の引数（値）はシンボル参照（D_EXTERNまたはD_STATIC）である必要があります。これは、FUNCDATAが通常、特定のデータ構造やGC関連のテーブルへの参照を指すためです。
   • outcode関数が呼び出され、解析されたFUNCDATAディレクティブがオブジェクトファイルに適切にエンコードされるようになります。outcodeは、アセンブラの命令やディレクティブを中間表現に変換し、最終的なオブジェクトファイルに書き込むための内部関数です。

3. 生成されたパーサファイル (y.tab.c, y.tab.h):

   • a.yとlex.cの変更に伴い、YaccとLexによって生成されるy.tab.cとy.tab.hファイルが更新されます。これには、新しいトークン定義、文法規則に対応する状態遷移テーブル、および関連する定数の変更が含まれます。特に、LTYPEFトークンの数値が定義され、パーサの状態数やルール数も更新されています。

これらの変更により、GoのアセンブラはFUNCDATAディレクティブを含むアセンブリコードを正しく解析し、その情報をオブジェクトファイルに埋め込むことができるようになります。リンカは、これらのオブジェクトファイルからFUNCDATA情報を抽出し、最終的な実行可能ファイルに統合することで、GoランタイムがGCなどの目的でこのメタデータを利用できるようになります。

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

このコミットのコアとなる変更は、主にGoのアセンブラのYacc文法ファイル（a.y）とLexer定義ファイル（lex.c）に集中しています。

src/cmd/5a/a.y (ARMアセンブラの文法定義)

--- a/src/cmd/5a/a.y
+++ b/src/cmd/5a/a.y
@@ -50,11 +50,11 @@
 %left	'*' '/' '%'
 %token	<lval>	LTYPE1 LTYPE2 LTYPE3 LTYPE4 LTYPE5
 %token	<lval>	LTYPE6 LTYPE7 LTYPE8 LTYPE9 LTYPEA
-%token	<lval>	LTYPEB LTYPEC LTYPED LTYPEE LTYPEF
+%token	<lval>	LTYPEB LTYPEC LTYPED LTYPEE
 %token	<lval>	LTYPEG LTYPEH LTYPEI LTYPEJ LTYPEK
 %token	<lval>	LTYPEL LTYPEM LTYPEN LTYPEBX LTYPEPLD
 %token	<lval>	LCONST LSP LSB LFP LPC
-%token	<lval>	LTYPEX LTYPEPC LR LREG LF LFREG LC LCREG LPSR LFCR
+%token	<lval>	LTYPEX LTYPEPC LTYPEF LR LREG LF LFREG LC LCREG LPSR LFCR
 %token	<lval>	LCOND LS LAT
 %token	<dval>	LFCONST
 %token	<sval>	LSCONST
@@ -322,10 +322,23 @@ inst:
 /*
  * PCDATA
  */
-|\tLTYPEPC imm ',' imm
+|\tLTYPEPC gen ',' gen
 	{
+\t\tif($2.type != D_CONST || $4.type != D_CONST)
+\t\t\tyyerror("arguments to PCDATA must be integer constants");
 \t\toutcode($1, Always, &$2, NREG, &$4);
 \t}
+/*
+ * FUNCDATA
+ */
+|\tLTYPEF gen ',' gen
+\t{
+\t\tif($2.type != D_CONST)
+\t\t\tyyerror("index for FUNCDATA must be integer constant");
+\t\tif($4.type != D_EXTERN && $4.type != D_STATIC)
+\t\t\tyyerror("value for FUNCDATA must be symbol reference");
+ \t\toutcode($1, Always, &$2, NREG, &$4);
+\t}
 /*
  * END
  */

src/cmd/5a/lex.c (ARMアセンブラの字句解析定義)

--- a/src/cmd/5a/lex.c
+++ b/src/cmd/5a/lex.c
@@ -415,6 +415,7 @@ struct
 
 	"USEFIELD",	LTYPEN, AUSEFIELD,
 	"PCDATA",	LTYPEPC,	APCDATA,
+	"FUNCDATA",	LTYPEF,	AFUNCDATA,
 
 	0
 };

同様の変更がsrc/cmd/6a/a.y, src/cmd/6a/lex.c, src/cmd/8a/a.y, src/cmd/8a/lex.cにも適用されています。

コアとなるコードの解説

src/cmd/5a/a.y の変更点

1. トークン定義の追加:

   • %token <lval> LTYPEF が追加され、FUNCDATAディレクティブに対応するトークンLTYPEFが定義されています。これにより、パーサはFUNCDATAというキーワードを認識できるようになります。
   • 既存のLTYPEFトークンが削除され、新しいLTYPEFがLTYPEPCの隣に移動しています。これは、トークンの数値IDの再割り当てによるものです。

2. FUNCDATA文法規則の追加:

   • inst: ルール内に新しいプロダクション | LTYPEF gen ',' gen が追加されています。これは、FUNCDATAディレクティブがgen型の2つの引数をカンマで区切って取ることを示しています。
   • このプロダクションに対応するアクションブロックが追加されています。
     • if($2.type != D_CONST): 最初の引数（インデックス）が定数型（D_CONST）であることを検証します。定数でない場合はエラーを報告します。
     • if($4.type != D_EXTERN && $4.type != D_STATIC): 2番目の引数（値）が外部シンボル（D_EXTERN）または静的シンボル（D_STATIC）への参照であることを検証します。これは、FUNCDATAが通常、ランタイムが参照するシンボルを指すためです。シンボル参照でない場合はエラーを報告します。
     • outcode($1, Always, &$2, NREG, &$4);: FUNCDATAディレクティブとその引数をoutcode関数に渡します。この関数は、アセンブラの命令やディレクティブをオブジェクトファイルに書き込む役割を担っています。$1はLTYPEFトークン、&$2は最初の引数（インデックス）、&$4は2番目の引数（値）を指します。

src/cmd/5a/lex.c の変更点

1. キーワードの追加:
   • struct 配列に "FUNCDATA", LTYPEF, AFUNCDATA, のエントリが追加されています。
   • これは、字句解析器が入力ストリームでFUNCDATAという文字列を見つけたときに、それをLTYPEFトークンとして認識し、AFUNCDATAというアクションを実行するように指示します。AFUNCDATAは、FUNCDATAディレクティブの内部表現を構築するためのアセンブラ内部の定数または関数であると推測されます。

これらの変更により、GoのアセンブラはFUNCDATAディレクティブを正しく解析し、その情報をオブジェクトファイルに埋め込むことができるようになります。この情報は、Goランタイムがガベージコレクションやその他のランタイム機能のために必要とするメタデータの一部となります。

関連リンク

• Go言語の公式リポジトリ: https://github.com/golang/go
• Goのコードレビューシステム (Gerrit): https://go-review.googlesource.com/
• このコミットのGerritチェンジリスト: https://golang.org/cl/11397043

参考にした情報源リンク

• Go Assembly Language (Goアセンブリ言語のドキュメント): https://go.dev/doc/asm
• Goのガベージコレクションに関する資料 (例: "Go's garbage collector: in theory and in practice"): https://go.dev/blog/go15gc (これはGo 1.5のGCに関するものですが、GCの基本的な概念とスタックマップの重要性を理解するのに役立ちます)
• Yacc/Bisonのドキュメント: https://www.gnu.org/software/bison/manual/
• Lex/Flexのドキュメント: https://github.com/westes/flex/wiki
• Goのツールチェインの内部構造に関する議論やドキュメント (Goのソースコードやデザインドキュメント): https://go.googlesource.com/go/+/refs/heads/master/src/cmd/ (特にcmd/internal/objやcmd/linkのコードが関連します)
• GoのPCDATAとFUNCDATAに関する議論 (GoのメーリングリストやIssueトラッカー): golang-devメーリングリストのアーカイブやGoのIssueトラッカーでPCDATAやFUNCDATAを検索すると、より詳細な背景情報が見つかる可能性があります。
• stackoverflow.com (https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGzsliF1ycJQJ4DbUQdbqBV0L1QGyRTmmr9-94HWJTeXJnm581A0psf2E07vjOrxMJKXIzKwsaXtl5KG_13imaJy_NTo9SSbmtoixqxiMFo6wZaIhbMHFNDlkIPsHHpWQob330wvuaQ1tUUMB4PyyKa63Idvzdhs6z68Rf9Z49efMO9vx7b180fZQG-pM27rZNXvq5n)