cmd/cgo, cmd/ld: new cgo object file section

Switch to new pragma names, but leave old ones available for now.
Merge the three cgo-related sections in the .6 files into a single
cgo section.

R=golang-dev, iant, ality
CC=golang-dev
https://codereview.appspot.com/7424048

1 files changed, 17 insertions, 18 deletions

diff --git a/src/cmd/cgo/doc.go b/src/cmd/cgo/doc.go
index 334ceefc9..955b7c495 100644
--- a/src/cmd/cgo/doc.go
+++ b/src/cmd/cgo/doc.go
@@ -343,13 +343,13 @@ cgo examine the executable. Cgo records the list of shared library
 references and resolved names and writes them into a new file
 _cgo_import.c, which looks like:
 
-	#pragma dynlinker "/lib64/ld-linux-x86-64.so.2"
-	#pragma dynimport puts puts#GLIBC_2.2.5 "libc.so.6"
-	#pragma dynimport __libc_start_main __libc_start_main#GLIBC_2.2.5 "libc.so.6"
-	#pragma dynimport stdout stdout#GLIBC_2.2.5 "libc.so.6"
-	#pragma dynimport fflush fflush#GLIBC_2.2.5 "libc.so.6"
-	#pragma dynimport _ _ "libpthread.so.0"
-	#pragma dynimport _ _ "libc.so.6"
+	#pragma cgo_dynamic_linker "/lib64/ld-linux-x86-64.so.2"
+	#pragma cgo_import_dynamic puts puts#GLIBC_2.2.5 "libc.so.6"
+	#pragma cgo_import_dynamic __libc_start_main __libc_start_main#GLIBC_2.2.5 "libc.so.6"
+	#pragma cgo_import_dynamic stdout stdout#GLIBC_2.2.5 "libc.so.6"
+	#pragma cgo_import_dynamic fflush fflush#GLIBC_2.2.5 "libc.so.6"
+	#pragma cgo_import_dynamic _ _ "libpthread.so.0"
+	#pragma cgo_import_dynamic _ _ "libc.so.6"
 
 In the end, the compiled Go package, which will eventually be
 presented to 6l as part of a larger program, contains:
@@ -448,7 +448,7 @@ and then processed by the linker.
 
 The directives are:
 
-#pragma cgo_dynamic_import <local> [<remote> ["<library>"]]
+#pragma cgo_import_dynamic <local> [<remote> ["<library>"]]
 
 	In internal linking mode, allow an unresolved reference to
 	<local>, assuming it will be resolved by a dynamic library
@@ -459,9 +459,9 @@ The directives are:
 	In the <remote>, # or @ can be used to introduce a symbol version.
 
 	Examples:
-	#pragma cgo_dynamic_import puts
-	#pragma cgo_dynamic_import puts puts#GLIBC_2.2.5
-	#pragma cgo_dynamic_import puts puts#GLIBC_2.2.5 "libc.so.6"
+	#pragma cgo_import_dynamic puts
+	#pragma cgo_import_dynamic puts puts#GLIBC_2.2.5
+	#pragma cgo_import_dynamic puts puts#GLIBC_2.2.5 "libc.so.6"
 
 	A side effect of the cgo_dynamic_import directive with a
 	library is to make the final binary depend on that dynamic
@@ -469,7 +469,7 @@ The directives are:
 	symbols, use _ for local and remote.
 
 	Example:
-	#pragma cgo_dynamic_import _ _ "libc.so.6"
+	#pragma cgo_import_dynamic _ _ "libc.so.6"
 
 	For compatibility with current versions of SWIG,
 	#pragma dynimport is an alias for #pragma cgo_dynamic_import.
@@ -495,7 +495,7 @@ The directives are:
 	For compatibility with current versions of SWIG,
 	#pragma dynexport is an alias for #pragma cgo_export.
 
-#pragma cgo_static_import <local>
+#pragma cgo_import_static <local>
 
 	In external linking mode, allow unresolved references to
 	<local> in the go.o object file prepared for the host linker,
@@ -503,7 +503,7 @@ The directives are:
 	other object files that will be linked with go.o.
 
 	Example:
-	#pragma cgo_static_import puts_wrapper
+	#pragma cgo_import_static puts_wrapper
 
 #pragma cgo_ldflag "<arg>"
 
@@ -531,10 +531,9 @@ The following code will be generated by cgo:
 
 	// compiled by 6c
 
-	#pragma cgo_dynamic_import sin sin#GLIBC_2.2.5 "libm.so.6"
-	#pragma cgo_dynamic_linker "/lib/ld-linux.so.2"
+	#pragma cgo_import_dynamic sin sin#GLIBC_2.2.5 "libm.so.6"
 
-	#pragma cgo_static_import _cgo_gcc_Cfunc_sin
+	#pragma cgo_import_static _cgo_gcc_Cfunc_sin
 	#pragma cgo_ldflag "-lm"
 
 	void _cgo_gcc_Cfunc_sin(void*);
@@ -578,7 +577,7 @@ particular foo.cgo2.o. It links together the 6g- and 6c-generated
 object files, along with any other Go code, into a go.o file. While
 doing that, 6l will discover that there is no definition for
 _cgo_gcc_Cfunc_sin, referred to by the 6c-compiled source file. This
-is okay, because 6l also processes the cgo_static_import directive and
+is okay, because 6l also processes the cgo_import_static directive and
 knows that _cgo_gcc_Cfunc_sin is expected to be supplied by a host
 object file, so 6l does not treat the missing symbol as an error when
 creating go.o. Indeed, the definition for _cgo_gcc_Cfunc_sin will be