delta/go-git.git/misc, branch dev.go2go github.com: golang/go cmd/link: handle types as converted to interface when dynlink 2021-02-26T16:27:08+00:00 Cherry Zhang cherryyz@google.com 2021-02-26T01:01:53+00:00 a655208c9ecd2fee4de6deff35a863b1c28a091c When using plugins, a type (whose value) may be pass to a plugin and get converted to interface there, or vice versa. We need to treat the type as potentially converted to interface, and retain its methods. Should fix #44586. Change-Id: I80dd35e68baedaa852a317543ccd78d94628d13b Reviewed-on: https://go-review.googlesource.com/c/go/+/296709 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> 
When using plugins, a type (whose value) may be pass to a plugin
and get converted to interface there, or vice versa. We need to
treat the type as potentially converted to interface, and retain
its methods.

Should fix #44586.

Change-Id: I80dd35e68baedaa852a317543ccd78d94628d13b
Reviewed-on: https://go-review.googlesource.com/c/go/+/296709
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
all: use more precise build tags 2021-02-23T19:55:03+00:00 Tamir Duberstein tamird@google.com 2020-11-12T22:42:58+00:00 a671e33c6daded6639e0cd97b4791c4468475e71 s/!gccgo/gc/ in files which use gc-syntax assembly. Change-Id: Ifdadb62edd1210ebc70e7cd415648b752afaf067 Reviewed-on: https://go-review.googlesource.com/c/go/+/269957 Reviewed-by: Than McIntosh <thanm@google.com> Trust: David Chase <drchase@google.com> Trust: Matthew Dempsky <mdempsky@google.com> 
s/!gccgo/gc/ in files which use gc-syntax assembly.

Change-Id: Ifdadb62edd1210ebc70e7cd415648b752afaf067
Reviewed-on: https://go-review.googlesource.com/c/go/+/269957
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: David Chase <drchase@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
runtime: unify asmcgocall and systemstack traceback setup 2021-02-19T00:02:06+00:00 Russ Cox rsc@golang.org 2021-02-02T03:58:28+00:00 01f05d8ff1a88c4a63bdaaff5a095a92ce476f58 Both asmcgocall and systemstack need to save the calling Go code's context for use by traceback, but they do it differently. Systemstack's appraoch is better, because it doesn't require a special case in traceback. So make them both use that. While we are here, the fake mstart caller in systemstack is no longer needed and can be removed. (traceback knows to stop in systemstack because of the writes to SP.) Also remove the fake mstarts in sys_windows_*.s. And while we are there, fix the control flow guard code in sys_windows_arm.s. The current code is using pointers to a stack frame that technically is gone once we hit the RET instruction. Clearly it's working OK, but better not to depend on data below SP being preserved, even for just a few instructions. Store the value we need in other registers instead. (This code is only used for pushing a sigpanic call, which does not actually return to the site of the fault and therefore doesn't need to preserve any of the registers.) This CL is part of a stack adding windows/arm64 support (#36439), intended to land in the Go 1.17 cycle. This CL is, however, not windows/arm64-specific. It is cleanup meant to make the port (and future ports) easier. Change-Id: Id1e3ef5e54f7ad786e4b87043f2626eba7c3bbd9 Reviewed-on: https://go-review.googlesource.com/c/go/+/288799 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> 
Both asmcgocall and systemstack need to save the calling Go code's
context for use by traceback, but they do it differently.
Systemstack's appraoch is better, because it doesn't require a
special case in traceback.
So make them both use that.

While we are here, the fake mstart caller in systemstack is
no longer needed and can be removed.
(traceback knows to stop in systemstack because of the writes to SP.)

Also remove the fake mstarts in sys_windows_*.s.

And while we are there, fix the control flow guard code in sys_windows_arm.s.
The current code is using pointers to a stack frame that technically is gone
once we hit the RET instruction. Clearly it's working OK, but better not to depend
on data below SP being preserved, even for just a few instructions.
Store the value we need in other registers instead.
(This code is only used for pushing a sigpanic call, which does not
actually return to the site of the fault and therefore doesn't need to
preserve any of the registers.)

This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.

Change-Id: Id1e3ef5e54f7ad786e4b87043f2626eba7c3bbd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/288799
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
cmd/link: don't decode type symbol in shared library in deadcode 2021-02-02T16:00:58+00:00 Cherry Zhang cherryyz@google.com 2021-02-01T18:36:50+00:00 98f8454a73b569d81d1c5e167d7b68f22e2e3fea In the linker's deadcode pass we decode type symbols for interface satisfaction analysis. When linking against Go shared libraries, the type symbol may come from a shared library, so it doesn't have data in the current module being linked, so we cannot decode it. We already have code to skip DYNIMPORT symbols. However, this doesn't actually work, because at that point the type symbols' names haven't been mangled, whereas they may be mangled in the shared library. So the symbol definition (in shared library) and reference (in current module) haven't been connected. Skip decoding type symbols of type Sxxx (along with DYNIMPORT) when linkShared. Note: we cannot skip all type symbols, as we still need to mark unexported methods defined in the current module. Fixes #44031. Change-Id: I833d19a060c94edbd6fc448172358f9a7d760657 Reviewed-on: https://go-review.googlesource.com/c/go/+/288496 Trust: Cherry Zhang <cherryyz@google.com> Trust: Than McIntosh <thanm@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> 
In the linker's deadcode pass we decode type symbols for
interface satisfaction analysis. When linking against Go shared
libraries, the type symbol may come from a shared library, so it
doesn't have data in the current module being linked, so we cannot
decode it. We already have code to skip DYNIMPORT symbols. However,
this doesn't actually work, because at that point the type symbols'
names haven't been mangled, whereas they may be mangled in the
shared library. So the symbol definition (in shared library) and
reference (in current module) haven't been connected.

Skip decoding type symbols of type Sxxx (along with DYNIMPORT)
when linkShared.

Note: we cannot skip all type symbols, as we still need to mark
unexported methods defined in the current module.

Fixes #44031.

Change-Id: I833d19a060c94edbd6fc448172358f9a7d760657
Reviewed-on: https://go-review.googlesource.com/c/go/+/288496
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
misc/cgo/testcarchive: remove special flags for Darwin/ARM 2020-12-30T22:39:59+00:00 Cherry Zhang cherryyz@google.com 2020-12-30T21:41:58+00:00 ed301733bb228653f98ee9381e90bccf7a3e3bb6 The original Darwin/ARM port is gone. For ARM64, it works fine without the flags on macOS/ARM64. Remove the flags. Change-Id: I9cc00c49dd71376dd9c52abb78c2d8cec656b3db Reviewed-on: https://go-review.googlesource.com/c/go/+/280157 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> 
The original Darwin/ARM port is gone. For ARM64, it works fine
without the flags on macOS/ARM64. Remove the flags.

Change-Id: I9cc00c49dd71376dd9c52abb78c2d8cec656b3db
Reviewed-on: https://go-review.googlesource.com/c/go/+/280157
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
misc/cgo/test: enable TestCrossPackageTests on darwin/arm64 2020-12-30T22:39:48+00:00 Cherry Zhang cherryyz@google.com 2020-12-30T20:49:06+00:00 0ae2e032f2d42575cb64d0759a6d31a71f39412f Somehow I missed that one. It works fine. Change-Id: I0b1286bf1e6a8f40b9f3f114f49b3034079e0b85 Reviewed-on: https://go-review.googlesource.com/c/go/+/280156 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> 
Somehow I missed that one. It works fine.

Change-Id: I0b1286bf1e6a8f40b9f3f114f49b3034079e0b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/280156
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
misc/ios: fix wording for command line instructions 2020-12-29T21:49:26+00:00 Daniel Martí mvdan@mvdan.cc 2020-12-29T21:37:06+00:00 780b4de16b5ba03f2f2ebee35281217552578d50 A typo was made, which I noticed while looking through the recent master commits. Change-Id: Ieed5d6664a1f3ff5892d59abf194963b44ef0e55 Reviewed-on: https://go-review.googlesource.com/c/go/+/280454 Trust: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Cherry Zhang <cherryyz@google.com> 
A typo was made, which I noticed while looking through the recent master
commits.

Change-Id: Ieed5d6664a1f3ff5892d59abf194963b44ef0e55
Reviewed-on: https://go-review.googlesource.com/c/go/+/280454
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
misc/ios: add to README how to build ios executables 2020-12-29T20:34:36+00:00 Cherry Zhang cherryyz@google.com 2020-12-28T19:33:14+00:00 f83e0f6616b58e7c77684c1f1dc6575439fdf79b Updates #43371, #43343. Change-Id: I19386269245f2c20345c6cac7560089b8223e9f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/280153 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> 
Updates #43371, #43343.

Change-Id: I19386269245f2c20345c6cac7560089b8223e9f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/280153
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/compile, runtime: use __msan_memmove for moving data, split msanread to fields 2020-12-03T15:40:11+00:00 Cherry Zhang cherryyz@google.com 2020-11-17T02:28:26+00:00 07cba70d5794747044ce5f2f3b34de139193e2a5 Currently, for data moving, we generate an msanread of the source, followed by an msanwrite of the destination. msanread checks the source is initialized. This has a problem: if the source is an aggregate type containing alignment paddings, the padding bytes may not be thought as initialized by MSAN. If we copy the aggregate type by value, if it counts as a read, MSAN reports using uninitialized data. This CL changes it to use __msan_memmove for data copying, which tells MSAN to propagate initialized-ness but not check for it. Caveat: technically __msan_memmove is not a public API of MSAN, although the C compiler does generate direct calls to it. Also, when instrumenting a load of a struct, split the instrumentation to fields, instead of generating an msanread for the whole struct. This skips padding bytes, which may not be considered initialized in MSAN. Fixes #42820. Change-Id: Id861c8bbfd94cfcccefcc58eaf9e4eb43b4d85c6 Reviewed-on: https://go-review.googlesource.com/c/go/+/270859 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> 
Currently, for data moving, we generate an msanread of the source,
followed by an msanwrite of the destination. msanread checks
the source is initialized.

This has a problem: if the source is an aggregate type containing
alignment paddings, the padding bytes may not be thought as
initialized by MSAN. If we copy the aggregate type by value, if
it counts as a read, MSAN reports using uninitialized data. This
CL changes it to use __msan_memmove for data copying, which tells
MSAN to propagate initialized-ness but not check for it.

Caveat: technically __msan_memmove is not a public API of MSAN,
although the C compiler does generate direct calls to it.

Also, when instrumenting a load of a struct, split the
instrumentation to fields, instead of generating an msanread for
the whole struct. This skips padding bytes, which may not be
considered initialized in MSAN.

Fixes #42820.

Change-Id: Id861c8bbfd94cfcccefcc58eaf9e4eb43b4d85c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/270859
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
cmd/compile: mark plugin-exported types as used in interface 2020-11-13T22:01:37+00:00 Cherry Zhang cherryyz@google.com 2020-11-13T19:42:45+00:00 86954d5246339231dc0c45f5547c37a1c3650264 Plugin exports symbols as interfaces. Mark their types as used in interfaces, so their methods will be kept alive by the linker. Fixes #42579. Change-Id: If1b5aacc21510c20c25f88bb131bca61db6f1d56 Reviewed-on: https://go-review.googlesource.com/c/go/+/269819 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> 
Plugin exports symbols as interfaces. Mark their types as used in
interfaces, so their methods will be kept alive by the linker.

Fixes #42579.

Change-Id: If1b5aacc21510c20c25f88bb131bca61db6f1d56
Reviewed-on: https://go-review.googlesource.com/c/go/+/269819
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>