all: use ":" for compiler generated symbols

As it can't appear in user package paths.

There is a hack for handling "go:buildid" and "type:*" on windows/386.

Previously, windows/386 requires underscore prefix on external symbols,
but that's only applied for SHOSTOBJ/SUNDEFEXT or cgo export symbols.
"go.buildid" is STEXT, "type.*" is STYPE, thus they are not prefixed
with underscore.

In external linking mode, the external linker can't resolve them as
external symbols. But we are lucky that they have "." in their name,
so the external linker see them as Forwarder RVA exports. See:

 - https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#export-address-table
 - https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/pe-dll.c;h=e7b82ba6ffadf74dc1b9ee71dc13d48336941e51;hb=HEAD#l972)

This CL changes "." to ":" in symbols name, so theses symbols can not be
found by external linker anymore. So a hacky way is adding the
underscore prefix for these 2 symbols. I don't have enough knowledge to
verify whether adding the underscore for all STEXT/STYPE symbols are
fine, even if it could be, that would be done in future CL.

Fixes #37762

Change-Id: I92eaaf24c0820926a36e0530fdb07b07af1fcc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/317917
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>

2 files changed, 9 insertions, 9 deletions

diff --git a/test/codegen/strings.go b/test/codegen/strings.go
index 19e1dbda51..08425a418a 100644
--- a/test/codegen/strings.go
+++ b/test/codegen/strings.go
@@ -15,7 +15,7 @@ func CountRunes(s string) int { // Issue #24923
 }
 
 func ToByteSlice() []byte { // Issue #24698
-	// amd64:`LEAQ\ttype\.\[3\]uint8`
+	// amd64:`LEAQ\ttype:\[3\]uint8`
 	// amd64:`CALL\truntime\.newobject`
 	// amd64:-`.*runtime.stringtoslicebyte`
 	return []byte("foo")
diff --git a/test/fixedbugs/issue29312.go b/test/fixedbugs/issue29312.go
index 4293e01004..cbf79f704c 100644
--- a/test/fixedbugs/issue29312.go
+++ b/test/fixedbugs/issue29312.go
@@ -22,14 +22,14 @@
 // The type names for these types are as follows. Because we truncate
 // the name at depth 250, the last few names are all identical:
 //
-//     type.[]*"".pwn
-//     type.[][]*"".pwn
+//     type:[]*"".pwn
+//     type:[][]*"".pwn
 //     ...
-//     type.[][]...[][]*pwn       - 249 total "[]"
-//     type.[][]...[][][]*<...>   - 250 total "[]"
-//     type.[][]...[][][][]<...>  - 251 total "[]"
-//     type.[][]...[][][][]<...>  - 252 total "[]" (but only 251 "[]" in the name)
-//     type.[][]...[][][][]<...>  - 253 total "[]" (but only 251 "[]" in the name)
+//     type:[][]...[][]*pwn       - 249 total "[]"
+//     type:[][]...[][][]*<...>   - 250 total "[]"
+//     type:[][]...[][][][]<...>  - 251 total "[]"
+//     type:[][]...[][][][]<...>  - 252 total "[]" (but only 251 "[]" in the name)
+//     type:[][]...[][][][]<...>  - 253 total "[]" (but only 251 "[]" in the name)
 //
 // Because the names of the last 3 types are all identical, the
 // compiler will generate only a single runtime.slicetype data
@@ -37,7 +37,7 @@
 // generates just the 251-entry one. There aren't any
 // runtime.slicetypes generated for the final two types.
 //
-// The compiler passes type.[]...[]<...> (251 total "[]") to
+// The compiler passes type:[]...[]<...> (251 total "[]") to
 // fmt.Sprintf (instead of the correct 253 one). But the data
 // structure at runtime actually has 253 nesting levels. So we end up
 // calling String on something that is of type [][]*pwn instead of