Mostly NOSPLIT additions.
Had to rewrite atomic_arm.c in Go because it calls lock,
and lock is too complex.

With this CL, I find no Go -> C calls that can split the stack
on any system except Solaris and Windows.

Solaris and Windows need more work and will be done separately.

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

The -nocgo builder failed because it has cgo disabled
as well as no USER environment variable:
http://build.golang.org/log/2250abb82f5022b72a12997b8ff89fcdeff094c9

# Checking API compatibility.
Error getting current user: user: Current not implemented on linux/amd64
exit status 1

Don't require the environment variable here.

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

(a b string, ok bool) is not a valid signature

Fixes #8656.

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

Convert no-op race functions.
Everything else is tiny and gets NOSPLITs.

After this, all that is left on darwin is sysAlloc, panic, and gothrow (all pending).
There may be system-specific calls in other builds.

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

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

When this code was written, there was no way for Go to
reuse the C function and enum values. Now there is.

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

The original conversion in CL 132090043 cut up
the function in an attempt to avoid converting most
of the code to Go. This contorts the control flow.

While debugging the onM signal stack bug,
I reconverted sigqueue.goc in its entirety.
This restores the original control flow, which is
much easier to understand.

The current conversion is correct, it's just complex
and will be hard to maintain. The new one is as
readable as the original code.

I uploaded sigqueue.goc as the initial copy of
sigqueue.go in the CL, so if you view the diffs
of sigqueue.go comparing against patch set 2 [sic]
it will show the actual starting point.

For example:
https://golang.org/cl/136160043/diff2/20001:60001/src/pkg/runtime/sigqueue.go

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

Without this fix, some tests crashed (e.g. go test -run Invalid).

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

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

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

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

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

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

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

The common code is converted, epoll and kqueue are converted.
Windows and solaris are still C.

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

BP is not a legal register on nacl.

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

I had this right in one of my clients, but apparently not the one I submitted from.

Fixes 386 builds.

TBR=dfc
CC=golang-codereviews
https://golang.org/cl/138000045

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

The arm5 build breakage at CL 139110043 was caused by
calling funcPC on a lessstack defined as a struct{}.
That symbol ended up with a non-4-aligned address,
which caused the memory fault that broke the builders.
The definition of lessstack was fixed in CL 140880043.

Tracking that down suggested that it would be worth
looking for the same bug elsewhere in the directory.
This is the only one I found.

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

Some things get converted.
Other things (too complex or too many C deps) get onM calls.
Other things (too simple) get #pragma textflag NOSPLIT.

After this CL, the offending function list is basically:
        - panic.c
        - netpoll.goc
        - mem*.c
        - race stuff
        - readgstatus
        - entersyscall/exitsyscall

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

The implementation and use patterns of onM assume
that they run on either the m->curg or m->g0 stack.

Calling onM from m->gsignal has two problems:

(1) When not on g0, onM switches to g0 and then "back" to curg.
If we didn't start at curg, bad things happen.

(2) The use of scalararg/ptrarg to pass C arguments and results
assumes that there is only one onM call at a time.
If a gsignal starts running, it may have interrupted the
setup/teardown of the args for an onM on the curg or g0 stack.
Using scalararg/ptrarg itself would smash those.

We can fix (1) by remembering what g was running before the switch.

We can fix (2) by requiring that uses of onM that might happen
on a signal handling stack must save the old scalararg/ptrarg
and restore them after the call, instead of zeroing them.
The only sane way to do this is to introduce a separate
onM_signalsafe that omits the signal check, and then if you
see a call to onM_signalsafe you know the surrounding code
must preserve the old scalararg/ptrarg values.
(The implementation would be that onM_signalsafe just calls
fn if on the signal stack or else jumps to onM. It's not necessary
to have two whole copies of the function.)

(2) is not a problem if the caller and callee are both Go and
a closure is used instead of the scalararg/ptrarg slots.

For now, I think we can avoid calling onM from code executing
on gsignal stacks, so just reject it.

In the long term, (2) goes away (as do the scalararg/ptrarg slots)
once everything is in Go, and at that point fixing (1) would be
trivial and maybe worth doing just for regularity.

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

Instead of making asmcgocall call asmcgocall_errno,
make both load args into registers and call a shared
assembly function.

On amd64, this costs 1 word in the asmcgocall_errno path
but saves 3 words in the asmcgocall path, and the latter
is what happens on critical nosplit paths on Windows.

On arm, this fixes build failures: asmcgocall was writing
the arguments for asmcgocall_errno into the wrong
place on the stack. Passing them in registers avoids the
decision entirely.

On 386, this isn't really needed, since the nosplit paths
have twice as many words to work with, but do it for consistency.

Update #8635
Fixes arm build (except GOARM=5).

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

Fixes #8619.

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

I really hoped we could avoid this nonsense, but it appears not.

Should fix windows/amd64 build breakage.

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

This CL fixes a bug introduced by CL 128820043 which is that
builtin dns stub resolver doesn't work well with literal IPv6
address namesever entries in /etc/resolv.conf.

Also simplifies resolv.conf parser and adds more test cases.

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

The discriminator in the execution engine was stupid.
Add a test to the parse package too. The problem wasn't there
but the particular case ('e' in a hex integer) was not covered.

Fixes #8622.

LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/133530043

It is fundamentally unsafe to grow the stack once someone
has made a call to syscall.Syscall. That function takes 6 uintptr
arguments, but depending on the call some are pointers.
In fact, some might be pointers to stack values, and we don't know which.
That makes it impossible to copy the stack somewhere else.
Since we want to delete all the stack splitting code, relying only
on stack copying, make sure that Syscall never needs to split the stack.

The only thing Syscall does is:
        call entersyscall
        make the system call
        call exitsyscall

As long as we make sure that entersyscall and exitsyscall
can live in the nosplit region, they won't ask for more stack.

Do this by making entersyscall and exitsyscall set up the
stack guard so that any call to a function with a split check
will cause a crash. Then move non-essential slow-path
work onto the m stack using onM and mark the rest of the
work nosplit. The linker will verify that the chain of nosplits
fits in the total nosplit budget.

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

LGTM=gri
R=golang-codereviews, gobot, gri
CC=golang-codereviews
https://golang.org/cl/140750043

Because symtab.c was partially converted before,
the diffs are not terribly useful.

The earlier conversion was trying to refactor or
clean up the code in addition to doing the translation.
It also made a mistake by redefining Func to be something
users could overwrite.

I undid those changes, making symtab.go a more
literal line-for-line translation of symtab.c instead.

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

We often saw GC pauses of 0 ns, not just on Windows.
Google Compute Engine timer granularity might suck
too.

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

The race was in the old C code.
The new Go code does not have the race
and does not need the check.

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

Ignore memory access on g0/gsignal.
See the issue for context and explanation.
Fixes #8627.

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

Code to bring goroutines to a gc safepoint one at a time,
do some work such as scanning, and restart the
goroutine, and then move on to the next goroutine.
Currently this code does not do much useful work
but this infrastructure will be critical to future
concurrent GC work.

Fixed comments reviewers.

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

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

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

This gives them correct types in Go and also makes it
possible to use them to run Go code on an m stack.

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

They were in proc.c mainly because there was no portable
traceback source file. As part of converting them to Go,
move to traceback.go.

In order to get access to the PC of _rt0_go,
rename to runtime.rt0_go.

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

This removes the ** unsafe hack.

Real bug fixed at chan.go:101.

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

If system is busy burning cpu, it takes long time (about 300ms on
windows builders) to adjust prof thread priority. Once adjusted, prof
thread runs ahead of everyone else, but due to initial slowness, it
does not capture prof snapshots until start-up period is completed.

Change prof thread priority sooner, so it can start captures straight
away.

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

While we are here, give the gc helper a real function name
that will appear in stack traces.

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