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

The C header files are the single point of truth:
every C enum constant Foo is available to Go as _Foo.
Remove or redirect duplicate Go declarations so they
cannot be out of sync.

Eventually we will need to put constants in Go, but for now having
them be out of sync with C is too risky. These predate the build
support for auto-generating Go constants from the C definitions.

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

Fixes #8196.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/141510044

Fixes #8317.

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

It is more useful to report all the errors instead of just the first.

LGTM=dave, khr
R=khr, dave
CC=golang-codereviews
https://golang.org/cl/143940043

Fixes #7626.

LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/144870045

Document that the package cache has
an issue (8425) to speed up future
debugging.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/143980043

Make sure Goexit runs defers.
Make sure recover() during a Goexit defer returns nil.

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

Fixes #8736.

LGTM=iant, josharian
R=golang-codereviews, iant, josharian
CC=golang-codereviews
https://golang.org/cl/144910044

iterdelete's run time varies; occasionally we get unlucky. To reduce spurious failures, average away some of the variation.

On my machine, 8 of 5000 runs (0.15%) failed before this CL. After this CL, there were no failures after 35,000 runs.

I confirmed that this adjusted test still fails before CL 141270043.

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

During anylit run, nodes such as SLICEARR(statictmp, [:])
may be generated and are expected to be found unchanged by
gen_as_init.

In some walks (in particular walkselect), the statement
may be walked again and lowered to its usual form, leading to a
crash.

Fixes #8017.
Fixes #8024.
Fixes #8058.

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

Previously it might happen before calling dowidth and
result in a compiler crash.

Fixes #8060.

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

Fixes #8722

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

I have made mistake while converting it to Go (CL 132820043).
Added test as penance for my sin.

LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/136560043

Fixes sporadic linux/386 build failure (untyped args)
and probably some others we haven't observed yet.

Fixes #8727.

TBR=iant
R=golang-codereviews
CC=bradfitz, golang-codereviews, iant, khr, r
https://golang.org/cl/143930043

This file was already assigned to another CL
so it didn't make it into the build fix CL. Sigh.

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

CL 144830043 changed LibCall for Windows.
I didn't realize Solaris used it too.

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

This is necessary because syscall.Syscall blocks, and the
garbage collector needs to be able to scan that frame while
it is blocked, and C frames have no garbage collection
information.

Windows builders are broken now due to this problem:
http://build.golang.org/log/152ca9a4be6783d3a8bf6e2f5b9fc265089728b6

LGTM=alex.brainman
R=alex.brainman
CC=golang-codereviews
https://golang.org/cl/144830043

Fixes #8693.

LGTM=crawshaw
R=crawshaw
CC=golang-codereviews
https://golang.org/cl/141470043

The merged traceback was wrong for LR machines,
because traceback didn't pass lr to gentraceback.
Now that we have a test looking at traceback output
for a trap (the test of runtime.Breakpoint),
we caught this.

While we're here, fix a 'set and not used' warning.

Fixes arm build.

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

It doesn't.
Fixes 386 build.

While we're here, mark runtime.asmcgocall as GO_ARGS,
so that it will work with stack copying. I don't think anything
that uses it can lead to a stack copy, but better safe than sorry.
Certainly the runtime.asmcgocall_errno variant needs
(and already has) GO_ARGS.

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

http://build.golang.org/log/0434a945e3351eedaf56aa824d2bfe9c0d5e6735

LGTM=dave
R=bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/144800043

The behavior was fixed in CL 141270043. Add a test.

Fixes #8410.

LGTM=khr
R=khr, remyoudompheng
CC=golang-codereviews
https://golang.org/cl/137560044

Instrument dst argument of writebarrier calls.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/139560045

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

No impact on formatting on our repos.

Fixes #8021.

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

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

The argsize PCDATA was specifying the number of
bytes passed to a function call, so that if the function
did not specify its argument count, the garbage collector
could use the call site information to scan those bytes
conservatively. We don't do that anymore, so stop
generating the information.

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

The goal here is to commit fully to having precise information
about stack frames. If we need information we don't have,
crash instead of assuming we should scan conservatively.

Since the stack copying assumes fully precise information,
any crashes during garbage collection that are introduced by
this CL are crashes that could have happened during stack
copying instead. Those are harder to find because stacks are
copied much less often than the garbage collector is invoked.

In service of that goal, remove ARGSIZE macros from
asm_*.s, change switchtoM to have no arguments
(it doesn't have any live arguments), and add
args and locals information to some frames that
can call back into Go.

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

Dmitriy changed all the execution to interpret the BitVector
as an array of bytes. Update the declaration and generation
of the bitmaps to match, to avoid problems on big-endian
machines.

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

makeFuncStub and methodValueStub are used by reflect as
generic function implementations. Each call might have
different arguments. Extract those arguments from the
closure data instead of assuming it is the same each time.

Because the argument map is now being extracted from the
function itself, we don't need the special cases in reflect.Call
anymore, so delete those.

Fixes an occasional crash seen when stack copying does
not update makeFuncStub's arguments correctly.

Will also help make it safe to require stack maps in the
garbage collector.

Derived from CL 142000044 by khr.

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

The pid field in the Tos structure is a 32-bit value.
Loading a 64-bit word also brings in the next field
which is used for the profiling clock.

LGTM=0intro, aram
R=rsc, 0intro, aram
CC=golang-codereviews, mischief
https://golang.org/cl/139560044

That's what defines GO_ARGS.

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

Before, Syscall and friends were having their arguments
treated conservatively. Now they will use the Go prototype,
which will mean the arguments are not considered pointers
at all.

This is safe because of CL 139360044.

The fact that all these non-Solaris systems were using
conservative scanning of the Syscall arguments is why
the failure that prompted CL 139360044 was only
observed on Solaris, which does something completely different.
If we'd done this earlier, we'd have seen the Solaris
failure in more places.

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

The goal here is to allow assembly functions to appear in the middle
of a Go stack (having called other code) and still record enough information
about their pointers so that stack copying and garbage collection can handle
them precisely. Today, these frames are handled only conservatively.

If you write

        func myfunc(x *float64) (y *int)

(with no body, an 'extern' declaration), then the Go compiler now emits
a liveness bitmap for use from the assembly definition of myfunc.
The bitmap symbol is myfunc.args_stackmap and it contains two bitmaps.
The first bitmap, in effect at function entry, marks all inputs as live.
The second bitmap, not in effect at function entry, marks the outputs
live as well.

In funcdata.h, define new assembly macros:

GO_ARGS opts in to using the Go compiler-generated liveness bitmap
for the current function.

GO_RESULTS_INITIALIZED indicates that the results have been initialized
and need to be kept live for the remainder of the function; it causes a
switch to the second generated bitmap for the assembly code that follows.

NO_LOCAL_POINTERS indicates that there are no pointers in the
local variables being stored in the function's stack frame.

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

Tests will come in a separate CL after the funcdata stuff is resolved.

Update #8696

LGTM=iant, rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/138330045