Addr2lineはGNU addr2lineツールの最低限のシミュレーションであり、pprofをサポートするために必要なだけの機能を有しています。 使用方法： go tool addr2line バイナリ Addr2lineは標準入力から16進数のアドレスを読み取ります。各入力アドレスに対して、addr2lineは2つの出力行を表示します。まず、アドレスを含む関数の名前が表示され、次にそのアドレスに対応するソースコードのファイルと行が表示されます。 このツールはpprofの内部でのみ使用することを目的としており、将来のリリースでインターフェースが変更される可能性があるか、または完全に削除される可能性があります。.

Cgoを使用すると、Cコードを呼び出すGoパッケージを作成できます。 # goコマンドでcgoを使用する cgoを使用するには、擬似パッケージ「C」をインポートする通常のGoコードを書きます。 その後、GoコードはC.size_tのような型、C.stdoutのような変数、またはC.putcharのような関数を参照できます。 「C」のインポートが直前にコメントで指定されている場合、そのコメントは前文と呼ばれ、 パッケージのC部分をコンパイルするときにヘッダーとして使用されます。 例えば： // #include <stdio.h> // #include <errno.h> import "C" プリアンブルには、関数や変数の宣言や定義を含むCコードを含めることができます。 これらは、パッケージ「C」に定義されているかのように、Goコードから参照できます。 プリアンブルで宣言されたすべての名前は使用できますが、小文字で始まる場合でも使用できます。 例外：プリアンブルの静的変数は、Goコードから参照できません。静的関数は許可されています。 $GOROOT/cmd/cgo/internal/teststdioと$GOROOT/misc/cgo/gmpを参照して、例を確認してください。 cgoの使用についての紹介については、「C？Go？Cgo！」を参照してください： https://golang.org/doc/articles/c_go_cgo.html 。 CFLAGS、CPPFLAGS、CXXFLAGS、FFLAGS、およびLDFLAGSは、これらのコメント内の疑似#cgoディレクティブで定義できます。 これにより、C、C ++、またはFortranコンパイラの動作を調整できます。 複数のディレクティブで定義された値は連結されます。 ディレクティブには、その効果を制限するビルド制約のリストを含めることができます。 （制約構文の詳細については、https://golang.org/pkg/go/build/#hdr-Build_Constraints を参照してください。） 例えば： // #cgo CFLAGS: -DPNG_DEBUG=1 // #cgo amd64 386 CFLAGS: -DX86=1 // #cgo LDFLAGS: -lpng // #include <png.h> import "C" 代わりに、'#cgo pkg-config:'ディレクティブに続いてパッケージ名を指定することで、 pkg-configツールを使用してCPPFLAGSとLDFLAGSを取得できます。 例えば： // #cgo pkg-config: png cairo // #include <png.h> import "C" デフォルトのpkg-configツールは、PKG_CONFIG環境変数を設定することで変更できます。 セキュリティ上の理由から、許可されるフラグは-D、-U、-I、および-lのみです。 追加のフラグを許可するには、CGO_CFLAGS_ALLOWを正規表現に設定し、新しいフラグに一致するようにします。 許可されるフラグを禁止するには、CGO_CFLAGS_DISALLOWを正規表現に設定し、禁止する必要がある引数に一致するようにします。 両方の場合、正規表現は完全な引数に一致する必要があります。-mfoo=barを許可するには、CGO_CFLAGS_ALLOW='-mfoo.*'を使用します。 単にCGO_CFLAGS_ALLOW='-mfoo'ではなく、同様の名前の変数が許可されるCPPFLAGS、CXXFLAGS、FFLAGS、およびLDFLAGSを制御します。 また、セキュリティ上の理由から、英数字文字といくつかの記号（例えば、'.'など）のみが許可されており、 予期しない方法で解釈されないいくつかの記号が許可されています。 禁止された文字を使用すると、「malformed #cgo argument」エラーが発生します。 ビルド時に、CGO_CFLAGS、CGO_CPPFLAGS、CGO_CXXFLAGS、CGO_FFLAGS、およびCGO_LDFLAGS環境変数は、 これらのディレクティブから派生したフラグに追加されます。 パッケージ固有のフラグは、環境変数ではなくディレクティブを使用して設定する必要があります。 これにより、変更されていない環境でビルドが機能するようになります。 環境変数から取得したフラグは、上記で説明したセキュリティ上の制限の対象外です。 パッケージ内のすべてのcgo CPPFLAGSおよびCFLAGSディレクティブは連結され、 そのパッケージのCファイルをコンパイルするために使用されます。 パッケージ内のすべてのCPPFLAGSおよびCXXFLAGSディレクティブは連結され、 そのパッケージのC++ファイルをコンパイルするために使用されます。 パッケージ内のすべてのCPPFLAGSおよびFFLAGSディレクティブは連結され、 そのパッケージのFortranファイルをコンパイルするために使用されます。 プログラム内の任意のパッケージのすべてのLDFLAGSディレクティブは連結され、リンク時に使用されます。 すべてのpkg-configディレクティブは連結され、同時にpkg-configに送信され、 各適切なコマンドラインフラグのセットに追加されます。 cgoディレクティブが解析されると、文字列${SRCDIR}の出現箇所は、ソースファイルを含むディレクトリの絶対パスに置き換えられます。 これにより、事前にコンパイルされた静的ライブラリをパッケージディレクトリに含め、適切にリンクすることができます。 例えば、パッケージfooがディレクトリ/go/src/fooにある場合： // #cgo LDFLAGS: -L${SRCDIR}/libs -lfoo 次のように展開されます： // #cgo LDFLAGS: -L/go/src/foo/libs -lfoo Goツールが1つ以上のGoファイルで特別なインポート「C」を使用することを検出すると、 ディレクトリ内の他の非Goファイルを検索して、Goパッケージの一部としてコンパイルします。 .c、.s、.S、または.sxファイルはCコンパイラでコンパイルされます。 .cc、.cpp、または.cxxファイルはC ++コンパイラでコンパイルされます。 .f、.F、.for、または.f90ファイルはFortranコンパイラでコンパイルされます。 .h、.hh、.hpp、または.hxxファイルは別途コンパイルされませんが、 これらのヘッダーファイルが変更された場合、パッケージ（およびその非Goソースファイル）が再コンパイルされます。 他のディレクトリのファイルを変更しても、パッケージが再コンパイルされるわけではないため、 パッケージのすべての非Goソースコードはサブディレクトリではなく、パッケージディレクトリに保存する必要があります。 デフォルトのCおよびC++コンパイラは、それぞれCCおよびCXX環境変数によって変更できます。 これらの環境変数には、コマンドラインオプションを含めることができます。 cgoツールは常に、ソースファイルのディレクトリを含むパスでCコンパイラを呼び出します。 つまり、-I${SRCDIR}が常に暗示されます。これは、ヘッダーファイルfoo/bar.hが、 ソースディレクトリとシステムインクルードディレクトリ（または-Iフラグで指定された他の場所）の両方に存在する場合、 「#include <foo/bar.h>」が常に他のバージョンよりも優先してローカルバージョンを見つけることを意味します。 cgoツールは、動作が期待されるシステムでのネイティブビルドではデフォルトで有効になっています。 クロスコンパイル時や、CC環境変数が設定されていない場合、およびデフォルトのCコンパイラ（通常はgccまたはclang）がシステムPATHに見つからない場合は、デフォルトで無効になります。 goツールを実行する際にCGO_ENABLED環境変数を設定することで、デフォルトを上書きできます。 cgoの使用を有効にするには、1に設定し、無効にするには0に設定します。 goツールは、cgoが有効になっている場合、ビルド制約「cgo」を設定します。 特別なインポート「C」は、「//go:build cgo」と同じように「cgo」ビルド制約を意味するため、 cgoが無効になっている場合、Cをインポートするファイルはgoツールによってビルドされません。 （ビルド制約の詳細については、https://golang.org/pkg/go/build/#hdr-Build_Constraints を参照してください。） クロスコンパイル時には、cgoが使用するCクロスコンパイラを指定する必要があります。 これは、make.bashを使用してツールチェーンをビルドする際に、一般的なCC_FOR_TARGETまたは より具体的なCC_FOR_${GOOS}_${GOARCH}（例：CC_FOR_linux_arm）環境変数を設定することで行うことができます。 または、goツールを実行する際にいつでもCC環境変数を設定することができます。 C++コードに対しては、CXX_FOR_TARGET、CXX_FOR_${GOOS}_${GOARCH}、およびCXX環境変数が同様の方法で機能します。 # GoからCへの参照 Goファイル内で、GoのキーワードであるCの構造体フィールド名には、アンダースコアを前置することでアクセスできます。 たとえば、xが「type」という名前のフィールドを持つC構造体を指す場合、x._typeでフィールドにアクセスできます。 ビットフィールドやアラインメントされていないデータなど、Goで表現できないC構造体フィールドは、 次のフィールドまたは構造体の末尾に到達するまで、適切なパディングに置き換えられてGo構造体から省略されます。 標準のC数値型は、以下の名前で利用可能です。 C.char、C.schar（signed char）、C.uchar（unsigned char）、 C.short、C.ushort（unsigned short）、C.int、C.uint（unsigned int）、 C.long、C.ulong（unsigned long）、C.longlong（long long）、 C.ulonglong（unsigned long long）、C.float、C.double、 C.complexfloat（complex float）、およびC.complexdouble（complex double）。 C型void *は、Goのunsafe.Pointerで表されます。 C型__int128_tおよび__uint128_tは、[16]byteで表されます。 Goで通常はポインタ型で表されるいくつかの特別なC型は、代わりにuintptrで表されます。 詳細については、以下の特別なケースのセクションを参照してください。 構造体、共用体、または列挙型に直接アクセスするには、C.struct_statのように、 それにstruct_、union_、またはenum_をプレフィックスとして付けます。 任意のC型Tのサイズは、C.sizeof_struct_statのように、C.sizeof_Tとして利用できます。 これらの特別なプレフィックスは、「struct_」、「union_」、「enum_」、または「sizeof_」で始まる C識別子を直接参照する方法がないことを意味します。例えば、「struct_function」という名前の関数です。 回避策として、前置きに「#define」を使用し、「#define c_struct_function struct_function」のようにし、 Goコード内で「C.c_struct_function」と参照します。 Goファイルで、特別な名前_GoString_のパラメータ型を持つC関数を宣言することができます。 この関数は、通常のGo文字列値で呼び出すことができます。 文字列の長さと、文字列の内容へのポインタは、C関数を呼び出すことでアクセスできます。 size_t _GoStringLen(_GoString_ s); const char *_GoStringPtr(_GoString_ s); これらの関数は、他のCファイルではなく、プリアンブルでのみ使用できます。 Cコードは、_GoStringPtrによって返されるポインタの内容を変更してはいけません。 文字列の内容には、末尾のNULバイトがない場合があることに注意してください。 一般的な場合、GoはCの共用体型をサポートしていないため、 Cの共用体型は同じ長さのGoバイト配列として表されます。 Goの構造体には、Cの型を埋め込むことはできません。 Goのコードは、非空のC構造体の末尾にあるサイズゼロのフィールドを参照することはできません。 （サイズゼロのフィールドでできる唯一の操作である）そのようなフィールドのアドレスを取得するには、 構造体のアドレスを取得し、構造体のサイズを加算する必要があります。 Cgoは、Cの型を同等の非公開のGoの型に変換します。 翻訳が非公開であるため、GoパッケージはCの型をエクスポートされたAPIで公開すべきではありません。 1つのGoパッケージで使用されるCの型は、別のGoパッケージで使用される同じCの型とは異なります。 任意のC関数（void関数でも）は、複数の代入コンテキストで呼び出すことができ、 戻り値（ある場合）とC errno変数をエラーとして取得できます（関数がvoidを返す場合は、結果値をスキップするために_を使用します）。 例えば： n, err = C.sqrt(-1) _, err := C.voidFunc() var n, err = C.sqrt(1) Cの関数ポインタを呼び出すことは現在サポートされていませんが、 Cの関数ポインタを保持するGo変数を宣言し、GoとCの間で相互に渡すことができます。 Cコードは、Goから受け取った関数ポインタを呼び出すことができます。 例えば： package main // typedef int (*intFunc) (); // // int // bridge_int_func(intFunc f) // { // return f(); // } // // int fortytwo() // { // return 42; // } import "C" import "fmt" func main() { f := C.intFunc(C.fortytwo) fmt.Println(int(C.bridge_int_func(f))) // Output: 42 } C言語では、固定サイズの配列として書かれた関数引数は、実際には配列の最初の要素へのポインタを必要とします。 Cコンパイラはこの呼び出し規約を認識して、呼び出しを適切に調整しますが、Goはできません。 Goでは、最初の要素へのポインタを明示的に渡す必要があります：C.f(&C.x[0])。 可変長のC関数を呼び出すことはサポートされていません。C関数ラッパーを使用することで、これを回避することができます。 例えば： package main // #include <stdio.h> // #include <stdlib.h> // // static void myprint(char* s) { // printf("%s\n", s); // } import "C" import "unsafe" func main() { cs := C.CString("Hello from stdio") C.myprint(cs) C.free(unsafe.Pointer(cs)) } いくつかの特別な関数は、データのコピーを作成することによって、 GoとCの型の間を変換します。疑似Go定義では次のようになります。 // Go文字列からC文字列へ // C文字列はmallocを使用してCヒープに割り当てられます。 // 解放する責任は呼び出し側にあります。たとえば、C.freeを呼び出すことで解放できます // （C.freeが必要な場合はstdlib.hを含めることを忘れないでください）。 func C.CString(string) *C.char // Goの[]byteスライスからCの配列へ // Cの配列はmallocを使用してCヒープに割り当てられます。 // 解放する責任は呼び出し側にあります。たとえば、C.freeを呼び出すことで解放できます // （C.freeが必要な場合はstdlib.hを含めることを忘れないでください）。 func C.CBytes([]byte) unsafe.Pointer // C文字列からGo文字列へ func C.GoString(*C.char) string // 明示的な長さを持つCデータからGo文字列へ func C.GoStringN(*C.char, C.int) string // 明示的な長さを持つCデータからGoの[]byteスライスへ func C.GoBytes(unsafe.Pointer, C.int) []byte // 特別な場合として、C.mallocはCライブラリmallocを直接呼び出すのではなく、 // CライブラリmallocをラップするGoヘルパー関数を呼び出しますが、 // nilを返さないことを保証します。Cのmallocがメモリ不足を示す場合、 // ヘルパー関数はプログラムをクラッシュさせます。Go自体がメモリ不足になった場合と同様です。 // C.mallocは失敗しないため、errnoを返す2つの結果形式はありません。 // CからGoへの参照 // // Go関数は、Cコードで使用するために次の方法でエクスポートできます。 //export MyFunction func MyFunction(arg1, arg2 int, arg3 string) int64 {...} //export MyFunction2 func MyFunction2(arg1, arg2 int, arg3 string) (int64, *C.char) {...} Cコードでは、次のように使用できます。 extern GoInt64 MyFunction(int arg1, int arg2, GoString arg3); extern struct MyFunction2_return MyFunction2(int arg1, int arg2, GoString arg3); // _cgo_export.h生成ヘッダーで見つかった、前文からコピーされたプリアンブルの後にある // 複数の戻り値を持つ関数は、構造体を返す関数にマップされます。 すべてのGoの型が有用な方法でCの型にマップできるわけではありません。 Goの構造体型はサポートされていません。Cの構造体型を使用してください。 Goの配列型はサポートされていません。Cのポインタ型を使用してください。 Goのstring型の引数を取る関数は、上記で説明した _GoString_ 型のCタイプで呼び出すことができます。 _GoString_ 型は自動的にプリアンブルで定義されます。 Cコードからこの型の値を作成する方法はありません。これは、GoからCに文字列値を渡し、 再びGoに戻すためにのみ有用です。 ファイルで//exportを使用すると、プリアンブルに制限が設けられます。 2つの異なるC出力ファイルにコピーされるため、定義ではなく宣言のみを含める必要があります。 ファイルに定義と宣言の両方が含まれている場合、2つの出力ファイルは重複するシンボルを生成し、 リンカーが失敗します。これを回避するには、定義を他のファイルのプリアンブルまたはCソースファイルに配置する必要があります。 # ポインタの渡し方 Goはガベージコレクションされる言語であり、ガベージコレクタはGoメモリへのすべてのポインタの場所を知る必要があります。 そのため、GoとCの間でポインタを渡す際には制限があります。 このセクションでは、Goポインタという用語は、Goによって割り当てられたメモリへのポインタを意味します （＆演算子を使用するか、定義済みのnew関数を呼び出すことによって）。 Cポインタという用語は、Cによって割り当てられたメモリへのポインタを意味します（C.mallocを呼び出すことによって）。 ポインタがGoポインタであるかCポインタであるかは、メモリがどのように割り当てられたかによって動的に決定されます。 ポインタの型とは何の関係もありません。 注意: 一部のGo型の値は、その型のゼロ値以外の場合、常にGoポインタを含みます。 これは、インターフェース、チャネル、マップ、および関数型に当てはまります。 ポインタ型はGoポインタまたはCポインタを保持することができます。 配列、スライス、文字列、および構造体型は、その型と構築方法に応じて、 Goポインタを含む場合と含まない場合があります。 以下のGoポインタに関する議論は、ポインタ型だけでなく、 Goポインタを含む他の型にも適用されます。 Cに渡されるすべてのGoポインタは、固定されたGoメモリを指す必要があります。 C関数に関数引数として渡されるGoポインタは、 呼び出しの期間中暗黙的に固定されたメモリを指します。 これらの関数引数から到達可能なGoメモリは、Cコードがアクセスできる限り固定されている必要があります。 Goメモリが固定されているかどうかは、そのメモリ領域の動的なプロパティであり、 ポインタの型とは何の関係もありません。 newを呼び出すことによって、複合リテラルのアドレスを取得することによって、またはローカル変数のアドレスを取得することによって作成されたGo値は、 [runtime.Pinner] を使用してメモリを固定することもできます。この型は、メモリの固定状態の期間を管理するために使用でき、 C関数呼び出しの期間を超えてメモリを固定することができます。メモリは複数回固定でき、 固定された回数と同じ回数だけ固定を解除する必要があります。 Goのコードは、ポイント先のメモリにGoポインタが含まれていない場合、 GoポインタをCに渡すことができます。構造体のフィールドにポインタを渡す場合、 問題のGoメモリはフィールドによって占有されるメモリであり、構造体全体ではありません。 配列またはスライスの要素にポインタを渡す場合、問題のGoメモリは 配列全体またはスライスのバッキング配列全体です。 Cのコードは、Goポインタが指すメモリが固定されている限り、Goポインタのコピーを保持できます。 Cのコードは、呼び出しが返された後、Goポインタのコピーを保持することはできません。 ただし、ポインタが指すメモリが [runtime.Pinner] で固定され、PinnerがGoポインタがCメモリに格納されている間にアンピンされない場合は、 Cのメモリに格納されたGoポインタを保持できます。 これは、Cコードが文字列、スライス、チャネルなどのコピーを保持できないことを意味します。 これらは [runtime.Pinner] で固定できないためです。 _GoString_ 型も [runtime.Pinner] で固定することはできません。 Goポインタを含むため、指すメモリは呼び出しの期間だけ固定されます。 _GoString_ 値はCコードによって保持されることはできません。 Cコードによって呼び出されるGo関数は、 ピン留めされたメモリへのGoポインタを返すことができます （これは、文字列、スライス、チャネルなどを返すことはできないことを意味します）。 Cコードによって呼び出されるGo関数は、Cポインタを引数として取ることができ、 それらのポインタを介して非ポインタデータ、Cポインタ、またはピン留めされたGoポインタを格納することができます。 Goポインタを指すメモリにGoポインタを格納することはできません。 （これは、文字列、スライス、チャネルなどを格納することはできないことを意味します）。 Cコードによって呼び出されるGo関数は、Goポインタを取ることができますが、 指すGoメモリ（およびそのメモリが指すGoメモリなど）がピン留めされていることを保証する必要があります。 これらのルールは、実行時に動的にチェックされます。チェックは、GODEBUG環境変数のcgocheck設定によって制御されます。 デフォルトの設定はGODEBUG=cgocheck=1で、比較的安価な動的チェックが実装されています。 これらのチェックは、GODEBUG=cgocheck=0を使用して完全に無効にすることができます。 ポインタの処理の完全なチェックは、実行時間のコストがかかりますが、ビルド時にGOEXPERIMENT=cgocheck2を使用して利用できます。 unsafeパッケージを使用することで、この強制を無効にすることができます。 もちろん、Cコードが好きなことをすることを防ぐものは何もありません。 ただし、これらのルールを破るプログラムは、予期しない方法で失敗する可能性があります。 runtime/cgo.Handle型は、GoとCの間で安全にGo値を渡すために使用できます。 詳細については、runtime/cgoパッケージのドキュメントを参照してください。 注：現在の実装にはバグがあります。GoコードはCメモリにnilまたはCポインタ（ただしGoポインタではない）を書き込むことが許可されていますが、 現在の実装では、Cメモリの内容がGoポインタであるように見える場合には、ランタイムエラーが発生することがあります。 したがって、Goコードがその中にポインタ値を格納する場合は、初期化されていないCメモリをGoコードに渡すことを避けてください。 Cでメモリをゼロにしてから渡してください。 # 特殊なケース 通常、Goではポインタ型で表されるいくつかの特殊なC型は、代わりにuintptrで表されます。それらには以下が含まれます: 1.

コンパイルは通常、 ``go tool compile'' として呼び出され、コマンドラインで指定されたファイルの名前を持つ単一のGoパッケージをコンパイルします。それはその後、最初のソースファイルのベース名に.oの接尾辞を付けた単一のオブジェクトファイルを書き込みます。オブジェクトファイルは、他のオブジェクトと組み合わせてパッケージアーカイブに結合するか、直接リンカ（ ``go tool link''）に渡すことができます。-packを使用して呼び出された場合、コンパイラは中間オブジェクトファイルを経由せずに直接アーカイブを書き込みます。 生成されたファイルには、パッケージがエクスポートするシンボルに関する型情報と、パッケージが他のパッケージからインポートされたシンボルで使用される型に関する情報が含まれています。したがって、パッケージPのクライアントCをコンパイルする場合、Pの依存関係のファイルを読み込む必要はありません。コンパイルされたPの出力のみが必要です。 コマンドライン 使用法： go tool compile [フラグ] ファイル..

DistはGoの配布をブートストラップ、ビルド、テストするのに役立ちます。 使用方法： go tool dist [コマンド] コマンドは以下の通りです： banner インストールバナーを表示する bootstrap すべてを再ビルドする clean すべてのビルドファイルを削除する env [-p] 環境を表示する（-p：$PATHを含む） install [dir] 個々のディレクトリをインストールする list [-json] サポートされているすべてのプラットフォームをリストする test [-h] Goテストを実行する version Goのバージョンを表示する.

DistpackはGoの配布用のtgzファイルとzipファイルを作成します。 これはGOROOT/pkg/distpackに書き込みます： - 現在のGOOSとGOARCH向けのバイナリ配布（tgzまたはzip） - GOOS/GOARCHに依存しないソース配布 - ゴーグルコマンドで使用されるようにダウンロードするためのモジュールmod、info、zipファイル Distpackは通常、make.bashの-distpackフラグによって呼び出されます。 goos/goarch向けのクロスコンパイル配布は次のようにしてビルドできます： GOOS=goos GOARCH=goarch ./make.bash -distpack モジュールのダウンロードがgoコマンドで使用可能であるかをテストするには： ./make.bash -distpack mkdir -p /tmp/goproxy/golang.org/toolchain/ ln -sf $(pwd)/../pkg/distpack /tmp/goproxy/golang.org/toolchain/@v GOPROXY=file:///tmp/goproxy GOTOOLCHAIN=$(sed 1q ../VERSION) gotip version gotipは、リリースされた古いGoのバージョンで置き換えることができます。 make.bashがビルドしたバージョンであるため、それをスキップします。.

Doc (通常は go doc として実行される) は 0 個、1 個、または 2 個の引数を受け付けます。 0 個の引数: go doc 現在のディレクトリに含まれるパッケージのドキュメントを表示します。 1 個の引数: go doc <pkg> go doc <sym>[.<methodOrField>] go doc [<pkg>.]<sym>[.<methodOrField>] go doc [<pkg>.][<sym>.]<methodOrField> 成功する最初の項目のドキュメントが表示されます。シンボルが指定されているがパッケージが指定されていない場合、現在のディレクトリのパッケージが選択されます。ただし、引数が大文字で始まる場合は常に現在のディレクトリのシンボルと見なされます。 2 個の引数: go doc <pkg> <sym>[.<methodOrField>] パッケージ、シンボル、およびメソッドまたはフィールドのドキュメントを表示します。最初の引数は完全なパッケージパスである必要があります。これは godoc コマンドのコマンドライン使用法と似ています。 コマンドの場合、-cmd フラグが存在しない限り、"go doc コマンド" はパッケージレベルのドキュメントのみ表示します。 -src フラグを指定すると、doc は構造体、関数、またはメソッドの本体などのシンボルの全ソースコードを表示します。 -all フラグを指定すると、doc はパッケージとその可視なシンボルのすべてのドキュメントを表示します。引数はパッケージを識別する必要があります。 完全なドキュメントについては、「go help doc」を実行してください。.

Goは、Goのソースコードを管理するためのツールです。 使用法: go <コマンド> [引数] コマンドは以下の通りです: bug バグレポートを開始する build パッケージと依存関係をコンパイルする clean オブジェクトファイルとキャッシュファイルを削除する doc パッケージまたはシンボルのドキュメンテーションを表示する env Goの環境情報を表示する fix パッケージを更新して新しいAPIを使用する fmt gofmt（再フォーマット）パッケージソース generate ソースを処理してGoのファイルを生成する get 現在のモジュールに依存関係を追加し、それらをインストールする install パッケージと依存関係をコンパイルし、インストールする list パッケージまたはモジュールをリストする mod モジュールのメンテナンス work ワークスペースのメンテナンス run Goのプログラムをコンパイルして実行する telemetry テレメトリーデータと設定を管理します test パッケージをテストする tool 指定されたgoツールを実行する version Goのバージョンを表示する vet パッケージのおそらく間違いを報告する "go help <コマンド>"を使用して、コマンドの詳細情報を取得します。 追加のヘルプトピック: buildconstraint ビルド制約 buildmode ビルドモード c GoとC間の呼び出し cache ビルドとテストのキャッシュ environment 環境変数 filetype ファイルタイプ go.mod go.modファイル gopath GOPATH環境変数 goproxy モジュールプロキシプロトコル importpath インポートパスの構文 modules モジュール、モジュールバージョンなど module-auth go.sumを使用したモジュール認証 packages パッケージリストとパターン private 非公開コードのダウンロード設定 testflag テストフラグ testfunc テスト関数 vcs GOVCSでバージョン管理を制御 "go help <トピック>"を使用して、そのトピックに関する詳細情報を取得します。 # Start a bug report 使用法: go bug Bugはデフォルトのブラウザを開き、新しいバグレポートを開始します。 レポートには、役立つシステム情報が含まれます。 # Compile packages and dependencies 使用法: go build [-o output] [build flags] [packages] Buildは、インポートパスで指定されたパッケージとその依存関係をコンパイルしますが、 結果はインストールされません。 buildへの引数が単一のディレクトリからの.goファイルのリストである場合、 buildはそれらを単一のパッケージを指定するソースファイルのリストとして扱います。 パッケージをコンパイルするとき、buildは'_test.go'で終わるファイルを無視します。 単一のmainパッケージをコンパイルするとき、buildは結果の 実行可能ファイルをパッケージインポートパスの最後の非メジャーバージョン コンポーネントに基づいて名付けられた出力ファイルに書き込みます。Windows実行可能ファイルを 書き込むときには'.exe'のサフィックスが追加されます。 したがって、'go build example/sam'は'sam'または'sam.exe'を書き込みます。 'go build example.com/foo/v2'は'foo'または'foo.exe'を書き込み、'v2.exe'ではありません。 .goファイルのリストからパッケージをコンパイルするとき、実行可能ファイルは 最初のソースファイルに基づいて名付けられます。 'go build ed.go rx.go'は'ed'または'ed.exe'を書き込みます。 複数のパッケージをコンパイルするか、単一の非mainパッケージをコンパイルするとき、 buildはパッケージをコンパイルしますが、結果となるオブジェクトは破棄し、 パッケージがビルド可能であることをチェックするだけです。 -oフラグは、buildに結果となる実行可能ファイルまたはオブジェクトを 名前付きの出力ファイルまたはディレクトリに書き込むように強制します、 これは最後の2つの段落で説明されたデフォルトの動作とは異なります。 名前付きの出力が既存のディレクトリであるか、 スラッシュまたはバックスラッシュで終わる場合、結果となる実行可能ファイルは そのディレクトリに書き込まれます。 ビルドフラグは、build、clean、get、install、list、run、 およびtestコマンドで共有されます： -C dir コマンドを実行する前にdirに移動します。 コマンドラインで指定された任意のファイルは、 ディレクトリを変更した後で解釈されます。 使用する場合、このフラグはコマンドラインの最初のものでなければなりません。 -a すでに最新のパッケージの再ビルドを強制します。 -n コマンドを表示しますが、実行はしません。 -p n ビルドコマンドやテストバイナリなどのプログラムが、 並行して実行できる数です。 デフォルトはGOMAXPROCSで、通常は利用可能なCPUの数です。 -race データ競合の検出を有効にします。 linux/amd64、freebsd/amd64、darwin/amd64、darwin/arm64、windows/amd64、 linux/ppc64le、およびlinux/arm64（48ビットVMAのみ）でのみサポートされています。 -msan メモリサニタイザとの相互運用を有効にします。 これはlinux/amd64、linux/arm64、linux/loong64、freebsd/amd64でのみサポートされており、 ホストのCコンパイラとしてClang/LLVMを使用する場合に限ります。 PIEビルドモードはlinux/amd64を除くすべてのプラットフォームで使用されます。 -asan アドレスサニタイザとの相互運用を有効にします。 これはlinux/arm64、linux/amd64、linux/loong64でのみサポートされています。 linux/amd64またはlinux/arm64では、GCC 7以上またはClang/LLVM 9以上でのみサポートされています。 また、linux/loong64ではClang/LLVM 16以上でのみサポートされています。 -cover コードカバレッジ計測を有効にします。 -covermode set,count,atomic カバレッジ分析のモードを設定します。 デフォルトは "set" ですが、-raceが有効になっている場合は "atomic" です。 値： set: bool: このステートメントは実行されますか？ count: int: このステートメントは何回実行されますか？ atomic: int: count、ただしマルチスレッドテストでは正確です。 かなり高価です。 -coverを設定します。 -coverpkg pattern1,pattern2,pattern3 'メイン'パッケージをターゲットとするビルド（つまり、Go実行可能ファイルをビルドする）の場合、 各パターンに一致するパッケージに対してカバレッジ分析を適用します。 デフォルトでは、メインのGoモジュール内のパッケージにカバレッジ分析を適用します。 パッケージパターンの説明については、「go help packages」を参照してください。-coverを設定します。 -v コンパイルされるパッケージの名前を表示します。 -work 一時的な作業ディレクトリの名前を表示し、 終了時にそれを削除しません。 -x コマンドを表示します。 -asmflags '[pattern=]arg list' 各go tool asm呼び出しに渡す引数。 -buildmode mode 使用するビルドモード。詳細については、「go help buildmode」を参照してください。 -buildvcs バイナリにバージョン管理情報をスタンプするかどうか （"true"、"false"、または "auto"）。デフォルト（"auto"）では、メインパッケージ、 それを含むメインモジュール、および現在のディレクトリがすべて同じリポジトリにある場合、 バージョン管理情報がバイナリにスタンプされます。 常にバージョン管理情報を省略するには、-buildvcs=falseを使用します。また、 バージョン管理情報が利用可能であるが、ツールが欠けているかディレクトリ構造が曖昧であるために 含めることができない場合にエラーを出すには、-buildvcs=trueを使用します。 -compiler name 使用するコンパイラの名前、runtime.Compiler（gccgoまたはgc）と同様。 -gccgoflags '[pattern=]arg list' 各gccgoコンパイラ/リンカー呼び出しに渡す引数。 -gcflags '[pattern=]arg list' 各go tool compile呼び出しに渡す引数。 -installsuffix suffix パッケージインストールディレクトリの名前に使用する接尾辞、 デフォルトのビルドから出力を分けて保持するため。 -raceフラグを使用している場合、インストール接尾辞は自動的にraceに設定されます または、明示的に設定されている場合、_raceが追加されます。同様に-msan および-asanフラグについても同様です。デフォルト以外のコンパイル フラグが必要な-buildmodeオプションを使用すると、同様の効果があります。 -ldflags '[pattern=]arg list' 各go tool link呼び出しに渡す引数。 -linkshared -buildmode=sharedで以前に作成された共有ライブラリに対してリンクされるコードをビルドします。 -mod mode 使用するモジュールのダウンロードモード: readonly、vendor、またはmod。 デフォルトでは、vendorディレクトリが存在し、go.modのgoバージョンが1.14以上の場合、 goコマンドは-mod=vendorが設定されているかのように動作します。 それ以外の場合、goコマンドは-mod=readonlyが設定されているかのように動作します。 詳細はhttps://golang.org/ref/mod#build-commandsを参照してください。 -modcacherw モジュールキャッシュ内の新しく作成されたディレクトリを読み取り専用ではなく、 読み書き可能にします。 -modfile file モジュール対応モードでは、モジュールのルートディレクトリにあるものではなく、 代替のgo.modファイルを読み込み（および可能な場合は書き込み）します。 "go.mod"という名前のファイルは、モジュールのルートディレクトリを決定するために 存在していなければなりませんが、アクセスされません。 -modfileが指定されている場合、代替のgo.sumファイルも使用されます。 そのパスは、".mod"拡張子をトリミングして".sum"を追加することで-modfileフラグから派生します。 -overlay file ビルド操作のオーバーレイを提供するJSON設定ファイルを読み込みます。 ファイルは、'Replace'という名前の単一のフィールドを持つJSON構造で、 各ディスクファイルパス（文字列）をそのバッキングファイルパスにマッピングします。 これにより、ビルドはディスクファイルパスがバッキングファイルパスによって与えられた内容で存在するかのように、 またはバッキングファイルパスが空の場合はディスクファイルパスが存在しないかのように実行されます。 -overlayフラグのサポートにはいくつかの制限があります。 重要な点として、インクルードパスの外部から含まれるcgoファイルは、それらが含まれるGoパッケージと同じディレクトリに 存在しなければならず、オーバーレイはgo runおよびgo testを通じて実行されるバイナリとテストには表示されません。 -pgo file プロファイルガイド付き最適化（PGO）のプロファイルのファイルパスを指定します。 特別な名前"auto"が指定された場合、ビルドの各メインパッケージについて、 そのパッケージのディレクトリに"default.pgo"という名前のファイルが存在する場合、 goコマンドはそれを選択し、それをメインパッケージの（トランジティブな）依存関係に適用します （他のパッケージには影響しません）。特別な名前"off"はPGOをオフにします。デフォルトは"auto"です。 -pkgdir dir 通常の場所ではなく、dirからすべてのパッケージをインストールしてロードします。 例えば、非標準の設定でビルドする場合、生成されたパッケージを別の場所に保持するために-pkgdirを使用します。 -tags tag,list ビルド中に満足させるための追加のビルドタグのカンマ区切りリスト。 ビルドタグについての詳細は'go help buildconstraint'を参照してください。 （Goの早いバージョンではスペース区切りのリストを使用していましたが、その形式は非推奨ですがまだ認識されます。） -trimpath 結果の実行可能ファイルからすべてのファイルシステムパスを削除します。 絶対ファイルシステムパスの代わりに、記録されたファイル名はモジュールパス@バージョン（モジュールを使用する場合）で始まるか、 またはプレーンなインポートパス（標準ライブラリ、またはGOPATHを使用する場合）で始まります。 -toolexec 'cmd args' vetやasmのようなツールチェーンプログラムを起動するために使用するプログラム。 例えば、asmを実行する代わりに、goコマンドは'cmd args /path/to/asm <arguments for asm>'を実行します。 TOOLEXEC_IMPORTPATH環境変数が設定され、ビルドされているパッケージの'go list -f {{.ImportPath}}'に一致します。 -asmflags、-gccgoflags、-gcflags、および-ldflagsフラグは、 ビルド中に基礎となるツールに渡すためのスペースで区切られた引数のリストを受け入れます。 リストの要素にスペースを埋め込むには、それをシングルクォートまたはダブルクォートで囲みます。 引数リストは、パッケージパターンと等号によって先行することができ、 それはその引数リストの使用を、そのパターンに一致するパッケージのビルドに制限します （パッケージパターンの説明については'go help packages'を参照してください）。 パターンがない場合、引数リストはコマンドライン上で名前が付けられたパッケージにのみ適用されます。 フラグは、異なるパッケージのセットに対して異なる引数を指定するために、 異なるパターンで繰り返すことができます。 パッケージが複数のフラグで与えられたパターンに一致する場合、 コマンドライン上で最新の一致が勝ちます。 例えば、'go build -gcflags=-S fmt'は、パッケージfmtのみの逆アセンブルを出力しますが、 'go build -gcflags=all=-S fmt'は、fmtとそのすべての依存関係の逆アセンブルを出力します。 パッケージの指定についての詳細は、'go help packages'を参照してください。 パッケージとバイナリがインストールされる場所についての詳細は、 'go help gopath'を実行してください。 GoとC/C++間の呼び出しについての詳細は、'go help c'を実行してください。 注意: Buildは、'go help gopath'で説明されているような特定の規約に従います。 しかし、すべてのプロジェクトがこれらの規約に従うわけではありません。 独自の規約を持つインストールや別のソフトウェアビルドシステムを使用するインストールは、 ビルドツールの一部のオーバーヘッドと設計決定を避けるために、 'go tool compile'や'go tool link'などの低レベルの呼び出しを選択することができます。 参照してください: go install, go get, go clean.

Nmはオブジェクトファイル、アーカイブ、または実行可能ファイルで定義または使用されているシンボルをリストアップします。 使用法: go tool nm [オプション] ファイル..

Objdumpは実行可能ファイルを逆アセンブルします。 使用法： go tool objdump [-s symregexp] binary Objdumpはバイナリのすべてのテキストシンボル（コード）の逆アセンブルを表示します。 -sオプションが指定されている場合、objdumpは正規表現に一致する名前のシンボルのみを逆アセンブルします。 代替の使用法： go tool objdump binary start end このモードでは、objdumpは開始アドレスから終了アドレスまでのバイナリを逆アセンブルします。 開始アドレスと終了アドレスは16進数形式で、オプションの0xプレフィックスを付けて書かれたプログラムカウンタです。 このモードでは、objdumpは次の形式の連続したアドレス範囲の逆アセンブルを出力します： file:line address: assembly address: assembly ..

PprofはGoプログラムのプロファイルを解釈して表示します。 基本的な使用方法: go tool pprof バイナリプロファイル 詳細な使用方法については: go tool pprof -h 具体例については、https://blog.golang.org/profiling-go-programsを参照してください。.

Test2jsonは、go testの出力を機械可読のJSONストリームに変換します。 使用方法: go tool test2json [-p pkg] [-t] [./pkg.test -test.v=test2json] Test2jsonは、指定されたテストコマンドを実行し、その出力をJSONに変換します。 コマンドが指定されていない場合、test2jsonは標準入力からテストの出力を予期します。 対応するJSONイベントのストリームを標準出力に書き込みます。 入出力の不要なバッファリングは行われないため、テストの状態の "ライブ更新" のために JSONストリームを読み取ることができます。 -pフラグは、各テストイベントで報告されるパッケージを設定します。 -tフラグは、各テストイベントにタイムスタンプを追加するようリクエストします。 テストは、-test.v=test2jsonで呼び出す必要があります。-test.vのみを使用することもできます （または -test.v=true）、しかし、より低い信頼性の結果となります。 "go test -json"コマンドはtest2jsonを正しく呼び出すことに対応しているため、 "go tool test2json"は、テストバイナリが"go test"とは別に実行される場合にのみ必要です。 可能な限り"go test -json"を使用してください。 また、test2jsonは単一のテストバイナリの出力を変換するためのものであることに注意してください。 複数のパッケージを実行する"go test"コマンドの出力を変換するには、再び"go test -json"を使用してください。 # 出力フォーマット JSONストリームは、改行で区切られたTestEventオブジェクトのシーケンスで、 Goの構造体に対応します： type TestEvent struct { Time time.Time // RFC3339形式の文字列としてエンコードされます Action string Package string Test string Elapsed float64 // 秒単位 Output string } Timeフィールドはイベントが発生した時刻を保持しています。 キャッシュされたテスト結果には、通常は省略されます。 Actionフィールドは、固定のアクションの説明の1つです： start - テストバイナリが実行される直前 run - テストが実行開始される pause - テストが一時停止される cont - テストが実行再開される pass - テストにパスする bench - ベンチマークがログ出力を行うが、失敗はしない fail - テストまたはベンチマークが失敗する output - テストが出力を行う skip - テストがスキップされるか、パッケージにテストが含まれていない JSONストリームは常に "start" イベントで始まります。 Packageフィールドが存在する場合、テストされているパッケージを指定します。 goコマンドが- jsonモードで並列テストを実行する場合、異なるテストのイベントが交互に現れます。 Packageフィールドにより、読み手はそれらを区別できます。 Testフィールドが存在する場合、イベントを引き起こしたテスト、例、またはベンチマーク関数を指定します。 パッケージ全体のテストの場合、Testは設定されません。 Elapsedフィールドは、"pass"と"fail"のイベントに設定されます。 パスまたは失敗した特定のテストまたはパッケージ全体のテストの経過時間を示します。 OutputフィールドはAction == "output"の場合に設定され、テストの出力の一部です （標準出力と標準エラーを結合したもの）。出力は変更されず、テストからの無効なUTF-8出力は、 置換文字を使用して有効なUTF-8に変換されます。この例外を除いて、 Outputフィールドのすべての出力イベントの連結がテストの実行の正確な出力です。 ベンチマークが実行されると、通常はタイミング結果を示す1行の出力が生成されます。 その行は、Action == "output"かつTestフィールドが存在しないイベントで報告されます。 ベンチマークが出力を記録したり失敗を報告した場合 （たとえば、b.Logやb.Errorを使用することによって）、その追加の出力は ベンチマーク名が設定されたイベントのシーケンスとして報告され、最後のイベントは Action == "bench"または"fail"です。ベンチマークにはAction == "pause"のイベントはありません。.

VetはGoのソースコードを検査し、Printfのような呼び出しがフォーマット文字列と一致しない場合に疑わしい構造を報告します。Vetは完全な報告を保証するわけではないヒューリスティックを使用しているため、すべての報告が本当の問題ではないかもしれませんが、コンパイラでは見つからないエラーを見つけることができます。 Vetは通常、goコマンドを通じて起動されます。 現在のディレクトリのパッケージを検査するためには、以下のコマンドを使用します: go vet パスが指定されたパッケージを検査するためには、以下のコマンドを使用します: go vet my/project/..