summaryrefslogtreecommitdiff
path: root/misc/cgo/test
Commit message (Collapse)AuthorAgeFilesLines
* misc/cgo: move registerCgoTests tests to cmd/cgo/internalAustin Clements2023-05-12124-7846/+0
| | | | | | | | | | | | | | This moves the remaining cgo tests. For #37486. Change-Id: I99dea5a312a1974de338461a8b02242e5c1bae62 Reviewed-on: https://go-review.googlesource.com/c/go/+/492721 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
* misc/cgo/test: add cgo build constraintsAustin Clements2023-05-1220-7/+39
| | | | | | | | | | | | | | | | | | | | | | | We're about to move this package to cmd/cgo/internal, where it will get caught up in the "CGO_ENABLED=0 go install cmd" done by make.bash. Currently, building this package with CGO_ENABLED=0 fails because it contains several source files that don't themselves import "C", but do import a subdirectory where that package imports "C" and thus has no exported API. Fix the CGO_ENABLED=0 build of this package by adding the necessary cgo build tags. Not all source files need it, but this CL makes "CGO_ENABLED=0 go test -c" work in this package. For #37486. Change-Id: Id137cdfbdd950eea802413536d990ab642ebcd7e Reviewed-on: https://go-review.googlesource.com/c/go/+/493215 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Austin Clements <austin@google.com>
* misc/cgo/test: fix vet errorAustin Clements2023-05-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Vet's cgocall check fails on misc/cgo/test with "possibly passing Go type with embedded pointer to C". This error is confusing, but the cgocall check is looking for passing pointers to Go slices to C, which is exactly what this test is doing. Normally we don't notice this because vet doesn't run on misc, but we're about to move this test to cmd/cgo/internal, where vet will start failing. I'm not sure why we're passing a pointer to a slice here. It's important that we call a C function with an unsafe.Pointer to memory containing a pointer to test #25941 and that the result is this call is then passed to another C function for #28540. This CL maintains these two properties without the use of a slice. For #37486. Change-Id: I672a3c35931a59f99363050498d6f0c80fb6cd98 Reviewed-on: https://go-review.googlesource.com/c/go/+/493137 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
* Revert "runtime/cgo: store M for C-created thread in pthread key"Chressie Himpel2023-05-054-64/+3
| | | | | | | | | | | | This reverts CL 485500. Reason for revert: This breaks internal tests at Google, see b/280861579 and b/280820455. Change-Id: I426278d400f7611170918fc07c524cb059b9cc55 Reviewed-on: https://go-review.googlesource.com/c/go/+/492995 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Chressie Himpel <chressie@google.com>
* runtime/cgo: store M for C-created thread in pthread keyMichael Pratt2023-04-264-3/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies CL 481061, with the followup fixes in CL 482975, CL 485315, and CL 485316 incorporated. CL 481061, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 482975 is a followup fix to a C declaration in testprogcgo. CL 485315 is a followup fix for x_cgo_getstackbound on Illumos. CL 485316 is a followup cleanup for ppc64 assembly. [Original CL 481061 description] This reapplies CL 392854, with the followup fixes in CL 479255, CL 479915, and CL 481057 incorporated. CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 479255 is a followup fix for a small bug in ARM assembly code. CL 479915 is another followup fix to address C to Go calls after the C code uses some stack, but that CL is also buggy. CL 481057, by Michael Knyszek, is a followup fix for a memory leak bug of CL 479915. [Original CL 392854 description] In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls. So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call. Instead, we only dropm while the C thread exits, so the extra M won't leak. When invoking a Go function from C: Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor. And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits. When returning back to C: Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C. This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows. This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread. For the newly added BenchmarkCGoInCThread, some benchmark results: 1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz [CL 479915 description] Currently, when C calls into Go the first time, we grab an M using needm, which sets m.g0's stack bounds using the SP. We don't know how big the stack is, so we simply assume 32K. Previously, when the Go function returns to C, we drop the M, and the next time C calls into Go, we put a new stack bound on the g0 based on the current SP. After CL 392854, we don't drop the M, and the next time C calls into Go, we reuse the same g0, without recomputing the stack bounds. If the C code uses quite a bit of stack space before calling into Go, the SP may be well below the 32K stack bound we assumed, so the runtime thinks the g0 stack overflows. This CL makes needm get a more accurate stack bound from pthread. (In some platforms this may still be a guess as we don't know exactly where we are in the C stack), but it is probably better than simply assuming 32K. [CL 485500 description] CL 479915 passed the G to _cgo_getstackbound for direct updates to gp.stack.lo. A G can be reused on a new thread after the previous thread exited. This could trigger the C TSAN race detector because it couldn't see the synchronization in Go (lockextra) preventing the same G from being used on multiple threads at the same time. We work around this by passing the address of a stack variable to _cgo_getstackbound rather than the G. The stack is generally unique per thread, so TSAN won't see the same address from multiple threads. Even if stacks are reused across threads by pthread, C TSAN should see the synchonization in the stack allocator. A regression test is added to misc/cgo/testsanitizer. Fixes #51676. Fixes #59294. Fixes #59678. Change-Id: Ic62be31a06ee83568215e875a891df37084e08ca Reviewed-on: https://go-review.googlesource.com/c/go/+/485500 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Michael Pratt <mpratt@google.com>
* Revert "runtime/cgo: store M for C-created thread in pthread key"Michael Pratt2023-04-174-64/+3
| | | | | | | | | | | | | | | | | | | This reverts CL 481061. Reason for revert: When built with C TSAN, x_cgo_getstackbound triggers race detection on `g->stacklo` because the synchronization is in Go, which isn't instrumented. For #51676. For #59294. For #59678. Change-Id: I38afcda9fcffd6537582a39a5214bc23dc147d47 Reviewed-on: https://go-review.googlesource.com/c/go/+/485275 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
* misc/cgo: remove +build lines, add go:build where neededIan Lance Taylor2023-04-1039-47/+15
| | | | | | | | | | Change-Id: Iae6ac32db5c2aacb323793a7e0dc34e09648d035 Reviewed-on: https://go-review.googlesource.com/c/go/+/482295 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org>
* misc/cgo: gofmtIan Lance Taylor2023-04-108-0/+8
| | | | | | | | | | Change-Id: I5d02279d0593a8368b2f249a6b53650b89aed7b7 Reviewed-on: https://go-review.googlesource.com/c/go/+/482275 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* runtime/cgo: store M for C-created thread in pthread keydoujiang242023-04-034-3/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies CL 392854, with the followup fixes in CL 479255, CL 479915, and CL 481057 incorporated. CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 479255 is a followup fix for a small bug in ARM assembly code. CL 479915 is another followup fix to address C to Go calls after the C code uses some stack, but that CL is also buggy. CL 481057, by Michael Knyszek, is a followup fix for a memory leak bug of CL 479915. [Original CL 392854 description] In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls. So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call. Instead, we only dropm while the C thread exits, so the extra M won't leak. When invoking a Go function from C: Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor. And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits. When returning back to C: Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C. This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows. This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread. For the newly added BenchmarkCGoInCThread, some benchmark results: 1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz [CL 479915 description] Currently, when C calls into Go the first time, we grab an M using needm, which sets m.g0's stack bounds using the SP. We don't know how big the stack is, so we simply assume 32K. Previously, when the Go function returns to C, we drop the M, and the next time C calls into Go, we put a new stack bound on the g0 based on the current SP. After CL 392854, we don't drop the M, and the next time C calls into Go, we reuse the same g0, without recomputing the stack bounds. If the C code uses quite a bit of stack space before calling into Go, the SP may be well below the 32K stack bound we assumed, so the runtime thinks the g0 stack overflows. This CL makes needm get a more accurate stack bound from pthread. (In some platforms this may still be a guess as we don't know exactly where we are in the C stack), but it is probably better than simply assuming 32K. Fixes #51676. Fixes #59294. Change-Id: I9bf1400106d5c08ce621d2ed1df3a2d9e3f55494 Reviewed-on: https://go-review.googlesource.com/c/go/+/481061 Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: DeJiang Zhu (doujiang) <doujiang24@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* Revert "runtime/cgo: store M for C-created thread in pthread key"Cherry Mui2023-03-314-64/+3
| | | | | | | | | | | | | This reverts CL 392854. Reason for revert: caused #59294, which was derived from google internal tests. The attempted fix of #59294 caused more breakage. Change-Id: I5a061561ac2740856b7ecc09725ac28bd30f8bba Reviewed-on: https://go-review.googlesource.com/c/go/+/481060 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* runtime/cgo: store M for C-created thread in pthread keydoujiang242023-03-244-3/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls. So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call. Instead, we only dropm while the C thread exits, so the extra M won't leak. When invoking a Go function from C: Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor. And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits. When returning back to C: Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C. This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows. This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread. For the newly added BenchmarkCGoInCThread, some benchmark results: 1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz Fixes #51676 Change-Id: I380702fe2f9b6b401b2d6f04b0aba990f4b9ee6c GitHub-Last-Rev: 93dc64ad98e5583372e41f65ee4b7ab78b5aff51 GitHub-Pull-Request: golang/go#51679 Reviewed-on: https://go-review.googlesource.com/c/go/+/392854 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: thepudds <thepudds1460@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* cmd/cgo: walk {FuncType,TypeSpec}.TypeParams fieldsMatthew Dempsky2022-11-301-0/+6
| | | | | | | | | | | | | | | This CL updates the cgo tool to walk the TypeParams fields for function types and type declarations, so that C.xxx identifiers can appear within type parameter lists. Fixes #52542. Change-Id: Id02a88d529d50fe59b0a834f415c2575204ffd1f Reviewed-on: https://go-review.googlesource.com/c/go/+/453977 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* misc/cgo/test: skip Test9400 on AlpineAustin Clements2022-11-071-3/+10
| | | | | | | | | | | | | | | Alpine has a known issue where setgid clobbers the Go stack (#39857). misc/cgo/test skips other tests that use setgid on Alpine, but not this one. It's not clear to me why this test *used to* pass, but when I refactored misc/cgo/test in CL 447355 it started failing. Disable this test on Alpine, like the other setgid tests. Change-Id: I2e646ef55e2201a4f0b377319d719a011ec847f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/448355 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* misc/cgo/test: simplify for module modeAustin Clements2022-11-0474-206/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we were first introducing module mode, CL 163418 moved many of the tests in misc/cgo/test into their own test binary under testdata so misc/cgo/test continued to work in both GOPATH mode and module mode. This introduce a somewhat complicated test driver into misc/cgo/test. Since the misc/cgo/test test had to invoke "go test" as a subprocess, this required care to thread any build flags down into the subprocess. The output from any failures of the sub-process was also less than ideal. Now that we don't have to worry about running these in GOPATH mode any more, this CL moves all of the tests back into misc/cgo/test and drops the test driver. There are two slight complications: - Test41761 was added after this split and has a C type "S" that's also present in misc/cgo/test itself. We rename that to keep that test working. - TestCgo in go/internal/srcimporter now fails to import misc/cgo/test because misc/cgo/test now contains imports of other "misc" module packages and the importer it sets up isn't configured to allow that. We fix this by setting up a build context that's configured for this. Preparation for #37486. Change-Id: I3c4f73540e0482bbd493823cca44b0ce7fac01f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/447355 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* misc/cgo/test: disable setgid tests with muslMichael Pratt2022-08-221-0/+7
| | | | | | | | | | | | | | | | We don't have a good musl detection mechanism, so we detect Alpine (the most common user of musl) instead. For #39857. For #19938. Change-Id: I2fa39248682aed75884476374fe2212be4427347 Reviewed-on: https://go-review.googlesource.com/c/go/+/425001 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* all: disable tests that fail on AlpineRuss Cox2022-08-022-0/+10
| | | | | | | | | | | | | | These changes are enough to pass all.bash using the disabled linux-amd64-alpine builder via debugnewvm. For #19938. For #39857. Change-Id: I7d160612259c77764b70d429ad94f0864689cdce Reviewed-on: https://go-review.googlesource.com/c/go/+/419995 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
* misc/cgo/test: use fewer threads in TestSetgidStress in long modeCherry Mui2022-07-271-4/+1
| | | | | | | | | | | | | | | TestSetgidStress originally spawns 1000 threads for stress testing. It caused timeout on some builders so CL 415677 reduced to 50 in short mode. But it still causes flaky timeouts in longtest builders, so reduce the number of threads in long mode as well. Should fix #53641. Change-Id: I02f4ef8a143bb1faafe3d11ad223f36f5cc245c6 Reviewed-on: https://go-review.googlesource.com/c/go/+/419453 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* misc/cgo/test: make TestSetgidStress cheaperCherry Mui2022-07-061-1/+4
| | | | | | | | | | | | | | | | | | TestSetgidStress spawns 1000 threads, which can be expensive on some platforms or slow builders. Run with 50 threads in short mode instead. This makes the failure less reproducible even with buggy code. But one can manually stress test it (e.g. when a flaky failure appear on the builder). Fixes #53641. Change-Id: I33b5ea5ecaa8c7a56f59c16f9171657ee295db47 Reviewed-on: https://go-review.googlesource.com/c/go/+/415677 Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com>
* cmd/internal/obj/arm64: save LR and SP in one instruction for small framesCherry Mui2022-06-292-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we create a thread with signals blocked. But glibc's pthread_sigmask doesn't really allow us to block SIGSETXID. So we may get a signal early on before the signal stack is set. If we get a signal on the current stack, it will clobber anything below the SP. This CL makes it to save LR and decrement SP in a single MOVD.W instruction for small frames, so we don't write below the SP. We used to use a single MOVD.W instruction before CL 379075. CL 379075 changed to use an STP instruction to save the LR and FP, then decrementing the SP. This CL changes it back, just this part (epilogues and large frame prologues are unchanged). For small frames, it is the same number of instructions either way. This decreases the size of a "small" frame from 0x1f0 to 0xf0. For frame sizes in between, it could benefit from using an STP instruction instead of using the prologue for the "large" frame case. We don't bother it for now as this is a stop-gap solution anyway. This only addresses the issue with small frames. Luckily, all functions from thread entry to setting up the signal stack have samll frames. Other possible ideas: - Expand the unwind info metadata, separate SP delta and the location of the return address, so we can express "SP is decremented but the return address is in the LR register". Then we can always create the frame first then write the LR, without writing anything below the SP (except the frame pointer at SP-8, which is minor because it doesn't really affect program execution). - Set up the signal stack immediately in mstart in assembly. For Go 1.19 we do this simple fix. We plan to do the metadata fix in Go 1.20 ( #53609 ). Other LR architectures are addressed in CL 413428. Fix #53374. Change-Id: I9d6582ab14ccb06ac61ad43852943d9555e22ae5 Reviewed-on: https://go-review.googlesource.com/c/go/+/412474 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Eric Fang <eric.fang@arm.com>
* cmd/cgo: dont override declared struct typekkHAIKE2022-06-225-0/+67
| | | | | | | | | | | | | | | | Fixes #52611 Change-Id: I835df8d6a98a37482446ec00af768c96fd8ee4fe GitHub-Last-Rev: ea54dd69eef90eaf1641889039344fff70158ece GitHub-Pull-Request: golang/go#52733 Reviewed-on: https://go-review.googlesource.com/c/go/+/404497 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Dexter Ouyang <kkhaike@gmail.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Alex Rakoczy <alex@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* misc, test: fix test error for loong64Xiaodong Liu2022-05-201-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Contributors to the loong64 port are: Weining Lu <luweining@loongson.cn> Lei Wang <wanglei@loongson.cn> Lingqin Gong <gonglingqin@loongson.cn> Xiaolin Zhao <zhaoxiaolin@loongson.cn> Meidan Li <limeidan@loongson.cn> Xiaojuan Zhai <zhaixiaojuan@loongson.cn> Qiyuan Pu <puqiyuan@loongson.cn> Guoqi Chen <chenguoqi@loongson.cn> This port has been updated to Go 1.15.6: https://github.com/loongson/go Updates #46229 Change-Id: I6760b4a7e51646773cd0f48baa1baba01b213b7d Reviewed-on: https://go-review.googlesource.com/c/go/+/342325 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
* misc/cgo/test: remove timing dependency from TestParallelSleepIan Lance Taylor2022-04-213-53/+33
| | | | | | | | | | | | | | | Rename it TestIssue1560 since it no longer sleeps. For #1560 Fixes #45586 Change-Id: I338eee9de43e871da142143943e9435218438e90 Reviewed-on: https://go-review.googlesource.com/c/go/+/400194 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* misc/cgo/test: disable unhelpful GCC warningIan Lance Taylor2022-02-031-0/+5
| | | | | | | | | | | | | | | GCC 9 warns about a change in the ABI of passing structs with bitfields, but we don't care. Fixes #50987 Change-Id: Ica658d04172a42a7be788f94d31a714bb8c4766f Reviewed-on: https://go-review.googlesource.com/c/go/+/382956 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Trust: Benny Siegert <bsiegert@gmail.com>
* runtime: fix comments on the behavior of SetGCPercentMichael Anthony Knyszek2021-12-071-1/+3
| | | | | | | | | | | | | | | | | | | | | Fixes for #49680, #49695, #45867, and #49370 all assumed that SetGCPercent(-1) doesn't block until the GC's mark phase is done, but it actually does. The cause of 3 of those 4 failures comes from the fact that at the beginning of the sweep phase, the GC does try to preempt every P once, and this may run concurrently with test code. In the fourth case, the issue was likely that only *one* of the debug_test.go tests was missing a call to SetGCPercent(-1). Just to be safe, leave a TODO there for now to remove the extraneous runtime.GC calls, but leave the calls in. Updates #49680, #49695, #45867, and #49370. Change-Id: Ibf4e64addfba18312526968bcf40f1f5d54eb3f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/369815 Reviewed-by: Austin Clements <austin@google.com> Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* misc/cgo/test: further reduce likeliness of hang in Test9400Paul E. Murphy2021-11-301-0/+2
| | | | | | | | | | | | | | | As suggested by #49680, a GC could be in-progress when we disable GC. Force a GC after we pause to ensure we don't hang in this case. For #49695 Change-Id: I4fc4c06ef2ac174217c3dcf7d58c7669226e2d24 Reviewed-on: https://go-review.googlesource.com/c/go/+/367874 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Paul Murphy <murp@ibm.com>
* misc/cgo/test: reduce likeliness of hang in Test9400Paul E. Murphy2021-11-301-0/+5
| | | | | | | | | | | | | | | If a GC triggers while spinning in RewindAndSetgid, it may result in this test hanging. Avoid it by disabling the collector before entering the uninterruptable ASM conditional wait. Fixes #49695 Change-Id: Ie0a03653481fb746f862469361b7840f4bfa8b67 Reviewed-on: https://go-review.googlesource.com/c/go/+/365836 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* misc/cgo/test: remove unnecessary forward declarationBryan C. Mills2021-11-221-1/+0
| | | | | | | | | | | | | | | | | This test otherwise fails to build on windows/arm64 as of CL 364774 due to a warning (promoted to an error) about a mismatched dllexport attribute. Fortunately, it seems not to need the forward-declared function in this file anyway. Updates #49633 Updates #49721 Change-Id: Ia4698b85077d0718a55d2cc667a7950f1d8e50ab Reviewed-on: https://go-review.googlesource.com/c/go/+/366075 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime/cgo: add example of Handle with void* parameterAlan Donovan2021-11-203-0/+31
| | | | | | | | | | | | Fixes #49633 Change-Id: I12ca350f7dd6bfc8753a4a169f29b89ef219b035 Reviewed-on: https://go-review.googlesource.com/c/go/+/364774 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Trust: Bryan C. Mills <bcmills@google.com>
* cmd/cgo: update to handle ast.IndexListExprMatthew Dempsky2021-10-071-0/+17
| | | | | | | | | | | | | 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>
* cmd/cgo: add go:notinheap annotation to Windows handle typesElias Naur2021-09-223-0/+61
| | | | | | | | | | Fixes #42018 Change-Id: I6a40f3effe860e67a45fca2e8ab86f3e9887ffee Reviewed-on: https://go-review.googlesource.com/c/go/+/350070 Trust: Elias Naur <mail@eliasnaur.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org>
* cmd/cgo: fix unused parameter warnings in generated _cgo_main.cHans2021-08-162-0/+17
| | | | | | | | | | | | | | | | | | | | | 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: f09d172f979acfba855be8108e7d79ec2778c406 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>
* all: gofmt more (but vendor, testdata, and top-level test directories)Dmitri Shuralyov2021-08-1314-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* syscall: some containers may fail syscall.TestSetuidEtcAndrew G. Morgan2021-05-171-4/+17
| | | | | | | | | | | | | | | | | | | | | | 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>
* misc/cgo/test: do not redeclare exported Go functionsRuss Cox2021-04-234-31/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* all: simplify the spelling of LinuxBrad Fitzpatrick2021-04-131-1/+1
| | | | | | | | | | The prefix didn't help clarify anything. Change-Id: I897fd4022ce9df42a548b15714e4b592618ca547 Reviewed-on: https://go-review.googlesource.com/c/go/+/309573 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
* all: fix spellingsNaman Gera2021-04-101-3/+5
| | | | | | | | | | | | | | 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: e16a32cd225a275f73d236bcb33703986d110ded 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>
* reflect: panic on New of go:notinheap typeIan Lance Taylor2021-04-092-0/+20
| | | | | | | | | | | | For #42076 Fixes #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>
* runtime/cgo: add Handle for managing (c)go pointersChangkun Ou2021-04-063-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* all: update references to symbols moved from io/ioutil to ioKimMachineGun2021-04-052-6/+5
| | | | | | | | | | | | | | | Update references missed in CL 263142. For #41190 Change-Id: I778760a6a69bd0440fec0848bdef539c9ccb4ee1 GitHub-Last-Rev: dda42b09fff36dc08ec1cdec50cc19e3da5058e5 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>
* all: use more precise build tagsTamir Duberstein2021-02-239-9/+9
| | | | | | | | | | 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 setupRuss Cox2021-02-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* misc/cgo/test: enable TestCrossPackageTests on darwin/arm64Cherry Zhang2020-12-301-1/+1
| | | | | | | | | | | 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>
* cmd/cgo: fix initialization of empty argument typesAustin Clements2020-11-131-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* syscall: improve TestSetuidEtc() /proc/ parsing against racesAndrew G. Morgan2020-11-111-24/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/dist,cmd/go,runtime: add support for cgo on linux/riscv64Joel Sing2020-11-031-0/+31
| | | | | | | | | | | 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>
* misc/cgo/test: test C.enum_*HowJMay2020-10-272-0/+28
| | | | | | | | | | | | | | | | Allocate a C enum object, and test if it can be assigned a value successfully. For #39537 Change-Id: I7b5482112486440b9d99f2ee4051328d87f45dca GitHub-Last-Rev: 81890f40acc5589563ec1206fe119873fb46dc1b 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>
* runtime,cmd/cgo: simplify C -> Go call pathAustin Clements2020-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* syscall: support POSIX semantics for Linux syscallsAndrew G. Morgan2020-10-232-0/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds two new methods for invoking system calls under Linux: syscall.AllThreadsSyscall() and syscall.AllThreadsSyscall6(). These system call wrappers ensure that all OSThreads mirror a common system call. The wrappers serialize execution of the runtime to ensure no race conditions where any Go code observes a non-atomic OS state change. As such, the syscalls have higher runtime overhead than regular system calls, and only need to be used where such thread (or 'm' in the parlance of the runtime sources) consistency is required. The new support is used to enable these functions under Linux: syscall.Setegid(), syscall.Seteuid(), syscall.Setgroups(), syscall.Setgid(), syscall.Setregid(), syscall.Setreuid(), syscall.Setresgid(), syscall.Setresuid() and syscall.Setuid(). They work identically to their glibc counterparts. Extensive discussion of the background issue addressed in this patch can be found here: https://github.com/golang/go/issues/1435 In the case where cgo is used, the C runtime can launch pthreads that are not managed by the Go runtime. As such, the added syscall.AllThreadsSyscall*() return ENOTSUP when cgo is enabled. However, for the 9 syscall.Set*() functions listed above, when cgo is active, these functions redirect to invoke their C.set*() equivalents in glibc, which wraps the raw system calls with a nptl:setxid fixup mechanism. This achieves POSIX semantics for these functions in the combined Go and C runtime. As a side note, the glibc/nptl:setxid support (2019-11-30) does not extend to all security related system calls under Linux so using native Go (CGO_ENABLED=0) and these AllThreadsSyscall*()s, where needed, will yield more well defined/consistent behavior over all threads of a Go program. That is, using the syscall.AllThreadsSyscall*() wrappers for things like setting state through SYS_PRCTL and SYS_CAPSET etc. Fixes #1435 Change-Id: Ib1a3e16b9180f64223196a32fc0f9dce14d9105c Reviewed-on: https://go-review.googlesource.com/c/go/+/210639 Trust: Emmanuel Odeke <emm.odeke@gmail.com> Trust: Ian Lance Taylor <iant@golang.org> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Austin Clements <austin@google.com>
* cmd/link: support cgo internal/linking on darwin/arm64Cherry Zhang2020-10-203-3/+4
| | | | | | | | | | | | | | | Cgo programs work as well. Still not enabled by default for now. Enable internal linking tests. Updates #38485. Change-Id: I8324a5c263fba221eb4e67d71207ca84fa241e6c Reviewed-on: https://go-review.googlesource.com/c/go/+/263637 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>
* cmd/link: support PIE internal linking on darwin/amd64Cherry Zhang2020-10-143-1/+6
| | | | | | | | | | | | | | This CL adds support of PIE internal linking on darwin/amd64. This is also preparation for supporting internal linking on darwin/arm64 (macOS), which requires PIE for everything. Updates #38485. Change-Id: I2ed58583dcc102f5e0521982491fc7ba6f2754ed Reviewed-on: https://go-review.googlesource.com/c/go/+/261642 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
View Lorry Controller Status