With the previous CL, internal/abi.IntArgRegs and FloatArgRegs
is controlled by RegabiArgs (or always enabled), so there is no
need to check for that goexperiment.
There are a few places we guard register-ABI specific code and
tests with the RegabiArgs flag. Switch to checking for the number
of argument registers instead.
Change-Id: I79fff9fd1e919684ffaf73aba9e7e85d5a9e1629
Reviewed-on: https://go-review.googlesource.com/c/go/+/393363
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
SetGCPercent(-1) is called by several tests in debug_test.go (followed
by a call to runtime.GC) due to #49370. However, startDebugCallWorker
already actually has this, just without the runtime.GC call (allowing an
in-progress GC to still mess up the test).
This CL consolidates SetGCPercent into startDebugDebugCallWorker where
applicable.
Change-Id: Ifa12d6a911f1506e252d3ddf03004cf2ab3f4ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369751
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently the debug call protocol implementation we use for testing is
riddled with write barriers, and called from a signal handler. This is
not safe, as write barriers need a P to execute.
Ideally this implementation would be rewritten to avoid the write
barriers, but it's not straightforward, and needs some thought. As a
temporary measure, disable GC during the debug call tests to avoid a
write barrier.
Note that this does not indicate a problem with real use of the debug
call protocol. Only our test implementation has this issue, because it
needs to get executed in a signal handler, normally a separate process
is interfacing with the protocol via process signals and ptrace (and the
like).
Fixes#49370.
Change-Id: Ic0fde5d0f4c64f9ecc9789b7dabb3954538fe0a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/361896
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
When these packages are released as part of Go 1.18,
Go 1.16 will no longer be supported, so we can remove
the +build tags in these files.
Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs
as defined in src/cmd/dist/buildtool.go, which need to continue
to build with Go 1.4 for now.
Also reverted src/vendor and src/cmd/vendor, which will need
to be updated in their own repos first.
Manual changes in runtime/pprof/mprof_test.go to adjust line numbers.
For #41184.
Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/344955
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The debug call tests currently assume that the target Go function is
ABI0; this is clearly no longer true when we switch to the new ABI, so
make the tests set up argument register state in the debug call handler
and copy back results returned in registers.
A small snag in calling a Go function that follows the new ABI is that
the debug call protocol depends on the AX register being set to a
specific value as it bounces in and out of the handler, but this
register is part of the new register ABI, so results end up being
clobbered. Use R12 instead.
Next, the new desugaring behavior for "go" statements means that
newosproc1 must always call a function with no frame; if it takes any
arguments, it closes over them and they're passed in the context
register. Currently when debugCallWrap creates a new goroutine, it uses
newosproc1 directly and passes a non-zero-sized frame, so that needs to
be updated. To fix this, briefly use the g's param field which is
otherwise only used for channels to pass an explicitly allocated object
containing the "closed over" variables. While we could manually do the
desugaring ourselves (we cannot do so automatically because the Go
compiler prevents heap-allocated closures in the runtime), that bakes in
more ABI details in a place that really doesn't need to care about them.
Finally, there's an old bug here where the context register was set up
in CX, so technically closure calls never worked. Oops. It was otherwise
harmless for other types of calls before, but now CX is an argument
register, so now that interferes with regular calls, too.
For #40724.
Change-Id: I652c25ed56a25741bb04c24cfb603063c099edde
Reviewed-on: https://go-review.googlesource.com/c/go/+/309169
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
If GOEXPERIMENT=regabidefer is enabled, newproc currently checks that
the call frame for new goroutines is empty. But there's one place in
the runtime (debugCallWrap), where we call newproc1, and it happens to
pass a non-empty frame. The current check didn't catch that. Move the
empty call frame check from newproc to newproc1 to catch this.
Updates #40724.
Change-Id: I9998faf1e07e7b7af88e06a8177127f998c40252
Reviewed-on: https://go-review.googlesource.com/c/go/+/309034
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
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>
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
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>
This fixes a few different issues that led to hangs and general
flakiness in the TestDebugCall* tests.
1. This fixes missing wake-ups in two error paths of the SIGTRAP
signal handler. If the goroutine was in an unknown state, or if
there was an unknown debug call status, we currently don't wake the
injection coordinator. These are terminal states, so this resulted
in a hang.
2. This adds a retry if the target goroutine is in a transient state
that prevents us from injecting a call. The most common failure
mode here is that the target goroutine is in _Grunnable, but this
was previously masked because it deadlocked the test.
3. Related to 2, this switches the "ready" signal from the target
goroutine from a blocking channel send to a non-blocking channel
send. This makes it much less likely that we'll catch this
goroutine while it's in the runtime performing that send.
4. This increases GOMAXPROCS from 2 to 8 during these tests. With the
current setting of 2, we can have at most the non-preemptible
goroutine we're injecting a call in to and the goroutine that's
trying to make it exit. If anything else comes along, it can
deadlock. One particular case I observed was in TestDebugCallGC,
where runtime.GC() returns before the forEachP that prepares
sweeping on all goroutines has finished. When this happens, the
forEachP blocks on the non-preemptible loop, which means we now
have at least three goroutines that need to run.
Fixes#25519.
Updates #29124.
Change-Id: I7bc41dc0b865b7d0bb379cb654f9a1218bc37428
Reviewed-on: https://go-review.googlesource.com/c/154112
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The debug call injection tests will freeze when run under a debugger
because they depend on catching SIGTRAP, which is usually swallowed by
a debugger.
Change-Id: If6b86ca279b0489182990dd513444ca3062973f1
Reviewed-on: https://go-review.googlesource.com/c/139437
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TestDebugCall* uses atomic spin loops and hence can deadlock if the
garbage collector is enabled (because of #10958; ironically,
implementing debugger call injection is closely related to fixing this
exact issue, but we're not there yet).
Fix this by disabling the garbage collector during these tests.
Updates #25519 (might fix it, though I suspect not)
Change-Id: If1e454b9cdea8e4b1cd82509b762c75b6acd8476
Reviewed-on: https://go-review.googlesource.com/114086
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This adds a mechanism for debuggers to safely inject calls to Go
functions on amd64. Debuggers must participate in a protocol with the
runtime, and need to know how to lay out a call frame, but the runtime
support takes care of the details of handling live pointers in
registers, stack growth, and detecting the trickier conditions when it
is unsafe to inject a user function call.
Fixes#21678.
Updates derekparker/delve#119.
Change-Id: I56d8ca67700f1f77e19d89e7fc92ab337b228834
Reviewed-on: https://go-review.googlesource.com/109699
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Cherry Mui
Michael Anthony Knyszek
Russ Cox
Austin Clements
Ian Lance Taylor