This change updates the go command behavior when
fuzzing to instrument the binary for code coverage,
and uses this coverage in the fuzzing engine to
determine if an input is interesting.
Unfortunately, we can't store and use the coverage
data for a given run of `go test` and re-use it
the next time we fuzz, since the edges could have
changed between builds. Instead, every entry in
the seed corpus and the on-disk corpus is run
by the workers before fuzzing begins, so that the
coordinator can get the baseline coverage for what
the fuzzing engine has already found (or what
the developers have already provided).
Users should run `go clean -fuzzcache` before
using this change, to clear out any existing
"interesting" values that were in the cache.
Previously, every single non-crashing input was
written to the on-disk corpus. Now, only inputs
that actually expand coverage are written.
This change includes a small hack in
cmd/go/internal/load/pkg.go which ensures that the Gcflags
that were explicitly set in cmd/go/internal/test/test.go
don't get cleared out.
Tests will be added in a follow-up change, since
they will be a bit more involved.
Change-Id: Ie659222d44475c6d68fa4a35d37c37cab3619d71
Reviewed-on: https://go-review.googlesource.com/c/go/+/312009
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Usage of f.testContext.match.fullName to generate the test name causes
unbounded memory growth, eventually causing the fuzzer to slow down
as memory pressure increases.
Each time fuzzFn is invoked it generates a unique string and stores it
in a map. With the fuzzer running at around 100k executions per second
this consumed around ~30GB of memory in a handful of minutes.
Instead just use the base name of the test for mutated inputs, a special
name for seeded inputs, and the filename for inputs from the input
corpus.
Change-Id: I083f47df7e82f0c6b0bda244f158233784a13029
Reviewed-on: https://go-review.googlesource.com/c/go/+/316030
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
There was a bug where if the types to fuzz were
different from the types in a file in the on-disk
corpus, then the code would panic. We thought
this case was handled, but the final `continue`
in the nested loop still allowed the invalid
entry to be added to the corpus. Pulling the
validation into a helper function makes this
less brittle.
Change-Id: I401346f890ea30ab7cff9640cb555da2e3ff8cc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/313810
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The -timeout flag is not used when the fuzzing engine
is running, but there was another backup alarm that would
stop the test binary after 11 minutes by default. This
change disables that backup alarm when the -fuzz flag is
set.
Note: unfortunately this means that if someone is running
`go test -fuzz` and a test hangs before the fuzzing engine
starts running, then the backup alarm won't trigger and
the test will run ~forever. I don't think there's a way
around this though, since the backup alarm has no way of
knowing what stage of the test execution we're in (ie.
are we running the unit tests, the seed corpus, or is
it fuzzing).
Fixes#44483
Change-Id: I4e212708a739c9cfc2e138440e27f257bb408c7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313072
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Adds four []byte mutators which:
* insert a chunk of constant bytes
* overwirtes a chunk with constant bytes
* shuffle a range of bytes
* swaps two chunks
Also updates the 'set byte to random value' mutator to use XOR in
order to avoid a no-op.
Additionally updates the rng call which chooses the []byte mutators
so all the available mutators are used.
Change-Id: I0703518922952f4b1c81b19b196ee91c73b0d5f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/313270
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Assuming that this works for non-recoverable errors, there
will likely be a follow-up CL which refactors the minimization
for recoverable errors to use the same RPC flow (since that
more easily allows the worker to tell the coordinator that
it's minimizing and shouldn't send more inputs to other workers
to fuzz).
Change-Id: I32ac7cec4abe2d4c345c0ee77315233047efb1fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/309509
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Previously, something like `float64(0)` would fail to decode
since the 0 value is considered an integer literal, and the
float64 parsing code required a float literal. Be more flexible
here since an integer can always be converted to a float.
Change-Id: Id1c53ef2e8a9748a4f71176b00b453a329af4ade
Reviewed-on: https://go-review.googlesource.com/c/go/+/309032
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This improves readability a bit, and it should help with compatibility
for future clients when arguments are added or reordered.
Unfortunately, testing still can't import internal/fuzz, so the
interface there can't use this type.
Change-Id: I4cda2347884defcbbfc2bd01ab5b4a901d91549c
Reviewed-on: https://go-review.googlesource.com/c/go/+/308192
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
While running the seed corpus, T.Parallel acts like it does in
subtests started with T.Run: it blocks until all other non-parallel
subtests have finished, then unblocks when the barrier chan is
closed. A semaphore (t.context.waitParallel) limits the number of
tests that run concurrently (determined by -test.parallel).
While fuzzing, T.Parallel has no effect, other than asserting that it
can't be called multiple times. We already run different inputs in
concurrent processes, but we can't run inputs concurrently in the same
process if we want to attribute crashes to specific inputs.
Change-Id: I2bac08e647e1d92ea410c83c3f3558a033fe3dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/300449
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
-fuzztime now works similarly to -benchtime: if it's given a string
with an "x" suffix (as opposed to "s" or some other unit of
duration), the fuzzing system will generate and run a maximum number
of values.
This CL also implements tracking and printing counts, since most of
the work was already done.
Change-Id: I013007984b5adfc1a751c379dc98c8d46b4a97e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/306909
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
worker.runFuzzing now accepts a Context, used for cancellation instead
of doneC (which is removed). This is passed down through workerClient
RPC methods (ping, fuzz).
workerClient RPC methods now wrap the call method, which handles
marshaling and cancellation.
Both workerClient.call and workerServer.serve should return quickly
when their contexts are cancelled. Turns out, closing the pipe won't
actually unblock a read on all platforms. Instead, we were falling
back to SIGKILL in worker.stop, which works but takes longer than
necessary.
Also fixed missing newline in log message.
Change-Id: I7b5ae54d6eb9afd6361a07759f049f048952e0cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/303429
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
The -fuzztime flag tells us how much time to spend fuzzing, not
counting time spent running the seed corpus. We shouldn't count time
spent loading the cache either. If the cache is large, the time limit
may be exceeded before the coordinator starts the workers.
Change-Id: If00435faa5d24aabdb9003ebb9337fa2e47f22b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/307310
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
This CL makes two main changes to allow internal/fuzz to support
-d=libfuzzer instrumentation:
1. It extends cmd/link to define _counters and _ecounters symbols so
internal/fuzz can find the coverage counters.
2. It adds "trace" stub functions that implement the ABI expected by
cmd/compile for comparison instrumentation.
N.B., that -tags=libfuzzer should *not* be set, so that
internal/fuzz's trace routines will be used instead of runtime's
libfuzzer trampolines.
Also, the current implementation doesn't support multi-module builds
(i.e., compiling a Go program that spans multiple .so/.dll files).
Presumably this isn't an issue, since "go test -fuzz" will need to
recompile the binary with instrumentation anyway so it can make sure
to always use a single-module build. But we can revisit this if
necessary.
Change-Id: I9b1619119ab7477bebcfd5988b4b60499a7ab0d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/308289
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Assuming this works, will follow up with another CL
that mutates other types.
Change-Id: Id61acaacd56ca41e3be52e400f8f768672313bbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/308169
Trust: Katie Hockman <katie@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This change only includes a stub for the function
which will hook into the runtime to expose
coverage instrumentation while we're fuzzing.
Previously, we discussed an exported API named
FuzzCoverage, but since this is within the
internal/fuzz package, simply naming it coverage
seems appropriate.
Change-Id: Iba3240e53e0c4c434e937aa9bb1711a44fec9975
Reviewed-on: https://go-review.googlesource.com/c/go/+/308191
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This fixes a few issues that were being masked since
log statements weren't being printed to stdout. Now
that they are, fix the bugs, and update the tests.
Also includes a few small refactors which will make
minimizing non-recoverable errors easier.
Change-Id: Ie2fd2e5534b3980317e1e1f3fd8e04750988c17f
Reviewed-on: https://go-review.googlesource.com/c/go/+/307810
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
When mutating a byte slice, mutate in place, and only allocate once if
the slice's capacity is less than the maximum size.
mutateBytes already should not allocate; we check a post-condition
that the slice's data pointer does not change.
This speeds up the mutator from 4 ms per value to 200-600 ns. For
example:
goos: darwin
goarch: amd64
pkg: internal/fuzz
cpu: Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
BenchmarkMutatorBytes/1-8 5908735 275.3 ns/op
BenchmarkMutatorBytes/10-8 5198473 282.0 ns/op
BenchmarkMutatorBytes/100-8 4304750 233.9 ns/op
BenchmarkMutatorBytes/1000-8 4623988 295.2 ns/op
BenchmarkMutatorBytes/10000-8 4252104 458.5 ns/op
BenchmarkMutatorBytes/100000-8 1236751 950.8 ns/op
PASS
ok internal/fuzz 12.993s
Change-Id: I4bf2a04be6c648ef440af2c62bf0ffa3d310172c
Reviewed-on: https://go-review.googlesource.com/c/go/+/306675
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Also improve the error messages for the use of
testing.F functions inside the Fuzz function.
Change-Id: I5fa48f8c7e0460a1da89a49a73e5af83c544e549
Reviewed-on: https://go-review.googlesource.com/c/go/+/298849
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This works by minimizing for a maximum of one minute. We may consider
making this customizable in the future.
This only minimizes []byte inputs which caused a recoverable error. In
the future, it should support minimizing other appopriate types, and
minimizing types which caused non-recoverable errors (though this is
much more expensive).
The code in internal/fuzz/worker.go is copied from, or heavily inspired
by, code originally authored by Dmitry Vyukov and Josh Bleecher Snyder
as part of the go-fuzz project. Thanks to them for their contributions.
See https://github.com/dvyukov/go-fuzz.
Change-Id: I93dbac7ff874d6d0c1b9b9dda23930ae9921480c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298909
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
CoordinateFuzzing now continues to run after discovering a crasher. It
waits until all workers have terminated before returning.
This fixes a deadlock that occurred when multiple workers discovered
crashers concurrently. CoordinateFuzzing would receive one crasher,
close doneC (telling workers to stop), then wait for workers to stop
without receiving more crashers. Other workers would block sending
crashers.
Change-Id: I55a64aac0e6e43f5e36b9d03c15051c3d5debb20
Reviewed-on: https://go-review.googlesource.com/c/go/+/293369
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
* Appending to the worker environment slice should reallocate it. On
Windows, we pass handles through the environment, and concurrent
workers were writing to the same memory, resulting in
"The handle is invalid" errors.
* Instead of passing a handle to the temporary file, we pass its path
to each worker instead. The worker is responsible for opening and
closing the handle. Previously, all inheritable handles were
inherited by all workers, even though only one was used. This
prevented temporary files from being deleted after a worker stopped,
because other workers would still have open handles to it.
Change-Id: If8b8bcfa5b03fbcadd10ef923b036bb0ee5dc3f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/297034
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
If a worker process encounters an error communicating with the
coordinator, or if the setup code reports an error with F.Fail
before calling F.Fuzz, exit with status 70. The coordinator will report
these errors and 'go test' will exit non-zero, but the coordinator
won't record a crasher since the problem is not in the code being
fuzzed.
The coordinator also detects unexpected terminations before the worker
calls F.Fuzz by sending a ping RPC. If the worker terminates before
responding to the ping RPC, the coordinator won't record a crasher.
Exit codes are chosen somewhat arbitrary, but in the Advanced Bash
Scripting Guide, 70 is "internal software error" which is applicable
here. 70 is also ASCII 'F'.
Change-Id: I1e676e39a7b07c5664efaaa3221d055f55240fff
Reviewed-on: https://go-review.googlesource.com/c/go/+/297033
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
* Run gofmt with go1.17 build constraint changes.
* Tighten regular expressions used in tests. "ok" got some false
positives with verbose output, so make sure it appears at the start
of a line.
* Return err in deps.RunFuzzWorker instead of nil.
* Call common.Helper from F methods. This prevents F methods from
appearing in stack traces.
Change-Id: I839c70ec8a9f313c1a4ea68e6bb34a4d801dd36f
Reviewed-on: https://go-review.googlesource.com/c/go/+/297032
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Previously, ever worker would run all of the unit tests, benchmarks, and
examples. Only the single coordinator needs to do this.
Change-Id: I0dfa7f79b390b6c3220d8ea646e2d2312eee6bb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/298809
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Previously, the coordintor used the error string encoded by the worker
to determine whether or not a crash occurred. However, failures caused
by things like t.Fail() which have no output will have an empty error
string, so we can't rely on the error string alone to determine if
something is a crasher or not.
Change-Id: Idcf7f6b1210aa1dc4e8dab222642c87919595693
Reviewed-on: https://go-review.googlesource.com/c/go/+/298351
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This change makes several refactors to start supporting
structured fuzzing. The mutator can still only mutate
byte slices, and future changes will be made to support
mutating other types. However, it does now support
fuzzing more than one []byte.
This change also makes it so that corpus entries are
encoded in the new file format when being written to
testdata or GOCACHE. Any existing GOCACHE data should
be deleted from your local workstation to allow tests
to pass locally.
Change-Id: Iab8fe01a5dc870f0c53010b9d5b0b479bbdb310d
Reviewed-on: https://go-review.googlesource.com/c/go/+/293810
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Based on feedback from rsc@, update the version
encoding to more clearly indicate that this is
about fuzzing with Go.
Change-Id: Id95dec8283608779b157bf662e7147f9a9c8dba8
Reviewed-on: https://go-review.googlesource.com/c/go/+/295110
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The test was broken before, but was fixed in
CL 279073, which will be pulled in during our
merge.
Change-Id: I782c49f223eec5f856e4735a6c883f1464be5a57
Reviewed-on: https://go-review.googlesource.com/c/go/+/293842
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
In CL 292109 we removed unnecessary writes to gp.sched.g
but put wrong register to save g (R4 saves pointer to g) on mips64x
Change-Id: I9777846a7b0a46e1af83dcfc73b74649e0dba3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/293989
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Reqs currently combines requirements with upgrades and downgrades.
However, only Upgrade needs the Upgrade method, and only Downgrade
needs the Previous method.
When we eventually add lazy loading, the lazily-loaded module graph
will not be able to compute upgrades and downgrades, so the
implementation work from here to there will be clearer if we are
explicit about which are still needed.
For #36460
Change-Id: I7bf8c2a84ce6bc4ef493a383e3d26850e9a6a6c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/290771
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
It turns out that the existing call sites of the resolveCandidates
method pass only *either* a slice of queries or a slice of upgrades
(never both), and the behaviors triggered by the two parameters don't
overlap much at all. To clarify the two different operations, split
them into two separate methods.
For #36460
Change-Id: I64651637734fd44fea68740a3cdfbacfb73c19b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/289697
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
On my Surface Pro X running the insider preview,
running "netsh help" from Powershell started from the task bar works.
But running "powershell" at a cmd.exe prompt and then running
"netsh help" produces missing DLL errors.
These aren't our fault, so just skip the netsh-based tests if this happens.
Change-Id: I13a17e01143d823d3b5242d827db056bd253e3e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/293849
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
macOS tests have been disabled since CL 12429045 (Aug 2013).
At the time, macOS required a kernel patch to get a working profiler
(https://research.swtch.com/macpprof), which we didn't want
to require, of course.
macOS has improved - it no longer requires the kernel patch - but
we never updated the list of exceptions.
As far as I can tell, the builders have no problem passing the pprof test now.
(It is possible that the iOS builders have trouble, but that is now a different GOOS.)
Remove the exception for macOS. The test should now pass.
Fixes#6047.
Change-Id: Iab49036cacc1025e56f515bd19d084390c2f5357
Reviewed-on: https://go-review.googlesource.com/c/go/+/292229
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The Surface Pro X's 386 simulator is not completely faithful to a real 387.
The most egregious problem is that it computes Log2(8) as 2.9999999999999996,
but it has some other subtler problems as well. All the problems occur in
routines that we don't even bother with assembly for on amd64.
If the speed of Go code is OK on amd64 it should be OK on 386 too.
Just remove all the 386-only assembly functions.
This leaves Ceil, Floor, Trunc, Hypot, and Sqrt in 386 assembly,
all of which are also in assembly on amd64 and all of which pass
their tests on Surface Pro X.
Compared to amd64, the 386 port omits assembly for Min, Max, and Log.
It never had Min and Max, and this CL deletes Log because Log2 wasn't
even correct. (None of the other architectures have assembly Log either.)
Change-Id: I5eb6c61084467035269d4098a36001447b7a0601
Reviewed-on: https://go-review.googlesource.com/c/go/+/291229
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The assembly is mostly a straightforward conversion of the
equivalent arm assembly.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I61b15d712ade4d3a7285c7680de8e0987aacba10
Reviewed-on: https://go-review.googlesource.com/c/go/+/288828
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL adds a few small files - defs, os, and rt0 - to start
on windows/arm64 support for the runtime.
It also copies sys_windows_arm.s to sys_windows_arm64.s,
with the addition of "#ifdef NOT_PORTED" around the entire file.
This is meant to make future CLs easier to review, since the
general pattern is to translate the 32-bit ARM assembly into
64-bit ARM assembly.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I922037eb3890e77bac48281ecaa8e489595675be
Reviewed-on: https://go-review.googlesource.com/c/go/+/288827
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>
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I5e2b589797808626bcca771cdf860d5cb85586cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/288826
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>
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>
This brings in the windows/arm64 support, along with other recent changes.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ifaca710093376c658ecf91239aa05cc33af98a31
Reviewed-on: https://go-review.googlesource.com/c/go/+/288824
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The address space starts at 4GB, so dummy is too far out.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I5f67e268ce729086d9f9fc8541722fabccfd0145
Reviewed-on: https://go-review.googlesource.com/c/go/+/288823
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>
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I397c1d238bb18cbe78b3fca00910660cf1d66b8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288822
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>
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I5ec459063d394b9f434d1b8b5030960b45061038
Reviewed-on: https://go-review.googlesource.com/c/go/+/288821
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>
We still need to add test data, but as yet we haven't identified
a good Windows arm64 compiler to produce small binaries.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ifbecb9a6e25f7af38e20b7d7830df7f5efe2798a
Reviewed-on: https://go-review.googlesource.com/c/go/+/288820
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
- Add Windows SystemInfo constant for arm64
- Add windows/arm64 to GOOS/GOARCH list
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I6109bd87512b5cb1d227d7a85fd0ac20eb2259e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288819
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: Ian Lance Taylor <iant@golang.org>
Katie Hockman
Roland Shoemaker
Jay Conrod
Matthew Dempsky
Meng Zhuo
Bryan C. Mills
Russ Cox