syscall: keep Windows syscall pointers live too

Like https://codereview.appspot.com/139360044

LGTM=rsc, alex.brainman
R=alex.brainman, rsc
CC=golang-codereviews
https://codereview.appspot.com/138250043
runtime: let stack copier update Panic structs for us

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://codereview.appspot.com/139380043
runtime: merge mallocgc, gomallocgc

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://codereview.appspot.com/141810043
undo CL 140110043 / 17b5fc2aa130

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://codereview.appspot.com/140110043

Committer: Russ Cox <rsc@golang.org>
»»»

LGTM=dave
R=golang-codereviews, dave, dvyukov
CC=golang-codereviews
https://codereview.appspot.com/133500043
runtime: assume precisestack, copystack, StackCopyAlways, ScanStackByFrames

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://codereview.appspot.com/137410043
runtime: fix build failures after CL 137410043

No promise about correctness, but they do build.

TBR=khr
CC=golang-codereviews
https://codereview.appspot.com/143720043
strconv: fix documentation for CanBackquote.
Space is not a control character.

Fixes issue 8571.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/137380043
fmt: fix allocation test
With new interface allocation rules, the old counts were wrong and
so was the commentary.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/142760044
testing: read coverage counters atomically
For -mode=atomic, we need to read the counters
using an atomic load to avoid a race. Not worth worrying
about when -mode=atomic is set during generation
of the profile, so we use atomic loads always.

Fixes issue 8630.

LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://codereview.appspot.com/141800043
runtime: avoid read overrun in heapdump

Start the stack a few words below the actual top, so that
if something tries to read goexit's caller PC from the stack,
it won't fault on a bad memory address.
Today, heapdump does that.
Maybe tomorrow, traceback or something else will do that.
Make it not a bug.

TBR=khr
R=khr
CC=golang-codereviews
https://codereview.appspot.com/136450043
runtime: fix windows/386 build

The difference between the old and the new (from earlier) code
is that we set stackguard = stack.lo + StackGuard, while the old
code set stackguard = stack.lo. That 512 bytes appears to be
the difference between the profileloop function running and not running.

We don't know how big the system stack is, but it is likely MUCH bigger than 4k.
Give Go/C 8k.

TBR=iant
CC=golang-codereviews
https://codereview.appspot.com/140440044
runtime: fix plan9/amd64 build?

The only thing I can see that is really Plan 9-specific
is that the stack pointer used for signal handling used
to have more mapped memory above it.
Specifically it used to have at most 88 bytes (StackTop),
so change the allocation of a 40-byte frame to a 128-byte frame.

No idea if this will work, but worth a try.

Note that "fix" here means get it back to timing out
instead of crashing.

TBR=iant
CC=golang-codereviews
https://codereview.appspot.com/142840043
runtime: map iterators: always use intrabucket randomess

Fixes issue 8688

LGTM=rsc
R=golang-codereviews, bradfitz, rsc, khr
CC=golang-codereviews
https://codereview.appspot.com/135660043
runtime: more cleanups

Move timenow thunk into time.s
Move declarations for generic c/asm services into stubs.go

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/137360043
runtime: call rfork on scheduler stack on Plan 9

A race exists between the parent and child processes after a fork.
The child needs to access the new M pointer passed as an argument
but the parent may have already returned and clobbered it.

Previously, we avoided this by saving the necessary data into
registers before the rfork system call but this isn't guaranteed
to work because Plan 9 makes no promises about the register state
after a system call. Only the 386 kernel seems to save them.
For amd64 and arm, this method won't work.

We eliminate the race by allocating stack space for the scheduler
goroutines (g0) in the per-process copy-on-write stack segment and
by only calling rfork on the scheduler stack.

LGTM=aram, 0intro, rsc
R=aram, 0intro, mischief, rsc
CC=golang-codereviews
https://codereview.appspot.com/110680044
runtime: cleanup openbsd semasleep implementation

The previous implementation had several subtle issues.  It's not
clear if any of these could actually be causing the flakiness
problems on openbsd/386, but fixing them should only help.

1. thrsleep() is implemented internally as unlock, then test *abort
(if abort != nil), then tsleep().  Under the current code, that makes
it theoretically possible that semasleep()/thrsleep() could release
waitsemalock, then a racing semawakeup() could acquire the lock,
increment waitsemacount, and call thrwakeup()/wakeup() before
thrsleep() reaches tsleep().  (In practice, OpenBSD's big kernel lock
seems unlikely to let this actually happen.)

The proper way to avoid this is to pass &waitsemacount as the abort
pointer to thrsleep so thrsleep knows to re-check it before going to
sleep, and to wakeup if it's non-zero.  Then we avoid any races.
(I actually suspect openbsd's sema{sleep,wakeup}() could be further
simplified using cas/xadd instead of locks, but I don't want to be
more intrusive than necessary so late in the 1.4 release cycle.)

2. semasleep() takes a relative sleep duration, but thrsleep() needs
an absolute sleep deadline.  Instead of recomputing the deadline each
iteration, compute it once up front and use (*Timespec)(nil) to signify
no deadline.  Ensures we retry properly if there's a spurious wakeup.

3. Instead of assuming if thrsleep() woke up and waitsemacount wasn't
available that we must have hit the deadline, check that the system
call returned EWOULDBLOCK.

4. Instead of assuming that 64-bit systems are little-endian, compute
timediv() using a temporary int32 nsec and then assign it to tv_nsec.

LGTM=iant
R=jsing, iant
CC=golang-codereviews
https://codereview.appspot.com/137960043

Committer: Ian Lance Taylor <iant@golang.org>
runtime: stop plan9/amd64 build from crashing

LGTM=iant
R=rsc, 0intro, alex.brainman, iant
CC=golang-codereviews
https://codereview.appspot.com/140460044

Committer: Ian Lance Taylor <iant@golang.org>
reflect: use runtime's memmove instead of its own

They will both need write barriers at some point.
But until then, no reason why we shouldn't share.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://codereview.appspot.com/141330043