This provides the runtime glue (_rt0_riscv64_linux_lib) for c-archive and c-shared
support, along with enabling both of these buildmodes on linux/riscv64.
Both misc/cgo/testcarchive and misc/cgo/testcshared now pass on this platform.
Fixes#47100
Change-Id: I7ad75b23ae1d592dbac60d15bba557668287711f
Reviewed-on: https://go-review.googlesource.com/c/go/+/334872
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fixes#49288
Change-Id: I7bfcbecbefa68871a3e556935a73f241fff44c0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360861
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add asan tests to check the use of Go with -asan option.
Currenly, the address sanitizer in Go only checks for error
memory access to heap objects.
TODO: Enable check for error memory access to global objects.
Updates #44853.
Change-Id: I83579f229f117b5684a369fc8f365f4dea140648
Reviewed-on: https://go-review.googlesource.com/c/go/+/298615
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts CL 359096.
Updates #47788.
Reason for revert: -buildmode=shared may have actually been working in a few very specific cases. We should not remove -buildmode=shared until we have implemented an alternative to support those few cases.
Change-Id: Ia962b06abacc11f6f29fc29d092773be175e32f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/359575
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It never worked in module mode (or with a read-only GOROOT).
A proposal to drop it was filed (and approved) in
https://golang.org/issue/47788.
Fixes#47788
Change-Id: I0c12f38eb0c5dfe9384fbdb49ed202301fa4273d
Reviewed-on: https://go-review.googlesource.com/c/go/+/359096
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When build with "-linkshared", we can't tell if the interface method will be used or not. It can be used in shared library.
Fixes#47873
Change-Id: Iba12812f199b7679cf2fd41a304268d6d6dd03c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/350189
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Allows cgo to work with generics.
Updates #47781.
Change-Id: Id1a5d1a0a8193c5b157e3e671b1490d687d10384
Reviewed-on: https://go-review.googlesource.com/c/go/+/353882
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Many uses of Index/IndexByte/IndexRune/Split/SplitN
can be written more clearly using the new Cut functions.
Do that. Also rewrite to other functions if that's clearer.
For #46336.
Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448
Reviewed-on: https://go-review.googlesource.com/c/go/+/351711
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#48396
Change-Id: Idd7cb66536ef513806c472d394a929bc271fc26b
Reviewed-on: https://go-review.googlesource.com/c/go/+/350159
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Applying -Werror compiler option to request warnings is an usual
way to discover potential errors. Go user may put a cgo directive
in preamble: `// #cgo CFLAGS: -Werror=unused-parameter`.
However, the directive also takes effect on the cgo generated files.
I cleaned _cgo_main.c to help Go user only concentrate on warnings
of their own file.
Fixes#43639
Change-Id: I9112f02ae5226f2fc87a8650d19faee59cddd588
GitHub-Last-Rev: f09d172f97
GitHub-Pull-Request: golang/go#46358
Reviewed-on: https://go-review.googlesource.com/c/go/+/322232
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
CL 294430 made packages in std and cmd modules use Go 1.17 gofmt format,
adding //go:build lines. This change applies the same formatting to some
more packages that 'go fmt' missed (e.g., syscall/js, runtime/msan), and
everything else that is easy and safe to modify in bulk.
Consider the top-level test directory, testdata, and vendor directories
out of scope, since there are many files that don't follow strict gofmt
formatting, often for intentional and legitimate reasons (testing gofmt
itself, invalid Go programs that shouldn't crash the compiler, etc.).
That makes it easy and safe to gofmt -w the .go files that are found
with gofmt -l with aforementioned directories filtered out:
$ gofmt -l . 2>/dev/null | \
grep -v '^test/' | \
grep -v '/testdata/' | \
grep -v '/vendor/' | wc -l
51
None of the 51 files are generated. After this change, the same command
prints 0.
For #41184.
Change-Id: Ia96ee2a0f998d6a167d4473bcad17ad09bc1d86e
Reviewed-on: https://go-review.googlesource.com/c/go/+/341009
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Conflicts:
- src/go/types/check_test.go
CL 324730 on dev.typeparams changed the directory paths in TestCheck,
TestExamples, and TestFixedbugs and renamed checkFiles to testFiles;
whereas CL 337529 on master added a new test case just above them and
that used checkFiles.
Merge List:
+ 2021-08-12 46fd547d89 internal/goversion: update Version to 1.18
+ 2021-08-12 5805efc78e doc/go1.17: remove draft notice
+ 2021-08-12 39634e7dae CONTRIBUTORS: update for the Go 1.17 release
+ 2021-08-12 095bb790e1 os/exec: re-enable LookPathTest/16
+ 2021-08-11 dea23e9ca8 src/make.*: make --no-clean flag a no-op that prints a warning
+ 2021-08-11 d4c0ed26ac doc/go1.17: linker passes -I to extld as -Wl,--dynamic-linker
+ 2021-08-10 1f9c9d8530 doc: use "high address/low address" instead of "top/bottom"
+ 2021-08-09 f1dce319ff cmd/go: with -mod=vendor, don't panic if there are duplicate requirements
+ 2021-08-09 7aeaad5c86 runtime/cgo: when using msan explicitly unpoison cgoCallers
+ 2021-08-08 507cc341ec doc: add example for conversion from slice expressions to array ptr
+ 2021-08-07 891547e2d4 doc/go1.17: fix a typo introduced in CL 335135
+ 2021-08-06 8eaf4d16bc make.bash: do not overwrite GO_LDSO if already set
+ 2021-08-06 63b968f4f8 doc/go1.17: clarify Modules changes
+ 2021-08-06 70546f6404 runtime: allow arm64 SEH to be called if illegal instruction
+ 2021-08-05 fd45e267c2 runtime: warn that KeepAlive is not an unsafe.Pointer workaround
+ 2021-08-04 6e738868a7 net/http: speed up and deflake TestCancelRequestWhenSharingConnection
+ 2021-08-02 8a7ee4c51e io/fs: don't use absolute path in DirEntry.Name doc
+ 2021-07-31 b8ca6e59ed all: gofmt
+ 2021-07-30 b7a85e0003 net/http/httputil: close incoming ReverseProxy request body
+ 2021-07-29 70fd4e47d7 runtime: avoid possible preemption when returning from Go to C
+ 2021-07-28 9eee0ed439 cmd/go: fix go.mod file name printed in error messages for replacements
+ 2021-07-28 b39e0f461c runtime: don't crash on nil pointers in checkptrAlignment
+ 2021-07-27 7cd10c1149 cmd/go: use .mod instead of .zip to determine if version has go.mod file
+ 2021-07-27 c8cf0f74e4 cmd/go: add missing flag in UsageLine
+ 2021-07-27 7ba8e796c9 testing: clarify T.Name returns a distinct name of the running test
+ 2021-07-27 33ff155970 go/types: preserve untyped constants on the RHS of a shift expression
+ 2021-07-26 840e583ff3 runtime: correct variable name in comment
+ 2021-07-26 bfbb288574 runtime: remove adjustTimers counter
+ 2021-07-26 9c81fd53b3 cmd/vet: add missing copyright header
Change-Id: Ia80604d24c6f4205265683024e3100769cf32065
This avoids an incorrect msan uninitialized memory report when using
runtime.SetCgoTraceback when a signal occurs while the fifth argument
register is undefined. See the issue for more details.
Fixes#47543
Change-Id: I3d1b673e2c93471ccdae0171a99b88b5a6062840
Reviewed-on: https://go-review.googlesource.com/c/go/+/339902
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Setting `-gcflags=all=-d=unified` works for normal builds/tests, but
seems to have trouble with the test/run.go regress tests. So add a
GOEXPERIMENT knob to allow another way to turn on unified IR
construction, which plays better with all.bash.
While here, update two existing test expectations that currently fail
during GOEXPERIMENT=unified ./all.bash:
1. misc/cgo/errors/testdata/err2.go is testing column positions, and
types2 gets one case slightly better, and another case slightly
worse. For now, the test case is updated to accept both.
2. fixedbugs/issue42284.go is added to the list of known failures,
because it fails for unified IR. (It's an escape analysis test, and
escape analysis is working as expected; but unified is formatting an
imported constant value differently than the test's regexp expects.)
Updates #46786.
Change-Id: I40a4a70fa1b85ac87fcc85a43687f5d81e011ec0
Reviewed-on: https://go-review.googlesource.com/c/go/+/328215
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LLD won't import a .dll directly and instead requires an import library.
So generate these using -out-implib, the same way as was done in CL
312046, where it makes sense, and elsewhere build the import library
using a def file. We can't use -out-implib all the time, because the
output file gets overwritten each time the linker is called, rather than
merged.
Updates #46502.
Change-Id: Iefe54cb6c576004b83b1039ba673881b8640423d
Reviewed-on: https://go-review.googlesource.com/c/go/+/327211
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Clang does not produce binaries with an .edata section, even when it
exports symbols properly, so just skip this binutils-specific test for
that case. Later we can rewrite these tests entirely to do something
more robust.
Updates #46719.
Change-Id: I864b3c2d91e66800c55454ae11d4ab1623693d14
Reviewed-on: https://go-review.googlesource.com/c/go/+/327549
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test was using the wrong column numbers, and was erroneously
passing because there happened to be line numbers that matched those
column numbers. Change the test harness to require the expected line
number for the ERROR HERE regexp case, so that this doesn't happen again.
Also rename a couple of variables in the test to avoid useless
redeclaration errors.
Fixes#46534
Change-Id: I2fcbf5e379c346de5346035c73d174a3980c0927
Reviewed-on: https://go-review.googlesource.com/c/go/+/324970
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This test is known to be broken on the darwin/arm64 builder.
Skip it while it's being investigated so it doesn't mask other failures.
For #46239.
Updates #43228.
Change-Id: I8fe57a0636bba84c3100337146dcb96cc264e524
Reviewed-on: https://go-review.googlesource.com/c/go/+/321349
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The test previously had the hardcoded assumption that /proc/self/status
files had "Groups:" lines containing numerical IDs in ascending order.
Because of the possibility of non-monotonic ordering of GIDs in user
namespaces, this assumption was not universally true for all
/proc/self/gid_map setups.
To ensure this test can pass in those setups, sanity check failed
"Groups:" line matches with a string sorted version of the expected
values. (For the test cases here, numerical and string sorted order
are guaranteed to match.)
Fixes#46145
Change-Id: Ia060e80b123604bc394a15c02582fc406f944d36
Reviewed-on: https://go-review.googlesource.com/c/go/+/319591
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Some uses of crosscall2 did not work on ppc64le and probably
aix-ppc64. In particular, if there was a main program compiled
with -buildmode=pie and used a plugin which invoked crosscall2,
then failures could occur due to R2 getting set incorrectly along the
way. The problem was due to R2 being saved on the caller's
stack; it is now saved on the crosscall2 stack. More details can be
found in the issue.
This adds a testcase where the main program is built with pie
and the plugin invokes crosscall2.
This also changes the save of the CR bits from MOVD to MOVW as
it should be.
Fixes#43228
Change-Id: Ib5673e25a2ec5ee46bf9a1ffb0cb1f3ef5449086
Reviewed-on: https://go-review.googlesource.com/c/go/+/319489
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Heschi Kreinick <heschi@google.com>
At least in mingw-clang it is not permitted to just name a .dll
on the command line. You must name the corresponding import
library instead, even though the dll is used when the executable
is run.
This fixes misc/cgo/testso and misc/cgo/testsovar on windows/arm64.
Change-Id: I516b6ccba2fe3a9ee2c01e710a71850c4df8522f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312046
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
An exported Go function like
//export F
func F() {}
gets declared in _cgo_export.h as something like
extern void F(void);
The exact declaration varies by operating system.
In particular, Windows adds __declspec(dllimport).
Clang on Windows/ARM64 rejects code that contains
conflicting declarations for F, like:
extern void F(void);
extern void __declspec(dllimport) F(void);
This means that F must not be declared separately from _cgo_export.h:
any code that wants to refer to F must use #include "_cgo_export.h".
Unfortunately, the cgo prologue itself (the commented code before import "C")
cannot include "_cgo_export.h", because that file is itself produced from the
cgo Go sources and therefore cannot be a dependency of the cgo Go sources.
This CL rewrites misc/cgo/test to avoid redeclaring exported functions.
Most of the time, this is not a significant problem: just move the code
that needs the header into a .c file, perhaps with a wrapper exposed
to the cgo Go sources.
The one case that is potentially problematic is f7665, which is part of
the test for golang.org/issue/7665. That bug report explicitly identified
a bug in referring to the C name for an exported function in the same
Go source file as it was exported function. That is now impossible,
at least on Windows/ARM64, so the test is modified a bit and possibly
does not test what the original bug was. But the original bug should
be long gone: that part of the compiler has been rewritten.
Change-Id: I0d14d9336632f0e5e3db4273d9d32ef2cca0298d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312029
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
tests that run commands should log their actions in a
shell-pasteable way.
Change-Id: Ifeee88397047ef5a76925c5f30c213e83e535038
Reviewed-on: https://go-review.googlesource.com/c/go/+/309770
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This follows the spelling choices that the Go project has made for English words.
https://github.com/golang/go/wiki/Spelling
Change-Id: Ie7c586d2cf23020cb492cfff58c0831d2d8d3a78
GitHub-Last-Rev: e16a32cd22
GitHub-Pull-Request: golang/go#45442
Reviewed-on: https://go-review.googlesource.com/c/go/+/308291
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
For #42076Fixes#45451
Change-Id: I69646226d3480d5403205412ddd13c0cfc2c8a53
Reviewed-on: https://go-review.googlesource.com/c/go/+/308970
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
A non-trivial Cgo program may need to use callbacks and interact with
go objects per goroutine. Because of the rules for passing pointers
between Go and C, such a program needs to store handles to associated
Go values. This often causes much extra effort to figure out a way to
correctly deal with: 1) map collision; 2) identifying leaks and 3)
concurrency.
This CL implements a Handle representation in runtime/cgo package, and
related methods such as Value, Delete, etc. which allows Go users can
use a standard way to handle the above difficulties.
In addition, the CL allows a Go value to have multiple handles, and the
NewHandle always returns a different handle compare to the previously
returned handles. In comparison, CL 294670 implements a different
behavior of NewHandle that returns a unique handle when the Go value is
referring to the same object.
Benchmark:
name time/op
Handle/non-concurrent-16 487ns ± 1%
Handle/concurrent-16 674ns ± 1%
Fixes#37033
Change-Id: I0eadb9d44332fffef8fb567c745246a49dd6d4c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/295369
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Pass information about original end position for c function arguments
processed in pointer checking generated code.
Fixes#42580
Change-Id: Ic8a578168362f0ca6055064dbbea092ad37477a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/269760
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Update references missed in CL 263142.
For #41190
Change-Id: I778760a6a69bd0440fec0848bdef539c9ccb4ee1
GitHub-Last-Rev: dda42b09ff
GitHub-Pull-Request: golang/go#42874
Reviewed-on: https://go-review.googlesource.com/c/go/+/273946
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Static tmps are private to a package, but with plugins a package
can be shared among multiple DSOs. They need to have a consistent
view of the static tmps, especially for writable ones. So export
them. (Read-only static tmps have the same values anyway, so it
doesn't matter. Also Mach-O doesn't support dynamically exporting
read-only symbols anyway.)
Fixes#44956.
Change-Id: I921e25b7ab73cd5d5347800eccdb7931e3448779
Reviewed-on: https://go-review.googlesource.com/c/go/+/301793
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>
For https://gcc.gnu.org/PR99553
Change-Id: I29a7fbfd89963d4139bc19af99330d70567938ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/300993
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Currently, the cmd/dist runs test cases in misc/cgo/testsantizers only
when memeory sanitizer is supported, but the tsan tests in
misc/cgo/testsanitizers do not require support for -msan option, which
makes tsan tests can not be run on some unsupported -msan option platforms.
Therefore, this patch moves the test constraints from cmd/dist to
msan_test.go, so that the tsan tests in misc/cgo/testsanitizers
can be run on any system where the C compiler supports -fsanitize=thread
option.
Change-Id: I779c92eedd0270050f1a0b1a69ecce50c3712bc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/297774
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
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>
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>
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>
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>
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>
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>
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>
CL 258938 changed the way C to Go calls work such that they now
construct a C struct on the C side for the arguments and space for the
results. Any pointers in the result space must be zeroed, so we just
zero the whole struct.
However, C makes it surprisingly hard to robustly zero any struct
type. We had used a "{0}" initializer, which works in the vast
majority of cases, but fails if the type is empty or effectively
empty.
This CL fixes this by changing how the cgo tool zero-initializes the
argument struct to be more robust.
Fixes#42495.
Change-Id: Id1749b9d751e59eb7a02a9d44fec0698a2bf63cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/269337
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A hand-edited object file can have a symbol name that uses newline and
other normally invalid characters. The cgo tool will generate Go files
containing symbol names, unquoted. That can permit those symbol names
to inject Go code into a cgo-generated file. If that Go code uses the
//go:cgo_ldflag pragma, it can cause the C linker to run arbitrary
code when building a package. If you build an imported package we
permit arbitrary code at run time, but we don't want to permit it at
package build time. This CL prevents this in two ways.
In cgo, reject invalid symbols that contain non-printable or space
characters, or that contain anything that looks like a Go comment.
In the go tool, double check all //go:cgo_ldflag directives in
generated code, to make sure they follow the existing LDFLAG restrictions.
Thanks to Imre Rad / https://www.linkedin.com/in/imre-rad-2358749b for
reporting this.
Fixes CVE-2020-28367
Change-Id: Ia1ad8f3791ea79612690fa7d26ac451d0f6df7c1
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/895832
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/269658
Trust: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TestSetuidEtc() was failing sporadically on linux-ppc64. From the
three https://build.golang.org/ logs, it looked like the logged
errors could be associated with threads dying, but proc reads
were, in some way, racing with their demise.
Exploring ways to increase thread demise, revealed that races
of this type can happen on non-ppc64 systems, and that
os.IsNotExist(err) was not a sufficient error condition test
for a thread's status file disappearing. This change includes a
fix for that to.
The actual issue on linux-ppc64 appears to be tied to PID reaping
and reuse latency on whatever the build test environment is for
linux-ppc64-buildlet. I suspect this can happen on any linux
system, however, especially where the container has a limited PID
range.
The fix for this, limited to the test (the runtime syscall support
is unchanged), is to confirm that the Pid for the interrogated
thread's /proc/<TID>/status file confirms that it is still
associated with the test-process' PID.
linux-ppc64-buildlet:
go/bin/go test syscall -run=TestSetuidEtc -count=10000
ok syscall 104.285s
Fixes#42462
Change-Id: I55c84ab8361003570a405fa52ffec4949bf91113
Reviewed-on: https://go-review.googlesource.com/c/go/+/268717
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Fixes#36641
Change-Id: I51868d83ce341d78d33b221d184c5a5110c60d14
Reviewed-on: https://go-review.googlesource.com/c/go/+/263598
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Allocate a C enum object, and test if it can be assigned a value
successfully.
For #39537
Change-Id: I7b5482112486440b9d99f2ee4051328d87f45dca
GitHub-Last-Rev: 81890f40ac
GitHub-Pull-Request: golang/go#39977
Reviewed-on: https://go-review.googlesource.com/c/go/+/240697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This redesigns the way calls work from C to exported Go functions. It
removes several steps from the call path, makes cmd/cgo no longer
sensitive to the Go calling convention, and eliminates the use of
reflectcall from cgo.
In order to avoid generating a large amount of FFI glue between the C
and Go ABIs, the cgo tool has long depended on generating a C function
that marshals the arguments into a struct, and then the actual ABI
switch happens in functions with fixed signatures that simply take a
pointer to this struct. In a way, this CL simply pushes this idea
further.
Currently, the cgo tool generates this argument struct in the exact
layout of the Go stack frame and depends on reflectcall to unpack it
into the appropriate Go call (even though it's actually
reflectcall'ing a function generated by cgo).
In this CL, we decouple this struct from the Go stack layout. Instead,
cgo generates a Go function that takes the struct, unpacks it, and
calls the exported function. Since this generated function has a
generic signature (like the rest of the call path), we don't need
reflectcall and can instead depend on the Go compiler itself to
implement the call to the exported Go function.
One complication is that syscall.NewCallback on Windows, which
converts a Go function into a C function pointer, depends on
cgocallback's current dynamic calling approach since the signatures of
the callbacks aren't known statically. For this specific case, we
continue to depend on reflectcall. Really, the current approach makes
some overly simplistic assumptions about translating the C ABI to the
Go ABI. Now we're at least in a much better position to do a proper
ABI translation.
For comparison, the current cgo call path looks like:
GoF (generated C function) ->
crosscall2 (in cgo/asm_*.s) ->
_cgoexp_GoF (generated Go function) ->
cgocallback (in asm_*.s) ->
cgocallback_gofunc (in asm_*.s) ->
cgocallbackg (in cgocall.go) ->
cgocallbackg1 (in cgocall.go) ->
reflectcall (in asm_*.s) ->
_cgoexpwrap_GoF (generated Go function) ->
p.GoF
Now the call path looks like:
GoF (generated C function) ->
crosscall2 (in cgo/asm_*.s) ->
cgocallback (in asm_*.s) ->
cgocallbackg (in cgocall.go) ->
cgocallbackg1 (in cgocall.go) ->
_cgoexp_GoF (generated Go function) ->
p.GoF
Notably:
1. We combine _cgoexp_GoF and _cgoexpwrap_GoF and move the combined
operation to the end of the sequence. This combined function also
handles reflectcall's previous role.
2. We combined cgocallback and cgocallback_gofunc since the only
purpose of having both was to convert a raw PC into a Go function
value. We instead construct the Go function value in cgocallbackg1.
3. cgocallbackg1 no longer reaches backwards through the stack to get
the arguments to cgocallback_gofunc. Instead, we just pass the
arguments down.
4. Currently, we need an explicit msanwrite to mark the results struct
as written because reflectcall doesn't do this. Now, the results are
written by regular Go assignments, so the Go compiler generates the
necessary MSAN annotations. This also means we no longer need to track
the size of the arguments frame.
Updates #40724, since now we don't need to teach cgo about the
register ABI or change how it uses reflectcall.
Change-Id: I7840489a2597962aeb670e0c1798a16a7359c94f
Reviewed-on: https://go-review.googlesource.com/c/go/+/258938
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
