Since CL 130990043, the GOTRACEBACK variable is
only used when the GODEBUG variable is set.
This change restores the original behavior.

LGTM=rsc
R=golang-codereviews, aram, gobot, r, rsc
CC=golang-codereviews
https://golang.org/cl/132520043

In Go 1.3 the runtime called panicstring to report errors like
divide by zero or memory faults. Now we call panic (gopanic)
with pre-allocated error values. That new path is missing the
checking that panicstring did, so add it there.

The only call to panicstring left is in cnew, which is problematic
because if it fails, probably the heap is corrupt. In that case,
calling panicstring creates a new errorCString (no allocation there),
but then panic tries to print it, invoking errorCString.Error, which
does a string concatenation (allocating), which then dies.
Replace that one panicstring with a throw: cnew is for allocating
runtime data structures and should never ask for an inappropriate
amount of memory.

With panicstring gone, delete newErrorCString, errorCString.
While we're here, delete newErrorString, not called by anyone.
(It can't be: that would be C code calling Go code that might
block or grow the stack.)

Found while debugging a malloc corruption.
This resulted in 'panic during panic' instead of a more useful message.

LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/138290045

Fixes #7776.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, r
https://golang.org/cl/145860043

It fails about 25% of the time on OS X.
I don't know what it's trying to do.
Created issue 8764 to correct this, but for now disable.

LGTM=bradfitz, mikioh.mikioh
R=bradfitz, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/144070044

Replace typeLock with copy-on-write map using atomic.Value.

benchmark                               old ns/op     new ns/op     delta
BenchmarkEndToEndPipe                   7722          7709          -0.17%
BenchmarkEndToEndPipe-2                 5114          4344          -15.06%
BenchmarkEndToEndPipe-4                 3192          2429          -23.90%
BenchmarkEndToEndPipe-8                 1833          1438          -21.55%
BenchmarkEndToEndPipe-16                1332          983           -26.20%
BenchmarkEndToEndPipe-32                1444          675           -53.25%
BenchmarkEndToEndByteBuffer             6474          6019          -7.03%
BenchmarkEndToEndByteBuffer-2           4280          2810          -34.35%
BenchmarkEndToEndByteBuffer-4           2264          1774          -21.64%
BenchmarkEndToEndByteBuffer-8           1275          979           -23.22%
BenchmarkEndToEndByteBuffer-16          1257          753           -40.10%
BenchmarkEndToEndByteBuffer-32          1342          644           -52.01%
BenchmarkEndToEndArrayByteBuffer        727725        671349        -7.75%
BenchmarkEndToEndArrayByteBuffer-2      394079        320473        -18.68%
BenchmarkEndToEndArrayByteBuffer-4      211785        178175        -15.87%
BenchmarkEndToEndArrayByteBuffer-8      141003        118857        -15.71%
BenchmarkEndToEndArrayByteBuffer-16     139249        86367         -37.98%
BenchmarkEndToEndArrayByteBuffer-32     144128        73454         -49.04%

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/147720043

Converting an integer to an interface{} allocates as of CL 130240043.

Fixes #8617.

LGTM=r
R=r
CC=golang-codereviews, khr
https://golang.org/cl/141700043

To clarify the dependency of NaCl platform.

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/143830044

It is left from the time when Value was implemented in assembly.
Now it is implemented in Go and race detector understands Go.
In particular the atomic operations must provide
all necessary synchronization.

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews, khr, rsc
https://golang.org/cl/145880043

Example output:
gc26(1): 1+0+1038+0 us, 0 -> 1 MB, 19074 (88777-69703) objects, 5 gs, 184/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields
It's useful to understand long scan times,
because goroutine traceback is slow.

LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/136310044

benchmark                    old ns/op     new ns/op     delta
BenchmarkEncode              8641055       8646829       +0.07%

Fixes #7792.

LGTM=r
R=r
CC=dbathgate, golang-codereviews
https://golang.org/cl/147730043

Generated by a+c.

R=gobot
CC=golang-codereviews
https://golang.org/cl/142200043

We could probably free the G structures as well, but
for the allg list.  Leaving that for another day.

Fixes #8287

LGTM=rsc
R=golang-codereviews, dvyukov, khr, rsc
CC=golang-codereviews
https://golang.org/cl/145010043

The logic here is copied from mgc0.c's scanframe.
Mostly it is messages although the minsize code is new
(and I believe necessary).

I am hoping to get more information about the current
arm build failures (or, if it's the minsize thing, fix them).

TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/143180043

Should fix nacl/arm build.

TBR=minux
CC=golang-codereviews
https://golang.org/cl/145070043

CC=golang-codereviews
https://golang.org/cl/145050043

Fixes #8734.

LGTM=r, bradfitz, dvyukov
R=bradfitz, r, dvyukov
CC=golang-codereviews, iant, khr
https://golang.org/cl/143150043

CC=golang-codereviews
https://golang.org/cl/144050043

It will be 8K on windows because it needs 4K for the OS.
Similarly, plan9 will be 4K.

On linux/amd64, reduces size of 100,000 goroutines
from ~819MB to ~245MB.

Update #7514

LGTM=dvyukov
R=golang-codereviews, dvyukov, khr, aram
CC=golang-codereviews
https://golang.org/cl/145790043

For real this time.

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/141640043

CC=golang-codereviews
https://golang.org/cl/145800043

A Value provides an atomic load and store of a consistently typed value.
It's intended to be used with copy-on-write idiom (see the example).

Performance:
BenchmarkValueRead	50000000	        21.7 ns/op
BenchmarkValueRead-2	200000000	         8.63 ns/op
BenchmarkValueRead-4	300000000	         4.33 ns/op

TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/136710045

The liblink code to insert the FUNCDATA for a stack map
from the Go prototype was not correct for ARM
(different data structure layout).

Also, sync/atomic was missing some Go prototypes
for ARM-specific functions.

TBR=r
CC=golang-codereviews
https://golang.org/cl/143160045

semacquire might need to park the currently running G.  It can
only park if called from the G stack (because it has no way of
saving the M stack state).  So all calls to semacquire must come
from the G stack.

The three violators are GOMAXPROCS, ReadMemStats, and WriteHeapDump.
This change moves the semacquire call earlier, out of their C code
and into their Go code.

This seldom caused bugs because semacquire seldom actually had
to park the caller.  But it did happen intermittently.

Fixes #8749

LGTM=dvyukov
R=golang-codereviews, dvyukov, bradfitz
CC=golang-codereviews
https://golang.org/cl/144940043

CC=golang-codereviews
https://golang.org/cl/138530044

Fixes #8566.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/126210045

Generated by a+c.

R=gobot
CC=golang-codereviews
https://golang.org/cl/138550043

If this needs to be turned back off, it should be done
just before the '// in finalizer' comment, not at the top
of the function.

GC is more precise now than it was (the only imprecise
stuff left is some global variables), so maybe the finalizer
test will work now on 32-bit systems.

LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/144030043

Fixes #6611.

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/14990045

Like most of the Type methods, the definition of Comparable
is what the Go spec says it is.

Fixes #7911.

LGTM=gri
R=gri, r
CC=golang-codereviews
https://golang.org/cl/144020043

If there is a leading ·, assume there is a Go prototype and
attach the Go prototype information to the function.
If the function is not called from Go and does not need a
Go prototype, it can be made file-local instead (using name<>(SB)).

This fixes the current BSD build failures, by giving functions like
sync/atomic.StoreUint32 argument stack map information.

Fixes #8753.

LGTM=khr, iant
R=golang-codereviews, iant, khr, bradfitz
CC=golang-codereviews, r, rlh
https://golang.org/cl/142150043

Follow-up to CL 137350043.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/141620043

This is a corner case, and one that was even tested, but this
CL changes the behavior to say that f is "complete" even if it panics.
But don't think of it that way, think of it as sync.Once runs
the function only the first time it is called, rather than
repeatedly until a run of the function completes.

Fixes #8118.

LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/137350043

LGTM=r
R=r, bradfitz, khr
CC=golang-codereviews
https://golang.org/cl/136660044

Might make test less flaky.
Fixes #8682.

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/143160043

We believe TestSelfConnect can accidentally connect to
something else listening on or dialing from that port.

Fixes #8680.

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews, rlh
https://golang.org/cl/136700043

There's no point in continuing. We will only get confused.
6g already makes this fatal.

LGTM=dave, minux, iant
R=iant, dave, minux
CC=golang-codereviews
https://golang.org/cl/140660043

mark finalizer1 as having no pointers

TBR=iant
CC=golang-codereviews
https://golang.org/cl/141570045

Along with CLs 139610043 and 141490043,
this removes all conservative scanning during
garbage collection, except _cgo_allocate,
which is SWIG-only.

LGTM=rlh, khr
R=golang-codereviews, dvyukov, rlh, khr
CC=golang-codereviews, iant
https://golang.org/cl/144860043

Now it's two allocations. I don't see much downside to that,
since the two pieces were in different cache lines anyway.

Rename 'conservative' to 'cgo_conservative_type' and make
clear that _cgo_allocate is the only allowed user.

This depends on CL 141490043, which removes the other
use of conservative (in defer).

LGTM=dvyukov, iant
R=khr, dvyukov, iant
CC=golang-codereviews, rlh
https://golang.org/cl/139610043

This makes the GC and the stack copying agree about how
to interpret the defer structures. Previously, only the stack
copying treated them precisely.
This removes an untyped memory allocation and fixes
at least three copystack bugs.

To make sure the GC can find the deferred argument
frame until it has been copied, keep a Defer on the defer list
during its execution.

In addition to making it possible to remove the untyped
memory allocation, keeping the Defer on the list fixes
two races between copystack and execution of defers
(in both gopanic and Goexit). The problem is that once
the defer has been taken off the list, a stack copy that
happens before the deferred arguments have been copied
back to the stack will not update the arguments correctly.
The new tests TestDeferPtrsPanic and TestDeferPtrsGoexit
(variations on the existing TestDeferPtrs) pass now but
failed before this CL.

In addition to those fixes, keeping the Defer on the list
helps correct a dangling pointer error during copystack.
The traceback routines walk the Defer chain to provide
information about where a panic may resume execution.
When the executing Defer was not on the Defer chain
but instead linked from the Panic chain, the traceback
had to walk the Panic chain too. But Panic structs are
on the stack and being updated by copystack.
Traceback's use of the Panic chain while copystack is
updating those structs means that it can follow an
updated pointer and find itself reading from the new stack.
The new stack is usually all zeros, so it sees an incorrect
early end to the chain. The new TestPanicUseStack makes
this happen at tip and dies when adjustdefers finds an
unexpected argp. The new StackCopyPoison mode
causes an earlier bad dereference instead.
By keeping the Defer on the list, traceback can avoid
walking the Panic chain at all,  making it okay for copystack
to update the Panics.

We'd have the same problem for any Defers on the stack.
There was only one: gopanic's dabort. Since we are not
taking the executing Defer off the chain, we can use it
to do what dabort was doing, and then there are no
Defers on the stack ever, so it is okay for traceback to use
the Defer chain even while copystack is executing:
copystack cannot modify the Defer chain.

LGTM=khr
R=khr
CC=dvyukov, golang-codereviews, iant, rlh
https://golang.org/cl/141490043