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

このコミットは、Go言語のランタイムにおける特定のアーキテクチャ（nacl/386）向けに、syscall.naclWriteという重要なシステムコールシンボルが欠落していた問題を修正するものです。この修正により、./make.bashスクリプトが正常に動作するようになりますが、コミットメッセージには「validationは通過しない」という言及があり、当時のGoのビルドシステムやテスト環境における潜在的な問題を示唆しています。

コミット

commit f2037e1533737d5326c6ab464d165ecf85c70b7c
Author: Dave Cheney <dave@cheney.net>
Date:   Thu Mar 13 07:58:42 2014 +1100

    runtime: fix missing nacl/386 symbol
    
    syscall.naclWrite was missing from sys_nacl_386.s
    
    This gets ./make.bash passing, but doesn't pass validation. I'm not sure if this is the fault of this change, or validation was broken anyway.
    
    LGTM=rsc
    R=minux.ma, rsc
    CC=golang-codereviews
    https://golang.org/cl/74510043

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

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

元コミット内容

runtime: fix missing nacl/386 symbol

syscall.naclWrite was missing from sys_nacl_386.s

This gets ./make.bash passing, but doesn't pass validation. I'm not sure if this is the fault of this change, or validation was broken anyway.

LGTM=rsc
R=minux.ma, rsc
CC=golang-codereviews
https://golang.org/cl/74510043

変更の背景

このコミットの背景には、Go言語がGoogle Native Client (NaCl) プラットフォームをサポートしていたという事実があります。NaClは、ウェブブラウザ内でネイティブコードを安全に実行するための技術であり、Go言語もそのターゲットの一つでした。

Goのランタイムは、異なるオペレーティングシステムやアーキテクチャ（OS/Arch）の組み合わせごとに、低レベルのシステムコールやアセンブリコードを実装する必要があります。nacl/386は、NaCl環境で動作する32ビットx86アーキテクチャを指します。

問題は、syscall.naclWriteという特定のシンボルが、sys_nacl_386.sというアセンブリファイルから欠落していたことです。このシンボルは、GoプログラムがNaCl環境で標準出力などに書き込みを行う際に使用される、writeシステムコールへのラッパー関数を提供するために必要でした。シンボルが欠落していると、Goのビルドプロセス、特に./make.bashのようなビルドスクリプトが、必要なシンボルを見つけられずに失敗する可能性がありました。

コミットメッセージにある「This gets ./make.bash passing, but doesn't pass validation.」という記述は、この修正によってビルド自体は成功するようになったものの、その後の検証ステップ（おそらくテストスイートやより広範なシステムテスト）がまだ失敗していたことを示唆しています。これは、このシンボル欠落が単一の問題ではなく、NaCl環境におけるGoランタイムのより複雑な問題の一部であった可能性を示唆しています。

前提知識の解説

Go言語のランタイムとアセンブリ

Go言語のランタイムは、ガベージコレクション、スケジューラ、システムコールインターフェースなど、Goプログラムの実行を管理する低レベルのコンポーネントの集合体です。パフォーマンスとOSとの直接的な対話のために、ランタイムの一部はGoではなくアセンブリ言語で書かれています。

• TEXTディレクティブ: Goのアセンブリファイル（.s拡張子）では、TEXTディレクティブが関数の開始を宣言します。例えば、TEXT runtime·close(SB),NOSPLIT,$0はruntimeパッケージのclose関数を定義しています。
  • SB: Static Base。グローバルシンボルや外部シンボルを参照するための擬似レジスタ。
  • NOSPLIT: この関数がスタックを分割しないことを示します。通常、小さな関数やスタックフレームが固定されている関数に使用されます。
  • $0: スタックフレームのサイズ。この場合、0バイトのスタックフレームを使用します。
• MOVL: 32ビット値を移動する命令（Move Long）。
• CALL: 関数呼び出し。
• RET: 関数からのリターン。
• FP: Frame Pointer。関数の引数やローカル変数にアクセスするためのレジスタ。arg1+0(FP)のように使用され、FPからのオフセットで引数にアクセスします。
• SP: Stack Pointer。スタックの現在のトップを指すレジスタ。0(SP)のように使用され、スタック上のメモリにアクセスします。
• AX, DI, SI, DX: x86アーキテクチャにおける汎用レジスタ。関数呼び出し規約（calling convention）に従って、引数の受け渡しや戻り値の格納に使用されます。この場合、DI, SI, DXが引数として使われ、AXが戻り値として使われています。

Google Native Client (NaCl)

Google Native Client (NaCl) は、ウェブブラウザ内でネイティブコード（C/C++など）を安全に実行するためのサンドボックス技術です。NaClは、特定のCPUアーキテクチャ（x86-32, x86-64, ARM）向けにコンパイルされたコードを、セキュリティを確保しつつ実行することを可能にします。Go言語は、かつてNaClをターゲットプラットフォームの一つとしてサポートしていました。

• NACL_SYSJMP: NaCl環境特有のマクロで、システムコールを呼び出すためのものです。NaClでは、通常のOSのシステムコールとは異なる方法でシステムコールが処理されます。
• SYS_write: writeシステムコールに対応する番号。

システムコール

システムコールは、ユーザー空間のプログラムがオペレーティングシステムカーネルのサービスを要求するためのメカニズムです。ファイルI/O、ネットワーク通信、メモリ管理など、多くの基本的な操作はシステムコールを通じて行われます。Go言語のランタイムは、これらのシステムコールを抽象化し、Goプログラムから利用できるようにします。

技術的詳細

このコミットは、src/pkg/runtime/sys_nacl_386.sファイルにsyscall·naclWriteという新しいアセンブリ関数を追加することで、syscall.naclWriteシンボルの欠落を修正しています。

Goのアセンブリでは、Goの関数名とアセンブリのシンボル名の間には特定の命名規則があります。syscall.naclWriteというGoの関数は、アセンブリレベルではsyscall·naclWriteというシンボルに対応します（ドット.が中点·に変換されます）。

追加されたsyscall·naclWrite関数は、Goのsyscall.naclWrite関数が呼び出されたときに実行されるアセンブリコードです。この関数は、引数として渡されたファイルディスクリプタ、バッファへのポインタ、書き込むバイト数をレジスタにロードし、最終的にGoランタイムのruntime·write関数を呼び出しています。runtime·write関数は、さらに低レベルでNaClのSYS_writeシステムコールを呼び出す役割を担っています。

この修正のポイントは、Goのsyscallパッケージが提供するnaclWrite関数が、実際にNaCl環境でwriteシステムコールを実行するためのアセンブリレベルのブリッジを確立したことです。これにより、GoプログラムがNaCl環境でファイルやソケットにデータを書き込む際に必要なパスが完成しました。

コミットメッセージの「This gets ./make.bash passing, but doesn't pass validation.」という部分は重要です。これは、シンボルが追加され、ビルドエラーは解消されたものの、その後のテストや検証プロセスで問題が残っていたことを示唆しています。考えられる理由としては、以下の点が挙げられます。

1. 機能の不完全性: naclWriteシンボルは追加されたものの、その実装がNaCl環境のすべてのエッジケースや要件を完全に満たしていなかった可能性があります。
2. 他の依存関係: naclWriteの修正は、NaCl環境でGoが完全に機能するために必要な多くの修正の一つに過ぎず、他の未解決の問題が残っていた可能性があります。
3. テスト環境の問題: 検証プロセス自体がNaCl環境の特定の側面を正しくテストできていなかった、あるいはテスト環境自体に問題があった可能性も考えられます。

このコミットは、Goが特定のプラットフォーム（この場合はNaCl）をサポートする際に、いかに低レベルなアセンブリコードレベルでの調整が必要となるかを示す良い例です。

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

変更はsrc/pkg/runtime/sys_nacl_386.sファイルに対して行われました。具体的には、以下の11行が追加されています。

--- a/src/pkg/runtime/sys_nacl_386.s
+++ b/src/pkg/runtime/sys_nacl_386.s
@@ -27,6 +27,17 @@ TEXT runtime·close(SB),NOSPLIT,$0
 TEXT runtime·read(SB),NOSPLIT,$0
  	NACL_SYSJMP(SYS_read)
 
+TEXT syscall·naclWrite(SB), NOSPLIT, $12-16
+\tMOVL arg1+0(FP), DI
+\tMOVL arg2+4(FP), SI
+\tMOVL arg3+8(FP), DX
+\tMOVL DI, 0(SP)
+\tMOVL SI, 4(SP)
+\tMOVL DX, 8(SP)
+\tCALL runtime·write(SB)
+\tMOVL AX, ret+12(FP)
+\tRET
+\
 TEXT runtime·write(SB),NOSPLIT,$0
  	NACL_SYSJMP(SYS_write)
 

コアとなるコードの解説

追加されたsyscall·naclWriteアセンブリ関数は、以下の処理を行っています。

1. TEXT syscall·naclWrite(SB), NOSPLIT, $12-16:

   • syscall·naclWrite: このアセンブリコードがGoのsyscall.naclWrite関数に対応することを示します。
   • NOSPLIT: この関数がスタックを分割しないことを示します。
   • $12-16: この関数のスタックフレームサイズが12バイトから16バイトの間であることを示します。これは、引数と戻り値を処理するために必要なスタック領域を確保するためです。

2. MOVL arg1+0(FP), DI:

   • arg1+0(FP): 関数に渡された最初の引数（ファイルディスクリプタ）をフレームポインタFPからのオフセット0で参照します。
   • DI: x86のDIレジスタにその値を移動します。これは、Goの関数呼び出し規約において、最初の引数がDIレジスタに渡されることを示唆しています。

3. MOVL arg2+4(FP), SI:

   • arg2+4(FP): 関数に渡された2番目の引数（書き込むデータのバッファへのポインタ）をフレームポインタFPからのオフセット4で参照します。
   • SI: x86のSIレジスタにその値を移動します。

4. MOVL arg3+8(FP), DX:

   • arg3+8(FP): 関数に渡された3番目の引数（書き込むバイト数）をフレームポインタFPからのオフセット8で参照します。
   • DX: x86のDXレジスタにその値を移動します。

   ここまでの3つのMOVL命令は、Goの関数syscall.naclWrite(fd, p, n)の引数fd, p, nをそれぞれDI, SI, DXレジスタにロードしています。

5. MOVL DI, 0(SP):

   • DIレジスタの内容（ファイルディスクリプタ）をスタックポインタSPからのオフセット0に移動します。これは、runtime·write関数を呼び出すための引数をスタックにプッシュしていることを意味します。

6. MOVL SI, 4(SP):

   • SIレジスタの内容（バッファポインタ）をスタックポインタSPからのオフセット4に移動します。

7. MOVL DX, 8(SP):

   • DXレジスタの内容（バイト数）をスタックポインタSPからのオフセット8に移動します。

   これら3つのMOVL命令は、runtime·write関数が期待する引数をスタック上に配置しています。

8. CALL runtime·write(SB):

   • Goランタイムのruntime·write関数を呼び出します。この関数が実際にNaClのSYS_writeシステムコールを呼び出す役割を担っています。

9. MOVL AX, ret+12(FP):

   • CALL runtime·write(SB)の呼び出し後、システムコールの戻り値（通常は書き込まれたバイト数、またはエラーコード）はAXレジスタに格納されます。
   • ret+12(FP): AXレジスタの値を、呼び出し元のGo関数syscall.naclWriteの戻り値が格納されるべきメモリ位置（フレームポインタFPからのオフセット12）に移動します。

10. RET:

    • 関数からリターンし、呼び出し元に制御を戻します。

このアセンブリコードは、Goの高級言語レベルの関数呼び出しを、低レベルのシステムコール呼び出しに変換するための典型的なラッパーの役割を果たしています。

関連リンク

• Go言語のランタイム: Goのランタイムに関する公式ドキュメントやソースコードは、GoプロジェクトのGitHubリポジトリで確認できます。特にsrc/runtimeディレクトリが関連します。
• Google Native Client (NaCl): NaClプロジェクトは現在メンテナンスモードであり、新しい開発は行われていませんが、過去のドキュメントや情報はGoogle Developersサイトや関連する学術論文で参照できます。
• Goのアセンブリ: Goのアセンブリ言語の構文や規約については、Goの公式ドキュメントや「Go Assembly Language」といったキーワードで検索することで詳細な情報を得られます。

参考にした情報源リンク

• Go言語のソースコード (特に src/pkg/runtime ディレクトリ)
• Go言語のアセンブリに関するドキュメント
• Google Native Client (NaCl) に関する過去のドキュメント
• x86アセンブリ言語の基本的な知識
• GoのIssueトラッカーやコードレビューシステム (CL 74510043)

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

このコミットは、Go言語のランタイムにおける特定のアーキテクチャ（nacl/386）向けに、syscall.naclWriteという重要なシステムコールシンボルが欠落していた問題を修正するものです。この修正により、./make.bashスクリプトが正常に動作するようになりますが、コミットメッセージには「validationは通過しない」という言及があり、当時のGoのビルドシステムやテスト環境における潜在的な問題を示唆しています。

コミット

commit f2037e1533737d5326c6ab464d165ecf85c70b7c
Author: Dave Cheney <dave@cheney.net>
Date:   Thu Mar 13 07:58:42 2014 +1100

    runtime: fix missing nacl/386 symbol
    
    syscall.naclWrite was missing from sys_nacl_386.s
    
    This gets ./make.bash passing, but doesn't pass validation. I'm not sure if this is the fault of this change, or validation was broken anyway.
    
    LGTM=rsc
    R=minux.ma, rsc
    CC=golang-codereviews
    https://golang.org/cl/74510043

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

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

元コミット内容

runtime: fix missing nacl/386 symbol

syscall.naclWrite was missing from sys_nacl_386.s

This gets ./make.bash passing, but doesn't pass validation. I'm not sure if this is the fault of this change, or validation was broken anyway.

LGTM=rsc
R=minux.ma, rsc
CC=golang-codereviews
https://golang.org/cl/74510043

変更の背景

このコミットの背景には、Go言語がGoogle Native Client (NaCl) プラットフォームをサポートしていたという事実があります。NaClは、ウェブブラウザ内でネイティブコードを安全に実行するための技術であり、Go言語もそのターゲットの一つでした。

Goのランタイムは、異なるオペレーティングシステムやアーキテクチャ（OS/Arch）の組み合わせごとに、低レベルのシステムコールやアセンブリコードを実装する必要があります。nacl/386は、NaCl環境で動作する32ビットx86アーキテクチャを指します。

問題は、syscall.naclWriteという特定のシンボルが、sys_nacl_386.sというアセンブリファイルから欠落していたことです。このシンボルは、GoプログラムがNaCl環境で標準出力などに書き込みを行う際に使用される、writeシステムコールへのラッパー関数を提供するために必要でした。シンボルが欠落していると、Goのビルドプロセス、特に./make.bashのようなビルドスクリプトが、必要なシンボルを見つけられずに失敗する可能性がありました。

コミットメッセージにある「This gets ./make.bash passing, but doesn't pass validation.」という記述は、この修正によってビルド自体は成功するようになったものの、その後の検証ステップ（おそらくテストスイートやより広範なシステムテスト）がまだ失敗していたことを示唆しています。これは、このシンボル欠落が単一の問題ではなく、NaCl環境におけるGoランタイムのより複雑な問題の一部であった可能性を示唆しています。

前提知識の解説

Go言語のランタイムとアセンブリ

Go言語のランタイムは、ガベージコレクション、スケジューラ、システムコールインターフェースなど、Goプログラムの実行を管理する低レベルのコンポーネントの集合体です。パフォーマンスとOSとの直接的な対話のために、ランタイムの一部はGoではなくアセンブリ言語で書かれています。

• TEXTディレクティブ: Goのアセンブリファイル（.s拡張子）では、TEXTディレクティブが関数の開始を宣言します。例えば、TEXT runtime·close(SB),NOSPLIT,$0はruntimeパッケージのclose関数を定義しています。
  • SB: Static Base。グローバルシンボルや外部シンボルを参照するための擬似レジスタ。
  • NOSPLIT: この関数がスタックを分割しないことを示します。通常、小さな関数やスタックフレームが固定されている関数に使用されます。
  • $0: スタックフレームのサイズ。この場合、0バイトのスタックフレームを使用します。
• MOVL: 32ビット値を移動する命令（Move Long）。
• CALL: 関数呼び出し。
• RET: 関数からのリターン。
• FP: Frame Pointer。関数の引数やローカル変数にアクセスするためのレジスタ。arg1+0(FP)のように使用され、FPからのオフセットで引数にアクセスします。
• SP: Stack Pointer。スタックの現在のトップを指すレジスタ。0(SP)のように使用され、スタック上のメモリにアクセスします。
• AX, DI, SI, DX: x86アーキテクチャにおける汎用レジスタ。関数呼び出し規約（calling convention）に従って、引数の受け渡しや戻り値の格納に使用されます。この場合、DI, SI, DXが引数として使われ、AXが戻り値として使われています。

Google Native Client (NaCl)

Google Native Client (NaCl) は、ウェブブラウザ内でネイティブコード（C/C++など）を安全に実行するためのサンドボックス技術です。NaClは、特定のCPUアーキテクチャ（x86-32, x86-64, ARM）向けにコンパイルされたコードを、セキュリティを確保しつつ実行することを可能にします。Go言語は、かつてNaClをターゲットプラットフォームの一つとしてサポートしていました。

• NACL_SYSJMP: NaCl環境特有のマクロで、システムコールを呼び出すためのものです。NaClでは、通常のOSのシステムコールとは異なる方法でシステムコールが処理されます。
• SYS_write: writeシステムコールに対応する番号。

システムコール

システムコールは、ユーザー空間のプログラムがオペレーティングシステムカーネルのサービスを要求するためのメカニズムです。ファイルI/O、ネットワーク通信、メモリ管理など、多くの基本的な操作はシステムコールを通じて行われます。Go言語のランタイムは、これらのシステムコールを抽象化し、Goプログラムから利用できるようにします。

技術的詳細

このコミットは、src/pkg/runtime/sys_nacl_386.sファイルにsyscall·naclWriteという新しいアセンブリ関数を追加することで、syscall.naclWriteシンボルの欠落を修正しています。

Goのアセンブリでは、Goの関数名とアセンブリのシンボル名の間には特定の命名規則があります。syscall.naclWriteというGoの関数は、アセンブリレベルではsyscall·naclWriteというシンボルに対応します（ドット.が中点·に変換されます）。

追加されたsyscall·naclWrite関数は、Goのsyscall.naclWrite関数が呼び出されたときに実行されるアセンブリコードです。この関数は、引数として渡されたファイルディスクリプタ、バッファへのポインタ、書き込むバイト数をレジスタにロードし、最終的にGoランタイムのruntime·write関数を呼び出しています。runtime·write関数は、さらに低レベルでNaClのSYS_writeシステムコールを呼び出す役割を担っています。

この修正のポイントは、Goのsyscallパッケージが提供するnaclWrite関数が、実際にNaCl環境でwriteシステムコールを実行するためのアセンブリレベルのブリッジを確立したことです。これにより、GoプログラムがNaCl環境でファイルやソケットにデータを書き込む際に必要なパスが完成しました。

コミットメッセージの「This gets ./make.bash passing, but doesn't pass validation.」という部分は重要です。これは、シンボルが追加され、ビルドエラーは解消されたものの、その後のテストや検証プロセスで問題が残っていたことを示唆しています。考えられる理由としては、以下の点が挙げられます。

1. 機能の不完全性: naclWriteシンボルは追加されたものの、その実装がNaCl環境のすべてのエッジケースや要件を完全に満たしていなかった可能性があります。
2. 他の依存関係: naclWriteの修正は、NaCl環境でGoが完全に機能するために必要な多くの修正の一つに過ぎず、他の未解決の問題が残っていた可能性があります。
3. テスト環境の問題: 検証プロセス自体がNaCl環境の特定の側面を正しくテストできていなかった、あるいはテスト環境自体に問題があった可能性も考えられます。

このコミットは、Goが特定のプラットフォーム（この場合はNaCl）をサポートする際に、いかに低レベルなアセンブリコードレベルでの調整が必要となるかを示す良い例です。

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

変更はsrc/pkg/runtime/sys_nacl_386.sファイルに対して行われました。具体的には、以下の11行が追加されています。

--- a/src/pkg/runtime/sys_nacl_386.s
+++ b/src/pkg/runtime/sys_nacl_386.s
@@ -27,6 +27,17 @@ TEXT runtime·close(SB),NOSPLIT,$0
 TEXT runtime·read(SB),NOSPLIT,$0
  	NACL_SYSJMP(SYS_read)
 
+TEXT syscall·naclWrite(SB), NOSPLIT, $12-16
+\tMOVL arg1+0(FP), DI
+\tMOVL arg2+4(FP), SI
+\tMOVL arg3+8(FP), DX
+\tMOVL DI, 0(SP)
+\tMOVL SI, 4(SP)
+\tMOVL DX, 8(SP)
+\tCALL runtime·write(SB)
+\tMOVL AX, ret+12(FP)
+\tRET
+\
 TEXT runtime·write(SB),NOSPLIT,$0
  	NACL_SYSJMP(SYS_write)
 

コアとなるコードの解説

追加されたsyscall·naclWriteアセンブリ関数は、以下の処理を行っています。

1. TEXT syscall·naclWrite(SB), NOSPLIT, $12-16:

   • syscall·naclWrite: このアセンブリコードがGoのsyscall.naclWrite関数に対応することを示します。
   • NOSPLIT: この関数がスタックを分割しないことを示します。
   • $12-16: この関数のスタックフレームサイズが12バイトから16バイトの間であることを示します。これは、引数と戻り値を処理するために必要なスタック領域を確保するためです。

2. MOVL arg1+0(FP), DI:

   • arg1+0(FP): 関数に渡された最初の引数（ファイルディスクリプタ）をフレームポインタFPからのオフセット0で参照します。
   • DI: x86のDIレジスタにその値を移動します。これは、Goの関数呼び出し規約において、最初の引数がDIレジスタに渡されることを示唆しています。

3. MOVL arg2+4(FP), SI:

   • arg2+4(FP): 関数に渡された2番目の引数（書き込むデータのバッファへのポインタ）をフレームポインタFPからのオフセット4で参照します。
   • SI: x86のSIレジスタにその値を移動します。

4. MOVL arg3+8(FP), DX:

   • arg3+8(FP): 関数に渡された3番目の引数（書き込むバイト数）をフレームポインタFPからのオフセット8で参照します。
   • DX: x86のDXレジスタにその値を移動します。

   ここまでの3つのMOVL命令は、Goの関数syscall.naclWrite(fd, p, n)の引数fd, p, nをそれぞれDI, SI, DXレジスタにロードしています。

5. MOVL DI, 0(SP):

   • DIレジスタの内容（ファイルディスクリプタ）をスタックポインタSPからのオフセット0に移動します。これは、runtime·write関数を呼び出すための引数をスタックにプッシュしていることを意味します。

6. MOVL SI, 4(SP):

   • SIレジスタの内容（バッファポインタ）をスタックポインタSPからのオフセット4に移動します。

7. MOVL DX, 8(SP):

   • DXレジスタの内容（バイト数）をスタックポインタSPからのオフセット8に移動します。

   これら3つのMOVL命令は、runtime·write関数が期待する引数をスタック上に配置しています。

8. CALL runtime·write(SB):

   • Goランタイムのruntime·write関数を呼び出します。この関数が実際にNaClのSYS_writeシステムコールを呼び出す役割を担っています。

9. MOVL AX, ret+12(FP):

   • CALL runtime·write(SB)の呼び出し後、システムコールの戻り値（通常は書き込まれたバイト数、またはエラーコード）はAXレジスタに格納されます。
   • ret+12(FP): AXレジスタの値を、呼び出し元のGo関数syscall.naclWriteの戻り値が格納されるべきメモリ位置（フレームポインタFPからのオフセット12）に移動します。

10. RET:

    • 関数からリターンし、呼び出し元に制御を戻します。

このアセンブリコードは、Goの高級言語レベルの関数呼び出しを、低レベルのシステムコール呼び出しに変換するための典型的なラッパーの役割を果たしています。

関連リンク

• Go言語のランタイム: Goのランタイムに関する公式ドキュメントやソースコードは、GoプロジェクトのGitHubリポジトリで確認できます。特にsrc/runtimeディレクトリが関連します。
• Google Native Client (NaCl): NaClプロジェクトは現在メンテナンスモードであり、新しい開発は行われていませんが、過去のドキュメントや情報はGoogle Developersサイトや関連する学術論文で参照できます。
• Goのアセンブリ: Goのアセンブリ言語の構文や規約については、Goの公式ドキュメントや「Go Assembly Language」といったキーワードで検索することで詳細な情報を得られます。

参考にした情報源リンク

• Go言語のソースコード (特に src/pkg/runtime ディレクトリ)
• Go言語のアセンブリに関するドキュメント
• Google Native Client (NaCl) に関する過去のドキュメント
• x86アセンブリ言語の基本的な知識
• GoのIssueトラッカーやコードレビューシステム (CL 74510043)