As per iant suggestion during issue #12587 crash investigation.

Also adjust incorrect throw message in sysUsed while we are here.

Change-Id: Ice07904fdd6e0980308cb445965a696d26a1b92e
Reviewed-on: https://go-review.googlesource.com/14633Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The man page for sigaction(2) on OS X doesn't guarantee that SA_RESTART
will work for open(2) on regular files:

    The affected system calls include open(2), read(2), write(2),
    sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a
    communications channel or a slow device (such as a terminal, but not
    a regular file) and during a wait(2) or ioctl(2).

I've never observed EINTR from open(2) for a traditional file system
such as HFS+, but it's easy to observe with a fuse file system that is
slightly slow (cf. https://goo.gl/UxsVgB). After this change, the
problem can no longer be reproduced when calling os.OpenFile.

Fixes #11180.

Change-Id: I967247430e20a7d29a285b3d76bf3498dc4773db
Reviewed-on: https://go-review.googlesource.com/14484Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I81a7f22be827519b5290b4acbcba357680cad3c4
Reviewed-on: https://go-review.googlesource.com/14605Reviewed-by: Rob Pike <r@golang.org>

Not sure how I managed to do this, or get it past review.

Change-Id: I141b97ef8e09dcc9c910c45493a584a3dced2b28
Reviewed-on: https://go-review.googlesource.com/14634Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes 11829.

Change-Id: I2e39f61e12953147b0cd6a11d29179c500c94964
Reviewed-on: https://go-review.googlesource.com/14566Reviewed-by: Chris Manghane <cmang@golang.org>

Fixes #11611.

Change-Id: I63d35cf15c3be759c899e3e561e631330dcc0bbb
Reviewed-on: https://go-review.googlesource.com/14565
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Manghane <cmang@golang.org>

Change-Id: I94af55bb894409b77bd87df36be9471dcc544fda
Reviewed-on: https://go-review.googlesource.com/14627Reviewed-by: Rob Pike <r@golang.org>

Add a Read function to Rand which reads random bytes into a buffer.

Fixes #8330

Change-Id: I85b90277b8be9287c6697def8dbefe0029b6ee06
Reviewed-on: https://go-review.googlesource.com/14522Reviewed-by: Rob Pike <r@golang.org>

Use MOVUPS to zero 16 bytes at a time.

results (haswell):

name             old time/op  new time/op  delta
ClearFat8-48     0.62ns ± 2%  0.62ns ± 1%     ~     (p=0.085 n=20+15)
ClearFat12-48    0.93ns ± 2%  0.93ns ± 2%     ~     (p=0.757 n=19+19)
ClearFat16-48    1.23ns ± 1%  1.23ns ± 1%     ~     (p=0.896 n=19+17)
ClearFat24-48    1.85ns ± 2%  1.84ns ± 0%   -0.51%  (p=0.023 n=20+15)
ClearFat32-48    2.45ns ± 0%  2.46ns ± 2%     ~     (p=0.053 n=17+18)
ClearFat40-48    1.99ns ± 0%  0.92ns ± 2%  -53.54%  (p=0.000 n=19+20)
ClearFat48-48    2.15ns ± 1%  0.92ns ± 2%  -56.93%  (p=0.000 n=19+20)
ClearFat56-48    2.46ns ± 1%  1.23ns ± 0%  -49.98%  (p=0.000 n=19+14)
ClearFat64-48    2.76ns ± 0%  2.14ns ± 1%  -22.21%  (p=0.000 n=17+17)
ClearFat128-48   5.21ns ± 0%  3.99ns ± 0%  -23.46%  (p=0.000 n=17+19)
ClearFat256-48   10.3ns ± 4%   7.7ns ± 0%  -25.37%  (p=0.000 n=20+17)
ClearFat512-48   20.2ns ± 4%  15.0ns ± 1%  -25.58%  (p=0.000 n=20+17)
ClearFat1024-48  39.7ns ± 2%  29.7ns ± 0%  -25.05%  (p=0.000 n=19+19)

Change-Id: I200401eec971b2dd2450c0651c51e378bd982405
Reviewed-on: https://go-review.googlesource.com/14408Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

IEEE is the most commonly used CRC-32 polynomial, used by zip, gzip and others.

Based on http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-crc-computation-generic-polynomials-pclmulqdq-paper.pdf

benchmark                       old ns/op     new ns/op     delta
BenchmarkIEEECrc1KB-8           3193          352           -88.98%
BenchmarkIEEECrc4KB-8           5025          1307          -73.99%
BenchmarkCastagnoliCrc1KB-8     126           126           +0.00%

benchmark                       old MB/s     new MB/s     speedup
BenchmarkIEEECrc1KB-8           320.68       2901.92      9.05x
BenchmarkIEEECrc4KB-8           815.08       3131.80      3.84x
BenchmarkCastagnoliCrc1KB-8     8100.80      8109.78      1.00x

Change-Id: I99c9a48365f631827f516e44f97e86155f03cb90
Reviewed-on: https://go-review.googlesource.com/14080Reviewed-by: Keith Randall <khr@golang.org>

Fixes #12642

Change-Id: I0b94437055b7d444f5caf7ea310e85357c467bdf
Reviewed-on: https://go-review.googlesource.com/14612Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #12363

Change-Id: I1a025ab6a1cbd5a58f5c2bce5416788387495428
Reviewed-on: https://go-review.googlesource.com/14604Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The _rt0_arm_darwin_lib entrypoint has to conform to the darwin ARMv7
calling convention, which requires functions to preserve the value of
R11. Go uses R11 as the liblink REGTMP register, so save it manually.

Also avoid using R4, which is also callee-save.

Fixes #12590

Change-Id: I9c3b374e330f81ff8fc9c01fa20505a33ddcf39a
Reviewed-on: https://go-review.googlesource.com/14603Reviewed-by: Ian Lance Taylor <iant@golang.org>

recover4 allocates 16 pages of memory via mmap, makes a 4 page hole in it with
munmap, allocates another 16 pages of memory via normal allocation and then
tries to copy from one to the other. For some reason on arm64 (but no other
platform I have tested) the second allocation sometimes causes the runtime to
ask the kernel for 4 additional pages of memory -- which the kernel satisfies
by remapping the pages that were just unmapped!

Moving the second allocation before the munmap fixes this behaviour, I can run
recover4 tens of thousands of times without failure with this fix vs a failure
rate of ~0.5% before.

Fixes #12549

Change-Id: I490b895b606897e4f7f25b1b51f5d485a366fffb
Reviewed-on: https://go-review.googlesource.com/14632Reviewed-by: Dave Cheney <dave@cheney.net>

Found with https://github.com/remyoudompheng/go-misc/deadcode:

deadcode: walk.go:2228:1: applywritebarrier_bv is unused
deadcode: subr.go:355:1: gethunk is unused
deadcode: subr.go:1991:1: localexpr is unused
deadcode: dcl.go:82:1: poptodcl is unused
deadcode: swt.go:810:1: dumpcase is unused
deadcode: esc.go:251:1: satAdd8 is unused
deadcode: esc.go:387:1: outputsPerTag is unused
deadcode: obj.go:190:1: duint64 is unused
deadcode: obj.go:287:1: dstringptr is unused
deadcode: plive.go:95:1: xmalloc is unused
deadcode: plive.go:119:1: freeblock is unused

followed by

deadcode: go.go:633:1: hunk is unused
deadcode: go.go:635:1: nhunk is unused
deadcode: go.go:637:1: thunk is unused

after 'gethunk' was removed.

Some dead code in bv.go, mparith3.go, and dcl.go was left as is.

Passes go build -a -toolexec 'toolstash -cmp' std cmd.

Change-Id: Ia63519adedc8650d7095572ddd454fd923d3204d
Reviewed-on: https://go-review.googlesource.com/14610Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Remove several uses of stringsCompare.

Passes go build -a -toolexec 'toolstash -cmp' std cmd.

Change-Id: I3f2323df2ad8c03bad77e0a91d6e2e714803705b
Reviewed-on: https://go-review.googlesource.com/14556Reviewed-by: Dave Cheney <dave@cheney.net>

Fixes #12629.

Change-Id: Iee96dc4f806a38f3cd8e065b8d0d5f682bb7e29b
Reviewed-on: https://go-review.googlesource.com/14597Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This has been the root cause of a number of crashes caused by
fuzz throwing modem noise at the assembler, which in turn attempts
to print diagnostics but instead just gets crashes.

Fixes #12627.

Change-Id: I72c2da79d8eb240e1a37aa6140454c552b05e0f1
Reviewed-on: https://go-review.googlesource.com/14595Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #11600.

Change-Id: I8871d4e525168fed35115855483a237bbd6e5445
Reviewed-on: https://go-review.googlesource.com/14596Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

This adds a test that debug/dwarf can read the skeleton DWARF data
from a split DWARF image (though it doesn't currently support piecing
the external DWARF data back together). This should work because
there's nothing particularly different about skeleton DWARF data, but
previously failed because of poor handling of unrecognized attributes.

Updates #12592.

Change-Id: I2fc5f4679883b05ebd7ec9f0b5c398a758181a32
Reviewed-on: https://go-review.googlesource.com/14542Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: jcd . <jcd@golang.org>

Currently, if the .debug_abbrev section of an ELF file contains
attributes that aren't known to the dwarf package and that have form
formSecOffset, the dwarf package will fail to open the DWARF data with
an error like "decoding dwarf section abbrev at offset 0x17: cannot
determine class of unknown attribute with formSecOffset". For the most
part, the class is implied by the form encoded in the abbrev section,
but formSecOffset can imply many different DWARF classes. Hence,
debug/dwarf disambiguates these using a table of known attributes.
However, it will reject the entire image if it encounters an attribute
it can't determine the class of. This is particularly unfortunate
because the caller may never even uses the offending attribute.

Fix this by introducing a ClassUnknown attribute class to use as a
fallback in these cases. This allows the dwarf package to load the
DWARF data and isolates the problem to just the affected attributes.

Fixes #12592.

Change-Id: I766227b136e9757f8b89c0b3ab8e9ddea899d94f
Reviewed-on: https://go-review.googlesource.com/14541Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: jcd . <jcd@golang.org>

The current code prints an error message and then tries to carry on.
This is not helpful for Go users: they see a message that means
nothing and that they can do nothing about.  In the only known case of
this message, in issue 11498, the best guess is that the netpoll code
went into an infinite loop.  Instead of doing that, crash the program.

Fixes #11498.

Change-Id: Idda3456c5b708f0df6a6b56c5bb4e796bbc39d7c
Reviewed-on: https://go-review.googlesource.com/12047Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Aeshash currently computes the hash of the empty string as
hash("", seed) = seed.  This is bad because the hash of a compound
object with empty strings in it doesn't include information about
where those empty strings were.  For instance [2]string{"", "foo"}
and [2]string{"foo", ""} might get the same hash.

Fix this by returning a scrambled seed instead of the seed itself.
With this fix, we can remove the scrambling done by the generated
array hash routines.

The test also rejects hash("", seed) = 0, if we ever thought
it would be a good idea to try that.

The fallback hash is already OK in this regard.

Change-Id: Iaedbaa5be8d6a246dc7e9383d795000e0f562037
Reviewed-on: https://go-review.googlesource.com/14129Reviewed-by: jcd . <jcd@golang.org>

Updates #11241

Change-Id: If71f651f3b8aca432c91314358b93f195217d9ec
Reviewed-on: https://go-review.googlesource.com/14317Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: I7de85034d499a9f859ab37d56463073f5cb29b35
Reviewed-on: https://go-review.googlesource.com/14592Reviewed-by: Rob Pike <r@golang.org>

More protection against random input bytes.

Fixes #12614.

Change-Id: Ie9f817de1376a10bb80b22ecee3bae4f1d26cc6c
Reviewed-on: https://go-review.googlesource.com/14563Reviewed-by: Andrew Gerrand <adg@golang.org>

There was no verification in Funcs that the map had valid names,
which meant that the error could only be caught when parsing
the template that tried to use them. Fix this by validating the names
in Funcs and panicking before parsing if there is a bad name.

This is arguably an API change, since it didn't trigger a panic
before, but Funcs did already panic if the function itself was no
good, so I argue it's an acceptable change to add more sanity
checks.

Fixes #9685.

Change-Id: Iabf1d0602c49d830f3ed71ca1ccc7eb9a5521ff5
Reviewed-on: https://go-review.googlesource.com/14562Reviewed-by: Andrew Gerrand <adg@golang.org>

Cleaning along the way:
-convert variable types from int to bool
-remove unnecessary functions
-remove unnecessary type conversion
-remove unnecessary variable declarations
-transform struct{string,string} with lookup to map[string]string

This change passes go build -toolexec 'toolstash -cmp' -a std.

Change-Id: I259728fe4afd7f23b67f08fab856ce0abee57b21
Reviewed-on: https://go-review.googlesource.com/14435Reviewed-by: Ian Lance Taylor <iant@golang.org>

They added no value.

Change-Id: I9e690379d2dfd983266de0ea5231f2b57c8b1517
Reviewed-on: https://go-review.googlesource.com/14568Reviewed-by: Ian Lance Taylor <iant@golang.org>

CL 13166 skipped external tests on freebsd/arm with the rationale
that the cmd/go tests are not architecture dependent.

This CL does the same for linux/arm to help linux/arm users who are
building Go on platforms like the Raspberry Pi where ./all.bash
frequently times out due to a lack of resources.

Change-Id: Iae1a25b63b74200da3f1b5637da0fa5c2dceeb83
Reviewed-on: https://go-review.googlesource.com/13342Reviewed-by: Ian Lance Taylor <iant@golang.org>

Windows amd64 requires all syscall callers to provide room for first
4 parameters on stack. We do that for all our syscalls, except inside
of usleep2. In https://codereview.appspot.com/7563043#msg3 rsc says:

"We don't need the stack alignment and first 4 parameters on amd64
because it's just a system call, not an ordinary function call."

He seems to be wrong on both counts. But alignment is already fixed.
Fix parameter space now too.

Fixes #12444

Change-Id: I66a2a18d2f2c3846e3aa556cc3acc8ec6240bea0
Reviewed-on: https://go-review.googlesource.com/14282Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #12437.

Change-Id: I5463970a6259527003eb0e12903a338cc78e0683
Reviewed-on: https://go-review.googlesource.com/14564Reviewed-by: Chris Manghane <cmang@golang.org>

Glibc uses some special signals for special thread operations.  These
signals will be used in programs that use cgo and invoke certain glibc
functions, such as setgid.  In order for this to work, these signals
need to not be masked by any thread.  Before this change, they were
being masked by programs that used os/signal.Notify, because it
carefully masks all non-thread-specific signals in all threads so that a
dedicated thread will collect and report those signals (see ensureSigM
in signal1_unix.go).

This change adds the two glibc special signals to the set of signals
that are unmasked in each thread.

Fixes #12498.

Change-Id: I797d71a099a2169c186f024185d44a2e1972d4ad
Reviewed-on: https://go-review.googlesource.com/14297Reviewed-by: David Crawshaw <crawshaw@golang.org>

This puts the _Root* indexes in a more friendly order and tweaks
markrootSpans to use a for-range loop instead of its own indexing.

Change-Id: I2c18d55c9a673ea396b6424d51ef4997a1a74825
Reviewed-on: https://go-review.googlesource.com/14548Reviewed-by: Rick Hudson <rlh@golang.org>

Commit 0e6a6c51 removed readyExecute a long time ago, but left behind
the g.readyg field that was used by readyExecute. Remove this now
unused field.

Change-Id: I41b87ad2b427974d256ec7a7f6d4bdc2ce8a13bb
Reviewed-on: https://go-review.googlesource.com/13111Reviewed-by: Rick Hudson <rlh@golang.org>

This is a cleanup following cc8f5441, which was a minimal change to fix
issue #11617. This consolidates the two places in mSpan_Sweep that
update sweepgen. Previously this was necessary because sweepgen must
be updated before freeing the span, but we freed large spans early.
Now we free large spans later, so there's no need to duplicate the
sweepgen update. This also means large spans can take advantage of the
sweepgen sanity checking performed for other spans.

Change-Id: I23b79dbd9ec81d08575cd307cdc0fa6b20831768
Reviewed-on: https://go-review.googlesource.com/12451Reviewed-by: Rick Hudson <rlh@golang.org>

Marking of span roots can represent a significant fraction of the time
spent in mark termination. Simply traversing the span list takes about
1ms per GB of heap and if there are a large number of finalizers (for
example, for network connections), it may take much longer.

Improve the situation by splitting the span scan into 128 subtasks
that can be executed in parallel and load balanced by the markroots
parallel for. This lets the GC balance this job across the Ps.

A better solution is to do this during concurrent mark, or to improve
it algorithmically, but this is a simple change with a lot of bang for
the buck.

This was suggested by Rhys Hiltner.

Updates #11485.

Change-Id: I8b281adf0ba827064e154a1b6cc32d4d8031c03c
Reviewed-on: https://go-review.googlesource.com/13112Reviewed-by: Keith Randall <khr@golang.org>

The call to hash the trace stack reversed the "seed" and "size"
arguments to memhash and, hence, always called memhash with a 0 size,
which dutifully returned a hash value that depended only on the number
of PCs in the stack and not their values. As a result, all stacks were
put in to a very subset of the 8,192 buckets.

Fix this by passing these arguments in the correct order.

Change-Id: I67cd29312f5615c7ffa23e205008dd72c6b8af62
Reviewed-on: https://go-review.googlesource.com/13613Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Passes go build -a -toolexec 'toolstash -cmp' std cmd

Change-Id: Ief4613cfb341172a85e3a894f44fb2bb308c7b55
Reviewed-on: https://go-review.googlesource.com/14554
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>

Fixes #12606

Change-Id: Ib68cb20108ad35c3dd96e606649c4c8f9c0f085c
Reviewed-on: https://go-review.googlesource.com/14571Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>