Commit to stack copying for stack growth.

We're carrying around a surprising amount of cruft from older schemes.
I am confident that precise stack scans and stack copying are here to stay.

Delete fallback code for when precise stack info is disabled.
Delete fallback code for when copying stacks is disabled.
Delete fallback code for when StackCopyAlways is disabled.
Delete Stktop chain - there is only one stack segment now.
Delete M.moreargp, M.moreargsize, M.moreframesize, M.cret.
Delete G.writenbuf (unrelated, just dead).
Delete runtime.lessstack, runtime.oldstack.
Delete many amd64 morestack variants.
Delete initialization of morestack frame/arg sizes (shortens split prologue!).

Replace G's stackguard/stackbase/stack0/stacksize/
syscallstack/syscallguard/forkstackguard with simple stack
bounds (lo, hi).

Update liblink, runtime/cgo for adjustments to G.

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

I have found better approach, then longer wait.
See CL 134360043 for details.

««« original CL description
runtime/pprof: adjust cpuHogger so that tests pass on windows builders

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

»»»

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

I assumed they were the same when I wrote
cgocallback.go earlier today. Merge them
to eliminate confusion.

I can't tell what gomallocgc did before with
a nil type but without FlagNoScan.
I created a call like that in cgocallback.go
this morning, translating from a C file.
It was supposed to do what the C version did,
namely treat the block conservatively.
Now it will.

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

It already is updating parts of them; we're just getting lucky
retraversing them and not finding much to do.
Change argp to a pointer so that it will be updated too.
Existing tests break if you apply the change to adjustpanics
without also updating the type of argp.

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

Like https://golang.org/cl/139360044

LGTM=rsc, alex.brainman
R=alex.brainman, rsc
CC=golang-codereviews
https://golang.org/cl/138250043

This change brings the iter/delete pattern down to O(n lgn) from O(n^2).

Fixes #8412.

before:
BenchmarkMapPop100	   50000	     32498 ns/op
BenchmarkMapPop1000	     500	   3244851 ns/op
BenchmarkMapPop10000	       5	 270276855 ns/op

after:
BenchmarkMapPop100	  100000	     16169 ns/op
BenchmarkMapPop1000	    5000	    300416 ns/op
BenchmarkMapPop10000	     300	   5990814 ns/op

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

src/pkg -> src

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

It worked at CL 134660043 on the builders,
so I believe it will stick this time.

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

Generated by a+c.

LGTM=jtolds, jbd
R=gobot, jbd, jtolds
CC=golang-codereviews
https://golang.org/cl/137300043

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

Fixes #8679.

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

windows/amd64 failure:
http://build.golang.org/log/1ded5e3ef4bd1226f976e3180772f87e6c918255

# ..\misc\cgo\testso
runtime: copystack: locals size info only for syscall.Syscall
fatal error: split stack not allowed

runtime stack:
runtime.throw(0xa64cc7)
        c:/go/src/runtime/panic.go:395 +0xad fp=0x6fde0 sp=0x6fdb0
runtime.newstack()
        c:/go/src/runtime/stack.c:1001 +0x750 fp=0x6ff20 sp=0x6fde0
runtime.morestack()
        c:/go/src/runtime/asm_amd64.s:306 +0x73 fp=0x6ff28 sp=0x6ff20

goroutine 1 [stack growth, locked to thread]:
runtime.freedefer(0xc0820ce120)
        c:/go/src/runtime/panic.go:162 fp=0xc08201b1a0 sp=0xc08201b198
runtime.deferreturn(0xa69420)
        c:/go/src/runtime/panic.go:211 +0xa8 fp=0xc08201b1e8 sp=0xc08201b1a0
runtime.cgocall_errno(0x498c00, 0xc08201b228, 0x0)
        c:/go/src/runtime/cgocall.go:134 +0x10e fp=0xc08201b210 sp=0xc08201b1e8
syscall.Syscall(0x7786b1d0, 0x2, 0xc0820c85b0, 0xc08201b2d8, 0x0, 0x0, 0x0, 0x0)
        c:/go/src/runtime/syscall_windows.c:74 +0x3c fp=0xc08201b260 sp=0xc08201b210
syscall.findFirstFile1(0xc0820c85b0, 0xc08201b2d8, 0x500000000000000, 0x0, 0x0)
        c:/go/src/syscall/zsyscall_windows.go:340 +0x76 fp=0xc08201b2b0 sp=0xc08201b260
syscall.FindFirstFile(0xc0820c85b0, 0xc08210c500, 0xc0820c85b0, 0x0, 0x0)
        c:/go/src/syscall/syscall_windows.go:907 +0x6a fp=0xc08201b530 sp=0xc08201b2b0
os.openDir(0xc0820b2e40, 0x33, 0x0, 0x0, 0x0)
        c:/go/src/os/file_windows.go:96 +0x110 fp=0xc08201b5e0 sp=0xc08201b530
os.OpenFile(0xc0820b2e40, 0x33, 0x0, 0x0, 0x41, 0x0, 0x0)
        c:/go/src/os/file_windows.go:143 +0x1e9 fp=0xc08201b650 sp=0xc08201b5e0

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

Should help windows/amd64.

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

Inside a control clause (if ... {}), composite
literals starting with a type name must be parenthesized.
A composite literal used in the array length expression
of an array composite literal is already parenthesized.
Not a valid program, but syntactically is should
be accepted.

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

This should make deferreturn nosplit all the way down,
which should fix the current windows/amd64 failure.
If not, I will change StackCopyAlways back to 0.

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

Fixes #8674.

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

Let's see how close we are to this being ready.
Will roll back if it breaks any builds in non-trivial ways.

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

Was having serious editor problems on Windows.

TBR=brainman, iant
CC=golang-codereviews
https://golang.org/cl/137370043

Given:

        p := alloc()
        fn_taking_ptr(p)

p is NOT recorded as live at the call to fn_taking_ptr:
it's not needed by the code following the call.
p was passed to fn_taking_ptr, and fn_taking_ptr must keep
it alive as long as it needs it.
In practice, fn_taking_ptr will keep its own arguments live
for as long as the function is executing.

But if instead you have:

        p := alloc()
        i := uintptr(unsafe.Pointer(p))
        fn_taking_int(i)

p is STILL NOT recorded as live at the call to fn_taking_int:
it's not needed by the code following the call.
fn_taking_int is responsible for keeping its own arguments
live, but fn_taking_int is written to take an integer, so even
though fn_taking_int does keep its argument live, that argument
does not keep the allocated memory live, because the garbage
collector does not dereference integers.

The shorter form:

        p := alloc()
        fn_taking_int(uintptr(unsafe.Pointer(p)))

and the even shorter form:

        fn_taking_int(uintptr(unsafe.Pointer(alloc())))

are both the same as the 3-line form above.

syscall.Syscall is like fn_taking_int: it is written to take a list
of integers, and yet those integers are sometimes pointers.
If there is no other copy of those pointers being kept live,
the memory they point at may be garbage collected during
the call to syscall.Syscall.

This is happening on Solaris: for whatever reason, the timing
is such that the garbage collector manages to free the string
argument to the open(2) system call before the system call
has been invoked.

Change the system call wrappers to insert explicit references
that will keep the allocations alive in the original frame
(and therefore preserve the memory) until after syscall.Syscall
has returned.

Should fix Solaris flakiness.

This is not a problem for cgo, because cgo wrappers have
correctly typed arguments.

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

The sighander has been run at the bottom of the
currently executing goroutine stack, but it's in C,
and we don't want C on our ordinary goroutine stacks.
Worse, it does a lot of stuff, and it might need more
stack space. There is scary code in traceback_windows.go
that talks about stack splits during sighandler.
Moving sighandler to g0 will eliminate the possibility
of stack splits and such, and then we can delete
traceback_windows.go entirely. Win win.

On the builder, all.bat passes with GOARCH=amd64
and all.bat gets most of the way with GOARCH=386
except for a DLL-loading test that I think is unrelated.

Fixes windows build.

TBR=brainman, iant
CC=golang-codereviews
https://golang.org/cl/140380043

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

This CL contains compiler+runtime changes that detect C code
running on Go (not g0, not gsignal) stacks, and it contains
corrections for what it detected.

The detection works by changing the C prologue to use a different
stack guard word in the G than Go prologue does. On the g0 and
gsignal stacks, that stack guard word is set to the usual
stack guard value. But on ordinary Go stacks, that stack
guard word is set to ^0, which will make any stack split
check fail. The C prologue then calls morestackc instead
of morestack, and morestackc aborts the program with
a message about running C code on a Go stack.

This check catches all C code running on the Go stack
except NOSPLIT code. The NOSPLIT code is allowed,
so the check is complete. Since it is a dynamic check,
the code must execute to be caught. But unlike the static
checks we've been using in cmd/ld, the dynamic check
works with function pointers and other indirect calls.
For example it caught sigpanic being pushed onto Go
stacks in the signal handlers.

Fixes #8667.

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

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

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

Fixes warning

# _/home/dfc/go/misc/cgo/test/backdoor
/home/dfc/go/src/cmd/cc/bv.c:43:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'

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

Fixes warning

/home/dfc/go/src/cmd/gc/subr.c:3469:8: runtime error: negation of -9223372036854775808 cannot be represented in type 'int64' (aka 'long'); cast to an unsigned type to negate this value to itself

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

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

These were missed in CL 134570043.

Fixes nacl, solaris builds.

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

Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.

This CL adjusts code referring to src/pkg to refer to src.

Immediately after submitting this CL, I will submit
a change doing 'hg mv src/pkg/* src'.
That change will be too large to review with Rietveld
but will contain only the 'hg mv'.

This CL will break the build.
The followup 'hg mv' will fix it.

For more about the move, see golang.org/s/go14nopkg.

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

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

Per discussions out of https://golang.org/cl/128930043/
and golang-nuts threads and with agl.

Fixes #8522

LGTM=agl, adg
R=agl, c, adg
CC=c, golang-codereviews
https://golang.org/cl/137940043

These all used a C implementation that contained 64-bit divide by 1000000000.
On 32-bit systems that ends up in the 64-bit C divide support, which makes
other calls and ends up using a fair amount of stack. We could convert them
to Go but then they'd still end up in software 64-bit divide code. That would
be okay, because Go code can split the stack, but it's still unnecessary.

Write time·now in assembly, just like on all the other systems, and use the
actual hardware support for 64/32 -> 64/32 division. This cuts the software
routines out entirely.

The actual code to do the division is copied and pasted from the sys_darwin_*.s files.

LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=aram, golang-codereviews, iant, khr, r
https://golang.org/cl/136300043

Now it's failing on Windows:

panic: httptest: failed to listen on a port: listen tcp 127.0.0.1:0:
listen: An operation on a socket could not be performed because the
system lacked sufficient buffer space or because a queue was full.

Since we can't seem to understand what the test is trying to test,
and because it is causing problems on multiple systems,
delete it.

Fixes #7264.

TBR=bradfitz
CC=brainman, golang-codereviews
https://golang.org/cl/141210043

This is what broke the build at
http://build.golang.org/log/d9c6d334be16cbab85e99fddc6b4ba034319bd4e

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

I am seeing deadlocks waiting on <-inHandler.
It seems to me that there is no guarantee that the
handler actually runs, if the client does

        write header
        close connection

fast enough. The server might see the EOF on the
connection before it manages to invoke the handler.

This change fixes the deadlock, but it may make
the test not actually test anything. Not sure.

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

This is one of those "how did this ever work?" bugs.
The current build failures are happening because
a fault comes up while executing on m->curg on a
system-created thread using an m obtained from needm,
but TLS is set to m->g0, not m->curg. On fault,
sigtramp starts executing, assumes r10 (g) might be
incorrect, reloads it from TLS, and gets m->g0, not
m->curg. Then sighandler dutifully pushes a call to
sigpanic onto the stack and returns to it.
We're now executing on the m->curg stack but with
g=m->g0. Sigpanic does a stack split check, sees that
the SP is not in range (50% chance depending on relative
ordering of m->g0's and m->curg's stacks), and then
calls morestack. Morestack sees that g=m->g0 and
crashes the program.

The fix is to replace every change of g in asm_arm.s
with a call to a function that both updates g and
saves the updated g to TLS.

Why did it start happening? That's unclear.
Unfortunately there were other bugs in the initial
checkin that mask exactly which of a sequence of
CLs started the behavior where sigpanic would end
up tripping the stack split.

Fixes arm build.
Fixes #8675.

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

Maybe will help us understand Solaris build failure.

TBR=aram
CC=golang-codereviews
https://golang.org/cl/139290043

Fixes arm build.

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

The Unix make.bash builds cmd/dist from *.c.
make.bat apparently does not.

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