The windows/arm port does not yet support cgo, so disable a test that
requires it. This fixes a regression from CL 327969, which added support
for arm64, but errantly dropped the t.Skip for both arm and arm64,
rather than just for arm64. With this commit, we make the test specific
to cgo, rather than the architecture.
Change-Id: Ibe1166c1965e007c7af899b07ded65f2a2633ddd
Reviewed-on: https://go-review.googlesource.com/c/go/+/327970
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In CL 327210, we disabled this test on arm platforms, because the
powershell shipped with those systems isn't native, which means it'd
refuse to load native DLLs. This commit rewrites the test to simply not
use Powershell, and instead compiles a trivial C program that tests for
the same thing. Reverting CL 316269 makes this test fail, as desired,
while applying it makes this test succeed.
Fixes#46701
Change-Id: If39612c57bf74c63adf58e2c49b5cb739b461fe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/327969
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The powershell that currently ships on ARM Windows isn't native, so it
won't load native DLLs. So just skip the tests for now, and reenable it
if this ever changes.
Updates #46701.
Change-Id: I2559fdf13cb65d3ecdc4c6f6df7dec1b490b9651
Reviewed-on: https://go-review.googlesource.com/c/go/+/327210
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
The declaration order in CL 319310 does not match what the generator
produces from scratch. That currently causes
cmd/internal/moddeps.TestAllDependencies to fail, since it is
explicitly checking for that kind of skew.
Updates #45914
Change-Id: If2a9cabc3d54e21deba7cb438fa364df205f38ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/325112
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
On Windows 7 (and below), console handles are not real kernel handles
but are rather userspace objects, with information passed via special
bits in the handle itself. That means they can't be passed in
PROC_THREAD_ATTRIBUTE_HANDLE_LIST, even though they can be inherited.
So, we filter the list passed to PROC_THREAD_ATTRIBUTE_HANDLE_LIST to
not have any console handles on Windows 7. At the same time, it turns
out that the presence of a NULL handle in the list is enough to render
PROC_THREAD_ATTRIBUTE_HANDLE_LIST completely useless, so filter these
out too. Console handles also can't be duplicated into parent processes,
as inhertance always happens from the present process, so duplicate
always into the present process even when a parent process is specified.
Fixes#45914.
Change-Id: I70b4ff4874dbf0507d9ec9278f63b9b4dd4f1999
Reviewed-on: https://go-review.googlesource.com/c/go/+/319310
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Currently NewCallback and NewCallbackCDecl may only be called a limited
number of times in a single Go process, but this property of the API is
not documented. This change fixes that, but does not document the
precise limit to avoid making that limit part of the API, leaving us
open to increasing or decreasing the limit in the future as needed.
Although the API avoids documenting a limit, it does guarantee a minimum
callback count so users can rely on at least some amount of callbacks
working.
Updates #46184.
Change-Id: I5129bf5fe301efff73ac112ba1f207ab32058833
Reviewed-on: https://go-review.googlesource.com/c/go/+/321133
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
openbsd/mips64 is now the only openbsd port that uses non-libc syscall - revise
build tags to reflect this.
Update #36435
Change-Id: I357b2dd2926d058e25e618fcca42c388587598a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/317919
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Convert the syscall package on openbsd/arm to use libc rather than performing
direct system calls.
Updates #36435
Change-Id: Iff3a91c959292cbf4e0a09c7fd34efc8e88ff83f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315793
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Before the CL 288297 all Go process handles had to be made
non-inheritable - otherwise they would escape into the child process.
But now this is not necessary.
This CL stops changing inheritance flag of stdint, stdout and stderr
handles.
Fixes#44876
Change-Id: Ib8fcf8066c30282293d96c34486b01b4c04f7116
Reviewed-on: https://go-review.googlesource.com/c/go/+/316269
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Follow CL 23967 and CL 24021 which did the same on linux and freebsd,
respectively.
Updates #13987
Updates #16028
Change-Id: I95b13d8ddde4cea1ef4fb7d655f1ad1a219d13aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/315281
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follow CL 23967 and CL 24021 which did the same on linux and freebsd,
respectively.
Updates #13987
Updates #16028
Change-Id: Ia30ef8b5cffd8f9eb75c29ee5fe350dac2be6d44
Reviewed-on: https://go-review.googlesource.com/c/go/+/315279
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Convert the syscall package on openbsd/386 to use libc rather than performing
direct system calls.
Updates #36435
Change-Id: Ifcfbca0e6b933762596a564243caa850dac01442
Reviewed-on: https://go-review.googlesource.com/c/go/+/287654
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
That way the skip takes effect.
Also ignore the result of calling TIOCSPGRP when cleaing up TestForeground.
It has started to fail for some reason, and the result doesn't matter.
Also call TIOCSPGRP to clean up in TestForegroundSignal.
For #37217
Change-Id: I2e4282d7d91ad9a198eeb12cef01c2214c2a98c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/314271
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
ptrace1 must be nosplit because it is called from
forAndExecInChild. It was marked nosplit in the generated code
but not in the generator. CL 313230 regenerated the code and lost
the nosplit mark. This CL restores it.
Change-Id: I4645d83650f1818bed3cb650328bba97074b6b2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314249
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Fixes#37217
Change-Id: I0151bb77fc4c4552d1b19c31d784943b72f84b80
Reviewed-on: https://go-review.googlesource.com/c/go/+/313653
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Android seems to block the accept syscall in newer versions. Use accept4
instead on kernel versions that support it (Linux 2.6.28 and newer) and
fall back to accept on ENOSYS.
Fixes#45767
Change-Id: If190ace0e0213207fdaf6eeb79a5543ef18456de
Reviewed-on: https://go-review.googlesource.com/c/go/+/313769
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Do it on OpenBSD as well, as OpenBSD and Darwin share code
generator.
Change-Id: I408120795f7fc826637c867394248f8f373906bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/313230
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>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Like on openbsd/amd64, use libc instead of direct syscalls on
openbsd/arm64.
This was likely missed in CL 286815. A similar change was done for
openbsd/amd64 in CL 270380.
Updates #36435
Change-Id: Ie496a6130f1a43d30974502777db12217e65c551
Reviewed-on: https://go-review.googlesource.com/c/go/+/312229
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Add support for passing MSG_CMSG_CLOEXEC to the recvmsg syscall on
dragonfly, netbsd and openbsd. MSG_CMSG_CLOEXEC on freebsd is currently
broken, see https://reviews.freebsd.org/D29328.
Change-Id: Ie4c6e3cb550cd0ae32a1c2acca12edf77569e96a
Reviewed-on: https://go-review.googlesource.com/c/go/+/311570
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As mentioned in #42765, calling "recvmsg" syscall on Linux should come
with "MSG_CMSG_CLOEXEC" flag.
For other systems which not supports "MSG_CMSG_CLOEXEC". ReadMsgUnix()
would check the header. If the header type is "syscall.SCM_RIGHTS",
then ReadMsgUnix() would parse the SocketControlMessage and call each
fd with "syscall.CloseOnExec"
Fixes#42765
Change-Id: I74347db72b465685d7684bf0f32415d285845ebb
GitHub-Last-Rev: ca59e2c9e0
GitHub-Pull-Request: golang/go#42768
Reviewed-on: https://go-review.googlesource.com/c/go/+/272226
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The raw fds are successively wrapped using os.NewFile and will be closed
by (*os.File).Close. Avoids a double close, in the worst case closing an
unrelated fd.
Change-Id: I86aabe5ed865eff43d264ddae1fb07c935868e97
Reviewed-on: https://go-review.googlesource.com/c/go/+/309353
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #45402
Change-Id: I573133d6b987e8ac23e3e2018652612af684c755
Reviewed-on: https://go-review.googlesource.com/c/go/+/307990
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Update references missed in CL 263142.
For #41190
Change-Id: I778760a6a69bd0440fec0848bdef539c9ccb4ee1
GitHub-Last-Rev: dda42b09ff
GitHub-Pull-Request: golang/go#42874
Reviewed-on: https://go-review.googlesource.com/c/go/+/273946
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
asm_windows.s contains dummy references of syscall.loadlibrary
and syscall.getprocaddress, to trigger ABI wrapper/alias
generation to get ABI0 symbols for them. The comment says they
are called from assembly in other packages, but I couldn't find
where. They are defined in Go and only referenced in Go.
CL 179862 removed dummy references in the runtime. This CL
is similar, for the syscall package.
Also, with CL 306609, they will have ABI0 definitions anyway.
Change-Id: I5c7b0efb9762e4ad9c94f0beea8d053d8c8b2cd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306709
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This replaces five implementations scattered across low level packages.
(And I plan to use it in a sixth soon.)
Three of the five were byte-for-byte identical.
Change-Id: I3bbbeeac63723a487986c912b604e10ad1e042f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/301549
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
It turns out that if you write Go pointers to Go memory, the Go compiler
must be involved so that it generates various calls to the GC in the
process. Letting Windows write Go pointers to Go memory violated this.
So, we replace that with just a boring call to runtime.KeepAlive. That's
not a great API, but this is all internal code anyway. We fix it up
more elegantly for external consumption in x/sys/windows with CL 300369.
Fixes#44900.
Change-Id: Id6599a793af9c4815f6c9387b00796923f32cb97
Reviewed-on: https://go-review.googlesource.com/c/go/+/300349
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It turns out that the proc thread update function doesn't actually
allocate new memory for its arguments and instead just copies the
pointer values into the preallocated memory. Since we were allocating
that memory as []byte, the garbage collector didn't scan it for pointers
to Go allocations and freed them. We _could_ fix this by requiring that
all users of this use runtime.KeepAlive for everything they pass to the
update function, but that seems harder than necessary. Instead, we can
just do the allocation as []unsafe.Pointer, which means the GC can
operate as intended and not free these from beneath our feet. In order
to ensure this remains true, we also add a test for this.
Fixes#44662.
Change-Id: Ib392ba8ceacacec94b11379919c8179841cba29f
Reviewed-on: https://go-review.googlesource.com/c/go/+/297389
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
'fork/exec ...: cannot allocate memory' failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on these platforms.
Fixes#31936
Change-Id: I4e28cf0763173145cacaa5340680dca9ff449305
Reviewed-on: https://go-review.googlesource.com/c/go/+/295849
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This allows users to specify which process should be used as the parent
process when creating a new process.
Note that this doesn't just trivially pass the handle onward to
PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, because inherited handles must be
valid in the parent process, so if we're changing the destination
process, then we must also change the origin of the parent handles. And,
the StartProcess function must clean up these handles successfully when
exiting, regardless of where the duplication happened. So, we take care
in this commit to use DuplicateHandle for both duplicating and for
closing the inherited handles.
The test was taken originally from CL 288272 and adjusted for use here.
Fixes#44011.
Change-Id: Ib3b132028dcab1aded3dc0e65126c8abebfa35eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/288300
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This allows users to specify handles that they explicitly want to be
inherited by the new process. These handles must already be marked as
inheritable.
Updates #44011.
Updates #21085.
Change-Id: Ib18322e7dc2909e68c4209e80385492804fa15d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/288298
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Windows does not have CLOEXEC, but rather handles are marked explicitly
for being inherited by new processes. This can cause problems when
different Windows functions create new processes from different threads.
syscall.StartProcess has traditionally used a mutex to prevent races
with itself, but this doesn't handle races with other win32 functions.
Fortunately there's a solution: PROC_THREAD_ATTRIBUTE_HANDLE_LIST allows
us to pass the entire list of handles that we want to be inherited. This
lets us get rid of the mutex and also makes process creation safe across
the Go runtime, no matter the context.
Updates #44011.
Change-Id: Ia3424cd2ec64868849cbd6cbb5b0d765224bf4ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/288297
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This will allow us to pass additional attributes when starting
processes.
Updates #44011.
Change-Id: I4af365c5544a6d421830f247593ec970200e5e03
Reviewed-on: https://go-review.googlesource.com/c/go/+/288296
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Updates #42637
Change-Id: I4c7d38034b60c2c04efdeb530a97d96deddfd6fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/284152
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This function has the wrong signature, so return an error when that
actually might lead to unexpected results. Users should switch to
x/sys/windows for the real version of this function.
Updates #44538.
Change-Id: I4d1f3d1e380815733ecfea683f939b1d25dcc32a
Reviewed-on: https://go-review.googlesource.com/c/go/+/296154
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follow the implementation used by the other BSDs and account for the
intricacy of having to pass the fds array even though the file
descriptors are returned.
Re-submit of CL 130996 with corrected pipe2 wrapper.
Change-Id: Ie36d8214cba60c4fdb579f18bfc1c1ab3ead3ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/295372
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts commit dc4698f52b, and then
fixes the memory corruption issue. It also suggests users switch to
x/sys/windows for the proper function.
This requires CL 295174 to be submitted first.
Updates #44538.
Change-Id: I0ee602f1c1d6a89cc585aff426833a4cb3f2be50
Reviewed-on: https://go-review.googlesource.com/c/go/+/296149
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The third argument to GetQueuedCompletionStatus is a pointer to a
uintptr, not a uint32. Users of this functions have therefore been
corrupting their memory every time they used it. Either that memory
corruption was silent (dangerous), or their programs didn't work so they
chose a different API to use.
Fixes#44538.
RELNOTES=yes
Change-Id: Idf48d4c712d13da29791e9a460159255f963105b
Reviewed-on: https://go-review.googlesource.com/c/go/+/295371
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This permits analysis of the syscall package by tools built with
older versions of Go that do not recognize ios as a GOOS.
Fixes#44459
Change-Id: I79cec2ffe0dbcbc2dc45a385e556dc9e62033125
Reviewed-on: https://go-review.googlesource.com/c/go/+/294634
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
types_windows_arm64.go is a copy of types_windows_amd64.go.
All that matters for these types seems to be that they are 64-bit vs 32-bit.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ia7788d6e88e5db899371c75dc7dea7d912a689ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/288825
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
The files being deleted contain no code.
They exist because back when we used Makefiles
that listed all the Go sources to be compiled, we wrote
patterns like syscall_$GOOS_$GOARCH.go,
and it was easier to create dummy empty files
than introduce conditionals to not look for that
file on Windows.
Now that we have the go command instead,
we don't need those dummy files.
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: Ie0066d1dd2bf09802c74c6a496276e8c593e4bc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/288815
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change Plan 9 fork/exec to use the O_CLOEXEC file
descriptor, instead of relying on spooky at a
distance.
Historically, Plan 9 has set the O_CLOEXEC flag on
the underlying channels in the kernel, rather
than the file descriptors -- if two fds pointed
at a single channel, as with dup, changing the
flags on one of them would be observable on the
other.
The per-Chan semantics are ok, if unexpected,
when a chan is only handled within a single
process, but this isn't always the case.
Forked processes share Chans, but even more of
a problem is the interaction between /srv and
OCEXEC, which can lead to unexectedly closed
file descriptors in completely unrelated
proceses. For example:
func exists() bool {
// If some other thread execs here,
// we don't want to leak the fd, so
// open it O_CLOEXEC
fd := Open("/srv/foo", O_CLOEXEC)
if fd != -1 {
Close(fd)
return true
}
return false
}
would close the connection to any file descriptor
(maybe even for the root fs) in ALL other processes
that have it open if an exec were to happen(!),
which is quite undesriable.
As a result, 9front will be changing this behavior
for the next release.
Go is the only code observed so far that relies on
this behavior on purpose, and It's easy to make the
code work with both semantics: simply using the file
descriptor that was opened with O_CEXEC instead of
throwing it away.
So we do that here.
Fixes#43524
Change-Id: I4887f5c934a5e63e5e6c1bb59878a325abc928d3
GitHub-Last-Rev: 96bb21bd1e
GitHub-Pull-Request: golang/go#43533
Reviewed-on: https://go-review.googlesource.com/c/go/+/281833
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Richard Miller <millerresearch@gmail.com>
Reviewed-by: Jacob Moody <j4kem00dy@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
Mark the syscall wrappers as ABIInternal, as they have addresses
taken from Go code, and it is important to call to them without
wrappers.
Previously, the wrapper is just a single JMP instruction, which
makes it not matter. In the next CL we'll make the wrapper
actually have a frame. The real wrappers will mess up things
such as stack alignment for C ABI.
This doesn't look really nice, but I don't know how we can do
better...
TODO: other OSes.
Change-Id: Ifb3920494990a7775e3e6902fbcaf137df3cc653
Reviewed-on: https://go-review.googlesource.com/c/go/+/288092
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>