Some C APIs require the use or structures that contain pointers to
buffers (iovec, io_uring, ...). The pointer passing rules would
require that these buffers are allocated in C memory and to process
this data with Go libraries it would need to be copied.
In order to provide a zero-copy way to use these C APIs, this CL
implements a Pinner API that allows to pin Go objects, which
guarantees that the garbage collector does not move these objects
while pinned. This allows to relax the pointer passing rules so that
pinned pointers can be stored in C allocated memory or can be
contained in Go memory that is passed to C functions.
The Pin() method accepts pointers to objects of any type and
unsafe.Pointer. Slices and arrays can be pinned by calling Pin()
with the pointer to the first element. Pinning of maps is not
supported.
If the GC collects unreachable Pinner holding pinned objects it
panics. If Pin() is called with the other non-pointer types it
panics as well.
Performance considerations: This change has no impact on execution
time on existing code, because checks are only done in code paths,
that would panic otherwise. The memory footprint on existing code is
one pointer per memory span.
Fixes: #46787
Signed-off-by: Sven Anderson <sven@anderson.de>
Change-Id: I110031fe789b92277ae45a9455624687bd1c54f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/367296
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
CL 495918 enabled testcarchive much more widely and added many dynamic
test skips. CL 495855 added TestDeepStack before these dynamic skips
were in. Unfortunately, the two CLs don't logically commute, so when
CL 495918 landed, it broke at least nocgo builders and platforms that
don't support c-archive builds. Fix this by adding the necessary skips
to TestDeepStack.
Change-Id: I3d352f731fe67a01c7b96871fde772db8eb21b5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/496376
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The test driver for testso and testsovar are literally identical, and
only the testdata code is different between the two test packages.
Merge them into a single test package with two tests that share a
driver.
Change-Id: I3f107a6aba345c0dd58606c10e3ac8eee33b33c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/496315
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Currently, this test only enabled on non-Darwin UNIX platforms because
it uses the non-standard _thread attribute for thread-local storage.
C11 introduced a standard way to declare something thread-local, so
this CL takes advantage of that to generalize the test to Darwin and
Windows.
Change-Id: Iba31b6216721df6eb8e978d7487cd3a787cae588
Reviewed-on: https://go-review.googlesource.com/c/go/+/496295
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
This makes testtls build and run on all platforms in the default build
configuration (though it will Skip on some).
Change-Id: I6aba96a82d618c9798a0d4418b40b2644cfceec9
Reviewed-on: https://go-review.googlesource.com/c/go/+/496177
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL moves many cgo test conditions out of dist and into the tests
themselves, now that they can use the testenv.Must* helpers.
This refines a lot of the conditions, which happens to have the effect
of enabling many tests on Android and iOS that are disabled by
too-coarse GOOS checks in dist today.
Fixes#15919.
Change-Id: I2947526b08928d2f7f89f107b5b2403b32092ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/495918
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This test was introduced in CL 18882, but only recently enabled as of
CL 493603. It's intended to check that we don't move executing C code
between threads when it re-enters Go, but it has always contained a
flake. Go *can* preempt between the Go call to gettid and the C call
to gettid and move the goroutine to another thread because there's no
C code on the stack during the Go call to gettid. This will cause the
test to fail.
Fix this by making both gettid calls in C, with a re-entry to Go
between them.
Fixes#60265
Change-Id: I546621a541ce52b996d68b17d3bed709d2b5b1f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/496182
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
This reapplies CL 485500, with a fix drafted in CL 492987 incorporated.
CL 485500 is reverted due to #60004 and #60007. #60004 is fixed in
CL 492743. #60007 is fixed in CL 492987 (incorporated in this CL).
[Original CL 485500 description]
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.
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.
[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 492987 description]
On the first call into Go from a C thread, currently we set the g0
stack's high bound imprecisely based on the SP. With CL 485500, we
keep the M and don't recompute the stack bounds when it calls into
Go again. If the first call is made when the C thread uses some
deep stack, but a subsequent call is made with a shallower stack,
the SP may be above g0.stack.hi.
This is usually okay as we don't check usually stack.hi. One place
where we do check for stack.hi is in the signal handler, in
adjustSignalStack. In particular, C TSAN delivers signals on the
g0 stack (instead of the usual signal stack). If the SP is above
g0.stack.hi, we don't see it is on the g0 stack, and throws.
This CL makes it get an accurate stack upper bound with the
pthread API (on the platforms where it is available).
Also add some debug print for the "handler not on signal stack"
throw.
Fixes#51676.
Fixes#59294.
Fixes#59678.
Fixes#60007.
Change-Id: Ie51c8e81ade34ec81d69fd7bce1fe0039a470776
Reviewed-on: https://go-review.googlesource.com/c/go/+/495855
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
The build tag on this file is currently unsatisfiable. It was clearly
supposed to be "linux || freebsd || openbsd", but the test doesn't
actually compile on FreeBSD or OpenBSD because they don't define
SYS_gettid. Change the build tag to just "linux".
Change-Id: Ifaffac5438e1b94a8588b5a00435461aa171a6fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/493603
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test package uses syscall.SIGSEGV and syscall.SIGPIPE, which are
defined on most, but not all platforms. Normally this test runs as
part of dist test, which only registers this test on platforms that
support c-archive build mode, which includes all platforms that define
these signals. But this doesn't help if you're just trying to type
check everything in cmd.
Add build constraints so that this package type checks on all
platforms.
Fixes#60164.
Updates #37486.
Change-Id: Id3f9ad4cc9f80146de16aedcf85d108a77215ae6
Reviewed-on: https://go-review.googlesource.com/c/go/+/494659
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test package uses the Pdeathsig field of syscall.SysProcAttr,
which is only available on a few platforms. Currently, dist test
checks for compatible platforms and only registers it as part of
all.bash on platforms where it can build. But this doesn't help if
you're just trying to type check everything in cmd.
Make this package pass type checking by moving the condition from dist
into build tags on the test package itself.
For #60164.
Updates #37486.
Change-Id: I58b12d547c323cec895320baa5fca1b82e99d1b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/494658
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Host tests are used for emulated builders that use cross-compilation.
Today, this is the android-{386,amd64}-emu builders and all wasm
builders. These builders run all.bash on a linux/amd64 host to build
all packages and most tests for the emulated guest, and then run the
resulting test binaries inside the emulated guest. A small number of
test packages are “host tests”: these run on the host rather than the
guest because they invoke the Go toolchain themselves (which only
lives on the host) and run the resulting binaries in the guest.
However, this host test mechanism is barely used today, despite being
quite complex. This complexity is also causing significant friction to
implementing structured all.bash output.
As of this CL, the whole host test mechanism runs a total of 10 test
cases on a total of two builders (android-{386,amd64}-emu). There are
clearly several tests that are incorrectly being skipped, so we could
expand it to cover more test cases, but it would still apply to only
two builders. Furthermore, the two other Android builders
(android-{arm,arm64}-corellium) build the Go toolchain directly inside
Android and also have access to a C toolchain, so they are able to get
significantly better test coverage without the use of host tests. This
suggests that the android-*-emu builders could do the same. All of
these tests are cgo-related, so they don't run on the wasm hosts
anyway.
Given the incredibly low value of host tests today, they are not worth
their implementation complexity and the friction they cause. Hence,
this CL drops support for host tests. (This was also the last use of
rtSequential, so we drop support for sequential tests, too.)
Fixes#59999.
Change-Id: I3eaca853a8907abc8247709f15a0d19a872dd22d
Reviewed-on: https://go-review.googlesource.com/c/go/+/492986
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This moves the misc/swig test to cmd/cgo/internal.
This lets these tests access facilities in internal/testenv. It's also
now just a normal test that can run as part of the cmd tests.
For #37486.
Change-Id: Ibe5026219999d175aa0a310b9886bef3f6f9ed17
Reviewed-on: https://go-review.googlesource.com/c/go/+/492722
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This moves most misc/cgo tests to cmd/cgo/internal. This is mostly a
trivial rename and updating dist/test.go for the new paths, plus
excluding these packages from regular dist test registration. A few
tests were sensitive to what path they ran in, so we update those.
This will let these tests access facilities in internal/testenv.
For #37486.
Change-Id: I3ed417c7c22d9b667f2767c0cb1f59118fcd4af6
Reviewed-on: https://go-review.googlesource.com/c/go/+/492720
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change causes cgo to emit an error (with the same
message as the compiler) when it encounters a declaration
of a method whose receiver type is C.T or *C.T.
Conceptually, C is another package, but unfortunately
the desugaring of C.T is a type within the same package,
causing the previous behavior to accept invalid input.
It is likely that at least some users are intentionally
exploiting this behavior, so this may break their build.
We should mention it in the release notes.
Fixes#57926
Change-Id: I513cffb7e13bc93d08a07b7e61301ac1762fd42d
Reviewed-on: https://go-review.googlesource.com/c/go/+/490819
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
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>
Change-Id: I69065f8adf101fdb28682c55997f503013a50e29
Reviewed-on: https://go-review.googlesource.com/c/go/+/449757
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joedian Reid <joedian@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The documentation for cgo has always said:
> The cgo tool is enabled by default for native builds
> on systems where it is expected to work.
Following the spirit of that rule, this CL disables cgo by default
on systems where $CC is unset and the default C compiler
(clang or gcc) is not found in $PATH.
This CL makes builds of Go code on systems with no C compiler
installed automatically fall back to non-cgo mode.
For example, if building a Go program using package net
in a stripped down Linux container, that build will now run
with cgo disabled, instead of attempting the build with cgo enabled
and only succeeding if the right pre-compiled .a files happen to
be loaded into the container.
This CL makes it safe to drop the pre-compiled .a files
from the Go distribution. Systems that don't have a C compiler
will simply disable cgo when building new .a files for that system.
In general keeping the pre-compiled .a files working in cgo mode
on systems without C compilers has had only mixed success due
to the precise build cache. Today we have had to disable various
checks in the precise build cache so that distributed .a files look
up-to-date even if the current machine's C compiler is a different
version than the one used when packaging the distribution.
Each time we improve precision we have a decent chance of
re-invalidating the files. This CL, combined with dropping the .a files
entirely, will let us re-enable those checks and ensure that the
.a files used in a build actually match the C compiler being used.
On macOS, the distributed .a files for cgo-dependent packages
have been stale (not actually used by the go command) since the
release of Go 1.14 in February 2020, due to CL 216304 setting
a CGO_CFLAGS environment variable that won't match the default
setting on users machines. (To keep the distributed .a files working,
that CL should have instead changed the default in the go command.)
The effect is that for the past six Go releases (!!!), the go command
has been unable to build basic programs like src/net/http/triv.go
on macOS without either disabling cgo or installing Xcode's C compiler.
This CL fixes that problem by disabling cgo when there's no C compiler.
Now it will once again be possible to build basic programs with just
a Go toolchain installed.
In the past, disabling cgo on macOS would have resulted in subpar
implementations of crypto/x509, net, and os/user, but as of CL 449316
those packages have all been updated to use libc calls directly,
so they now provide the same implementation whether or not cgo is enabled.
In the past, disabling cgo on macOS would also have made the
race detector unusable, but CL 451055 makes the race detector
work on macOS even when cgo is disabled.
On Windows, none of the standard library uses cgo today, so all
the necessary .a files can be rebuilt without a C toolchain,
and there is no loss of functionality in the standard library when
cgo is disabled. After this CL, the race detector won't work on
Windows without a C toolchain installed, but that turns out to be
true already: when linking race-enabled programs, even if the Go linker
does not invoke the host linker, it still attempts to read some of the
host C toolchain's .a files to resolve undefined references.
On Unix systems, disabling cgo when a C compiler is not present
will mean that builds get the pure Go net resolver, which is used
by default even in cgo builds when /etc/resolv.conf is simple enough.
It will also mean they get the pure os/user code, which reads
/etc/passwd and /etc/group instead of using shared libraries,
and therefore it may miss out on other sources of user information
such as LDAP. The race detector also will not work without a C compiler.
This would be dire except that nearly all Unix systems have a C compiler
installed by default, and on those that don't it is trivial to add one.
In particular, the vast majority of Go developers running on Linux
and other Unix systems will already have a C compiler and will be
unaffected.
Change-Id: I491e8a022fe3a64022e9dc593850d483a0d353fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/450739
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Test whether gccgo/GoLLVM supports cgo.Incomplete. If it doesn't, use a
local definition rather than importing it.
Roll back 426496, which skipped a gccgo test, as it now works.
For #46731Fixes#54761
Change-Id: I8bb2ad84c317094495405e178bf5c9694f82af56
Reviewed-on: https://go-review.googlesource.com/c/go/+/446260
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
[Roll-forward of CL 436915 by Tobias Klauser, with builtin and gen
directories dropped now that they've been handled separately.]
The minimum bootstrap version for Go ≥ 1.20 is Go 1.17. That version
supports the new style //go:build lines. Thus the old style //+build
lines can be dropped in this part of the tree as well. Leave the
//+build lines in cmd/dist which will ensure the minimum Go version
during bootstrap.
As suggested by Cherry during review of CL 430496
For #44505
Change-Id: Ifa686656c3e50bf7f92f70747b44d74a7d51bad8
Reviewed-on: https://go-review.googlesource.com/c/go/+/435473
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This reverts commit 6616573982, corresponding to CL 436915.
Reason for revert: this is causing some bootstrap build problems with older versions of Go 1.17, as I understand it. Still under investigation.
Change-Id: Idb6e17ff7b47004cbf87f967af6d84f214d8abb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/435471
Reviewed-by: David Chase <drchase@google.com>
The minimum bootstrap version for Go ≥ 1.20 is Go 1.17. That version
supports the new style //go:build lines. Thus the old style //+build
lines can be dropped in this part of the tree as well. Leave the
//+build lines in cmd/dist which will ensure the minimum Go version
during bootstrap.
As suggested by Cherry during review of CL 430496
For #44505
Change-Id: If53c0b02cacbfb055a33e73cfd38578dfd3aa340
Reviewed-on: https://go-review.googlesource.com/c/go/+/436915
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Change-Id: I97b5592c678c350fd77069d7c40a98864733707a
Reviewed-on: https://go-review.googlesource.com/c/go/+/435946
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Change-Id: I6007cc6363e22ffa5f9a8f0441a642fd85127397
Reviewed-on: https://go-review.googlesource.com/c/go/+/435945
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Change-Id: Iaa623dae50ccae36ad44af25899c6453b6108046
Reviewed-on: https://go-review.googlesource.com/c/go/+/435944
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
1. replace [0-9] with \d in regexps
2. replace [a-zA-Z0-9_] with \w in regexps
Change-Id: I9e260538252a0c1071e76aeb1c5f885c6843a431
GitHub-Last-Rev: 286e1a4619
GitHub-Pull-Request: golang/go#54874
Reviewed-on: https://go-review.googlesource.com/c/go/+/428435
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Say "//go:build" instead of "// +build" in the package level godoc
comment.
Change-Id: I4700227a03197ffbe29e4de04d068b4c63bb5bf0
Reviewed-on: https://go-review.googlesource.com/c/go/+/431856
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
For #45557
Change-Id: I56824135d86452603dd4ed4bab0e24c201bb0683
Reviewed-on: https://go-review.googlesource.com/c/go/+/426257
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I427776e5b2d9c7279932548c86c8faded0eed041
Reviewed-on: https://go-review.googlesource.com/c/go/+/428285
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: xie cui <523516579@qq.com>
We have supported passing lists of arguments to the compiler and linker
for some time, since https://go.dev/issue/18468 was fixed.
The reason behind it is that some systems like Windows have relatively
small limits for commands, and some Go packages contain many source files.
This wasn't done for other Go toolchain programs like cgo and asm,
as there wasn't an initial need for it. A TODO was left for them.
The need has now arisen in the form of a bug report for a build of a
large Go package involving cgo.
Do asm as well, which could be triggered by lots of asm files.
I rebuilt Go itself with some basic logging to tell if any other
commands were being run with moderately large command lengths.
I only found one other: gcc being invoked with 300-500 bytes.
I didn't spot any length close to 1KiB, and we can't safely assume that
a user's CC compiler supports these "response files", so leave that as
another TODO for the future. Just like cgo and asm, we can revisit this
if any user reports a bug on the issue tracker.
Fixes#47235.
Change-Id: Ifcc099d7c0dfac3ed2c4e9e7a2d6e3d69b0ccb63
Reviewed-on: https://go-review.googlesource.com/c/go/+/427015
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
None of cgo, "go test", nor srcimporter make use of go/ast's object
resolution via go/ast.Object. As such, we can skip that work during
parse time, which should save some CPU time.
We don't have any benchmark numbers, as none of the three packages have
any usable benchmarks, but we measured gofmt to be about 5% faster
thanks to this tweak in https://go.dev/cl/401454.
These three packages are quite different to gofmt, but one can expect
similar speed-ups in the 1-5% range.
Two notable exceptions, which do make use of go/ast.Object, are cmd/fix
and cmd/doc - we do not modify those here.
See #46485.
Change-Id: Ie3e65600d4790641c4e4d6f1c379be477fa02cee
Reviewed-on: https://go-review.googlesource.com/c/go/+/401455
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There's no real reason to limit to 1<<30 bytes. Maybe it would catch
some mistakes, but probably ones that would quickly manifest in other
ways.
We can't use the fancy new unsafe.Slice function because this code
may still be generated for people with 1.16 or earlier in their go.mod file.
Use unsafe shenanigans instead.
Fixes#53965Fixes#53958
Change-Id: Ibfa095192f50276091d6c2532e8ccd7832b57ca8
Reviewed-on: https://go-review.googlesource.com/c/go/+/418557
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#50710
Change-Id: I62feddbe3eaae9605d196bec60d378614436603a
Reviewed-on: https://go-review.googlesource.com/c/go/+/379754
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
For a package that uses cgo, the file _cgo_import.go is created to
record information required for internal linking: the non-Go dynamic
symbols and libraries that the package depends on. Generating this
information sometimes fails, because it can require recreating all the
dependencies of all transitively imported packages. And the
information is rarely needed, since by default we use external linking
when there are packages outside of the standard library that use cgo.
With this CL, if generating _cgo_import.go fails, we don't report an
error. Instead, we mark the package as requiring external linking, by
adding an empty file named "dynimportfail" into the generated archive.
If the linker sees a file with that name, it rejects an attempt to use
internal linking.
Fixes#52863
Change-Id: Ie586e6753a5b67e49bb14533cd7603d9defcf0ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/413460
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#52611
Change-Id: I835df8d6a98a37482446ec00af768c96fd8ee4fe
GitHub-Last-Rev: ea54dd69ee
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>
No test because this isn't support on any of the builders.
Fixes#53285
Change-Id: If8d17bdcdac81a6ce404a35a289bf83f07f02855
Reviewed-on: https://go-review.googlesource.com/c/go/+/411698
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#53013
Change-Id: I169d4eb2420a6da52cc9abe17da98c3092a91be6
Reviewed-on: https://go-review.googlesource.com/c/go/+/407514
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
https://reviews.llvm.org/D123534 is emitting DW_TAG_variable's
that don't have a DW_AT_name. This is allowed in the DWARF
standard. It is adding DIE's for string literals for better
symbolization on buffer overlows etc on these strings. They
no associated name because they are not user provided variables.
Fixes#53000
Change-Id: I2cf063160508687067c7672cef0517bccd707d7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/406816
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: Iee18987c495d1d4bde9da888d454eea8079d3ebc
GitHub-Last-Rev: ff5e01599d
GitHub-Pull-Request: golang/go#52949
Reviewed-on: https://go-review.googlesource.com/c/go/+/406915
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
When calling a C function, line information will be
incorrect if the function call's closing parenthesis
is not on the same line as the last argument. We add
a comment with the line info for the return statement
to guide debuggers to the correct line.
Fixes#49839.
Change-Id: I8bc2ce35fec9cbcafbbe8536d5a79dc487eb24bb
GitHub-Last-Rev: 8b28646d2e
GitHub-Pull-Request: golang/go#49840
Reviewed-on: https://go-review.googlesource.com/c/go/+/367454
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
We added internal/execabs back in January 2021 in order to fix
a security problem caused by os/exec's handling of the current
directory. Now that os/exec has that code, internal/execabs is
superfluous and can be deleted.
This commit rewrites all the imports back to os/exec and
deletes internal/execabs.
For #43724.
Change-Id: Ib9736baf978be2afd42a1225e2ab3fd5d33d19df
Reviewed-on: https://go-review.googlesource.com/c/go/+/381375
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Define pointer and int type size for loong64
Add "-mabi=lp64d" argument to gcc
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: I9699fd9af0112e72193ac24b736b85c580887a0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/342305
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
When we add GOEXPERIMENT=boringcrypto, the bootstrap process
will not converge if the compiler itself depends on the boringcrypto
cgo-based implementations of sha1 and sha256.
Using notsha256 avoids boringcrypto and makes bootstrap converge.
Removing md5 is not strictly necessary but it seemed worthwhile to
be consistent.
For #51940.
Change-Id: Iba649507e0964d1a49a1d16e463dd23c4e348f14
Reviewed-on: https://go-review.googlesource.com/c/go/+/402595
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Run the updated gofmt, which reformats doc comments,
on the main repository. Vendored files are excluded.
For #51082.
Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407
Reviewed-on: https://go-review.googlesource.com/c/go/+/384268
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
After CL 379474 has landed, the only remaining cgo export header
incompatibility with MSVC is the use of the _Complex macro,
which is not supported in MSVC even when it is part of the ISO C99
standard (1).
Since MSVC 2015 (2), complex math are supported via _Fcomplex and
_Dcomplex, which are equivalent to float _Complex and double _Complex.
As MSVC and C complex types have the same memory layout, we should
be able to typedef GoComplex64 and GoComplex128 to the appropriate
type in MSVC.
It is important to note that this CL is not adding MSVC support to cgo.
C compilers should still be GCC-compatible.
This CL is about allowing to include, without further modifications,
a DLL export header generated by cgo, normally using Mingw-W64 compiler,
into a MSVC project. This was already possible if the export header
changes introduced in this CL were done outside cgo, either manually or
in a post-build script.
Fixes#36233
1: https://docs.microsoft.com/en-us/cpp/c-runtime-library/complex-math-support
2: https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?c-standard-library-features-1
Change-Id: Iad8f26984b115c728e3b73f3a8334ade7a11cfa1
Reviewed-on: https://go-review.googlesource.com/c/go/+/397134
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Auto-Submit: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A future change to gofmt will rewrite
// Doc comment.
//
func f()
to
// Doc comment.
func f()
Apply that change preemptively to all doc comments.
For #51082.
Change-Id: I4023e16cfb0729b64a8590f071cd92f17343081d
Reviewed-on: https://go-review.googlesource.com/c/go/+/384259
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
