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

このコミットは、Go言語のリンカである cmd/5l における noop.c ファイルの変更に関するものです。具体的には、ラッパー関数内での RET.EQ 命令の取り扱いに関するバグ修正を行っています。

コミット

commit 3acddba2ec9ec2b6e8e9f6b9b6843d3780587bfe
Author: Russ Cox <rsc@golang.org>
Date:   Fri Sep 13 03:50:50 2013 +0000

    cmd/5l: fix handling of RET.EQ in wrapper function
    
    Keith is too clever for me.
    
    R=ken2
    CC=golang-dev, khr
    https://golang.org/cl/13272050

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

https://github.com/golang/go/commit/3acddba2ec9ec2b6e8e9f6b9b6843d3780587bfe

元コミット内容

cmd/5l: fix handling of RET.EQ in wrapper function

このコミットは、ラッパー関数における RET.EQ 命令の処理に関する問題を修正します。コミットメッセージには「Keith is too clever for me.」とあり、これはおそらく、この問題を発見したか、あるいはその原因となったコードを書いた人物（Keith）の巧妙さを称賛するものです。

変更の背景

この変更は、Go言語の reflect パッケージ、特に reflect.Call の実装に関連するバグを修正するために行われました。reflect.Call は、Goのプログラムが実行時に型情報に基づいて関数を呼び出すことを可能にする強力な機能です。この機能は、例えば、メソッドの動的なディスパッチや、外部からの入力に基づいて関数を実行するような場面で利用されます。

問題は、reflect.Call が内部的に使用する「ラッパー関数」が、特定の条件付きリターン命令（RET.EQ）を正しく処理していなかったことにありました。RET.EQ は、直前の比較結果が等しい場合にのみ関数からリターンするという、アセンブリレベルの条件分岐命令です。Goのコンパイラとリンカは、Goのソースコードを機械語に変換する過程で、このようなアセンブリ命令を生成します。

cmd/5l は、Goのツールチェインにおけるリンカの一部であり、特にARMアーキテクチャ（5lはARMを指す）向けのバイナリ生成を担当しています。noop.c は、リンカの最適化パスの一部として、命令の並べ替えや変換を行うファイルであると推測されます。

ラッパー関数が RET.EQ を正しく扱えないと、reflect.Call を使用した際に予期せぬ動作やクラッシュが発生する可能性がありました。これは、特にリフレクションを多用するアプリケーションや、Goの内部的な動作に依存するコードにおいて、深刻な問題となり得ました。

前提知識の解説

Go言語のツールチェイン

Go言語のプログラムは、ソースコードから実行可能なバイナリに変換されるまでに、いくつかの段階を経ます。

1. コンパイラ (go tool compile): Goのソースコードをアセンブリコード（Goアセンブリ）に変換します。
2. アセンブラ (go tool asm): Goアセンブリコードをオブジェクトファイル（機械語）に変換します。
3. リンカ (go tool link): 複数のオブジェクトファイルやライブラリを結合し、最終的な実行可能バイナリを生成します。cmd/5l は、このリンカの一部で、ARMアーキテクチャに特化したものです。

アセンブリ命令と条件コード

CPUは、命令を実行する際に、その結果に基づいて「条件コード」と呼ばれるフラグを設定します。例えば、比較命令（CMP）を実行した後、結果が等しければ「ゼロフラグ」がセットされます。RET.EQ のような条件付き命令は、これらの条件コードの値を参照して、命令を実行するかどうかを決定します。

• RET (Return): 関数から呼び出し元に戻る命令。
• RET.EQ (Return if Equal): 直前の比較結果が等しい場合にのみ関数から戻る命令。

reflect パッケージと reflect.Call

reflect パッケージは、Goのプログラムが実行時に自身の構造を検査し、変更することを可能にする機能（リフレクション）を提供します。

• reflect.Value: Goの任意の値を抽象的に表現する型。
• reflect.Method / reflect.Func: メソッドや関数を表現する型。
• reflect.Call(in []Value) []Value: reflect.Value で表される関数やメソッドを呼び出すためのメソッド。引数を []reflect.Value で受け取り、戻り値を []reflect.Value で返します。

reflect.Call は、Goの型システムをバイパスして動的に関数を呼び出すため、内部的には複雑なアセンブリコードの生成や、スタックフレームの操作を伴います。この過程で、Goのランタイムは「ラッパー関数」を生成し、実際の関数呼び出しを仲介します。このラッパー関数は、引数の準備、関数の呼び出し、戻り値の処理などを行います。

WRAPPER フラグ

Goのリンカ内部では、特定の関数やコードブロックに特別な意味を持たせるためにフラグが使用されます。WRAPPER フラグは、そのコードがリフレクションなどの目的で生成された「ラッパー関数」であることを示すために使用されていたと推測されます。

技術的詳細

このバグは、cmd/5l の noop.c 内で、ラッパー関数を処理するロジックに起因していました。noop.c は、リンカがオブジェクトファイルを処理する際に、命令の最適化や変換を行う場所です。

問題の核心は、ラッパー関数が生成される際に、元の命令の条件コード（scond）が失われてしまうことにありました。特に RET.EQ のような条件付きリターン命令は、その条件コードが非常に重要です。ラッパー関数が生成される過程で、この scond がリセットされてしまうと、RET.EQ は無条件の RET として扱われてしまい、期待される条件分岐が行われなくなります。

Goの reflect.Call は、内部的に特定の状況で RET.EQ を使用することがあります。例えば、関数の戻り値が特定の条件を満たす場合にのみリターンするといった最適化や、エラーハンドリングのメカニズムとして利用される可能性があります。ラッパー関数がこの RET.EQ の条件を無視してしまうと、reflect.Call が正しく動作せず、論理的な誤りやランタイムエラーを引き起こしていました。

修正は、ラッパー関数を処理する際に、元の命令の scond を一時的に保存し、ラッパー関数の生成後にそれを復元するというアプローチを取りました。これにより、RET.EQ のような条件付き命令が、ラッパー関数によってその意味を失うことなく、正しく機能するようになりました。

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

変更は src/cmd/5l/noop.c ファイルの noops 関数内で行われました。

--- a/src/cmd/5l/noop.c
+++ b/src/cmd/5l/noop.c
@@ -321,6 +321,13 @@ noops(void)
 				}
 
 				if(cursym->text->reg & WRAPPER) {
+					int cond;
+					
+					// Preserve original RET's cond, to allow RET.EQ
+					// in the implementation of reflect.call.
+					cond = p->scond;
+					p->scond = C_SCOND_NONE;
+
 					// g->panicwrap -= autosize;
 					// MOVW panicwrap_offset(g), R3
 					// SUB $autosize, R3
@@ -347,6 +354,8 @@ noops(void)
 					p->to.reg = REGG;
 					p->to.offset = 2*PtrSize;
 					p = appendp(p);
+
+					p->scond = cond;
 				}
 
 			p->as = AMOVW;

コアとなるコードの解説

変更は if(cursym->text->reg & WRAPPER) ブロック内で行われています。このブロックは、現在のシンボルがラッパー関数である場合に実行されるロジックを含んでいます。

1. int cond;: cond という整数型の変数が宣言されます。これは、元の命令の条件コードを一時的に保存するために使用されます。
2. // Preserve original RET's cond, to allow RET.EQ: コメントで、元の RET 命令の条件コードを保存する目的が説明されています。これは reflect.call の実装で RET.EQ を許可するためです。
3. cond = p->scond;: 現在処理している命令 p の条件コード scond を cond 変数に保存します。p はリンカが処理するアセンブリ命令を表す構造体であり、scond はその命令に付随する条件コード（例: C_SCOND_EQ for EQ）を格納するフィールドです。
4. p->scond = C_SCOND_NONE;: 命令 p の条件コードを C_SCOND_NONE に設定します。これは、ラッパー関数を生成する過程で、一時的に条件コードを無効にするためです。これにより、ラッパー関数内の命令が意図せず条件付きで実行されることを防ぎます。
5. p->scond = cond;: ラッパー関数の生成ロジックが完了した後、保存しておいた元の条件コード cond を、最後に生成された命令 p に復元します。これにより、RET.EQ のような命令が、ラッパー関数によってその条件を失うことなく、正しく機能するようになります。

この修正により、ラッパー関数が生成される際に、元の命令の重要な属性である条件コードが保持されるようになり、reflect.Call が RET.EQ を含む関数を正しく呼び出せるようになりました。

関連リンク

• Go言語の reflect パッケージのドキュメント: https://pkg.go.dev/reflect
• Go言語のツールチェインに関する一般的な情報: https://go.dev/doc/

参考にした情報源リンク

• Go言語の公式ドキュメント
• Go言語のソースコード（特に src/cmd/5l/ ディレクトリ）
• Go言語のコミット履歴とコードレビューシステム (Gerrit)
• アセンブリ言語とCPUアーキテクチャに関する一般的な知識
• リフレクションに関するプログラミングの概念
• Go言語のリンカに関する一般的な情報 (Goのリンカは非常に特殊なため、一般的なリンカの知識だけでなく、Go特有のリンカの動作を理解する必要がある)

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

このコミットは、Go言語のリンカである cmd/5l における noop.c ファイルの変更に関するものです。具体的には、ラッパー関数内での RET.EQ 命令の取り扱いに関するバグ修正を行っています。

コミット

commit 3acddba2ec9ec2b6e8e9f6b9b6843d3780587bfe
Author: Russ Cox <rsc@golang.org>
Date:   Fri Sep 13 03:50:50 2013 +0000

    cmd/5l: fix handling of RET.EQ in wrapper function
    
    Keith is too clever for me.
    
    R=ken2
    CC=golang-dev, khr
    https://golang.org/cl/13272050

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

https://github.com/golang/go/commit/3acddba2ec9ec2b6e8e9f6b9b6843d3780587bfe

元コミット内容

cmd/5l: fix handling of RET.EQ in wrapper function

このコミットは、ラッパー関数における RET.EQ 命令の処理に関する問題を修正します。コミットメッセージには「Keith is too clever for me.」とあり、これはおそらく、この問題を発見したか、あるいはその原因となったコードを書いた人物（Keith）の巧妙さを称賛するものです。

変更の背景

この変更は、Go言語の reflect パッケージ、特に reflect.Call の実装に関連するバグを修正するために行われました。reflect.Call は、Goのプログラムが実行時に型情報に基づいて関数を呼び出すことを可能にする強力な機能です。この機能は、例えば、メソッドの動的なディスパッチや、外部からの入力に基づいて関数を実行するような場面で利用されます。

問題は、reflect.Call が内部的に使用する「ラッパー関数」が、特定の条件付きリターン命令（RET.EQ）を正しく処理していなかったことにありました。RET.EQ は、直前の比較結果が等しい場合にのみ関数からリターンするという、アセンブリレベルの条件分岐命令です。Goのコンパイラとリンカは、Goのソースコードを機械語に変換する過程で、このようなアセンブリ命令を生成します。

cmd/5l は、Goのツールチェインにおけるリンカの一部であり、特にARMアーキテクチャ（5lはARMを指す）向けのバイナリ生成を担当しています。noop.c は、リンカの最適化パスの一部として、命令の並べ替えや変換を行うファイルであると推測されます。

ラッパー関数が RET.EQ を正しく扱えないと、reflect.Call を使用した際に予期せぬ動作やクラッシュが発生する可能性がありました。これは、特にリフレクションを多用するアプリケーションや、Goの内部的な動作に依存するコードにおいて、深刻な問題となり得ました。

前提知識の解説

Go言語のツールチェイン

Go言語のプログラムは、ソースコードから実行可能なバイナリに変換されるまでに、いくつかの段階を経ます。

1. コンパイラ (go tool compile): Goのソースコードをアセンブリコード（Goアセンブリ）に変換します。
2. アセンブラ (go tool asm): Goアセンブリコードをオブジェクトファイル（機械語）に変換します。
3. リンカ (go tool link): 複数のオブジェクトファイルやライブラリを結合し、最終的な実行可能バイナリを生成します。cmd/5l は、このリンカの一部で、ARMアーキテクチャに特化したものです。

アセンブリ命令と条件コード

CPUは、命令を実行する際に、その結果に基づいて「条件コード」と呼ばれるフラグを設定します。例えば、比較命令（CMP）を実行した後、結果が等しければ「ゼロフラグ」がセットされます。RET.EQ のような条件付き命令は、これらの条件コードの値を参照して、命令を実行するかどうかを決定します。

• RET (Return): 関数から呼び出し元に戻る命令。
• RET.EQ (Return if Equal): 直前の比較結果が等しい場合にのみ関数から戻る命令。

reflect パッケージと reflect.Call

reflect パッケージは、Goのプログラムが実行時に自身の構造を検査し、変更することを可能にする機能（リフレクション）を提供します。

• reflect.Value: Goの任意の値を抽象的に表現する型。
• reflect.Method / reflect.Func: メソッドや関数を表現する型。
• reflect.Call(in []Value) []Value: reflect.Value で表される関数やメソッドを呼び出すためのメソッド。引数を []reflect.Value で受け取り、戻り値を []reflect.Value で返します。

reflect.Call は、Goの型システムをバイパスして動的に関数を呼び出すため、内部的には複雑なアセンブリコードの生成や、スタックフレームの操作を伴います。この過程で、Goのランタイムは「ラッパー関数」を生成し、実際の関数呼び出しを仲介します。このラッパー関数は、引数の準備、関数の呼び出し、戻り値の処理などを行います。

WRAPPER フラグ

Goのリンカ内部では、特定の関数やコードブロックに特別な意味を持たせるためにフラグが使用されます。WRAPPER フラグは、そのコードがリフレクションなどの目的で生成された「ラッパー関数」であることを示すために使用されていたと推測されます。

技術的詳細

このバグは、cmd/5l の noop.c 内で、ラッパー関数を処理するロジックに起因していました。noop.c は、リンカがオブジェクトファイルを処理する際に、命令の最適化や変換を行う場所です。

問題の核心は、ラッパー関数が生成される際に、元の命令の条件コード（scond）が失われてしまうことにありました。特に RET.EQ のような条件付きリターン命令は、その条件コードが非常に重要です。ラッパー関数が生成される過程で、この scond がリセットされてしまうと、RET.EQ は無条件の RET として扱われてしまい、期待される条件分岐が行われなくなります。

Goの reflect.Call は、内部的に特定の状況で RET.EQ を使用することがあります。例えば、関数の戻り値が特定の条件を満たす場合にのみリターンするといった最適化や、エラーハンドリングのメカニズムとして利用される可能性があります。ラッパー関数がこの RET.EQ の条件を無視してしまうと、reflect.Call が正しく動作せず、論理的な誤りやランタイムエラーを引き起こしていました。

修正は、ラッパー関数を処理する際に、元の命令の scond を一時的に保存し、ラッパー関数の生成後にそれを復元するというアプローチを取りました。これにより、RET.EQ のような条件付き命令が、ラッパー関数によってその意味を失うことなく、正しく機能するようになりました。

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

変更は src/cmd/5l/noop.c ファイルの noops 関数内で行われました。

--- a/src/cmd/5l/noop.c
+++ b/src/cmd/5l/noop.c
@@ -321,6 +321,13 @@ noops(void)
 				}
 
 				if(cursym->text->reg & WRAPPER) {
+					int cond;
+					
+					// Preserve original RET's cond, to allow RET.EQ
+					// in the implementation of reflect.call.
+					cond = p->scond;
+					p->scond = C_SCOND_NONE;
+
 					// g->panicwrap -= autosize;
 					// MOVW panicwrap_offset(g), R3
 					// SUB $autosize, R3
@@ -347,6 +354,8 @@ noops(void)
 					p->to.reg = REGG;
 					p->to.offset = 2*PtrSize;
 					p = appendp(p);
+
+					p->scond = cond;
 				}
 
 			p->as = AMOVW;

コアとなるコードの解説

変更は if(cursym->text->reg & WRAPPER) ブロック内で行われています。このブロックは、現在のシンボルがラッパー関数である場合に実行されるロジックを含んでいます。

1. int cond;: cond という整数型の変数が宣言されます。これは、元の命令の条件コードを一時的に保存するために使用されます。
2. // Preserve original RET's cond, to allow RET.EQ: コメントで、元の RET 命令の条件コードを保存する目的が説明されています。これは reflect.call の実装で RET.EQ を許可するためです。
3. cond = p->scond;: 現在処理している命令 p の条件コード scond を cond 変数に保存します。p はリンカが処理するアセンブリ命令を表す構造体であり、scond はその命令に付随する条件コード（例: C_SCOND_EQ for EQ）を格納するフィールドです。
4. p->scond = C_SCOND_NONE;: 命令 p の条件コードを C_SCOND_NONE に設定します。これは、ラッパー関数を生成する過程で、一時的に条件コードを無効にするためです。これにより、ラッパー関数内の命令が意図せず条件付きで実行されることを防ぎます。
5. p->scond = cond;: ラッパー関数の生成ロジックが完了した後、保存しておいた元の条件コード cond を、最後に生成された命令 p に復元します。これにより、RET.EQ のような命令が、ラッパー関数によってその条件を失うことなく、正しく機能するようになります。

この修正により、ラッパー関数が生成される際に、元の命令の重要な属性である条件コードが保持されるようになり、reflect.Call が RET.EQ を含む関数を正しく呼び出せるようになりました。

関連リンク

• Go言語の reflect パッケージのドキュメント: https://pkg.go.dev/reflect
• Go言語のツールチェインに関する一般的な情報: https://go.dev/doc/

参考にした情報源リンク

• Go言語の公式ドキュメント
• Go言語のソースコード（特に src/cmd/5l/ ディレクトリ）
• Go言語のコミット履歴とコードレビューシステム (Gerrit)
• アセンブリ言語とCPUアーキテクチャに関する一般的な知識
• リフレクションに関するプログラミングの概念
• Go言語のリンカに関する一般的な情報 (Goのリンカは非常に特殊なため、一般的なリンカの知識だけでなく、Go特有のリンカの動作を理解する必要がある)