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

This fixes the Plan 9 build.

Fix issue 8621.

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

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

C and Go calling conventions are now compatible, so we
don't need two versions of this function.

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

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

Reverse dependency of https://golang.org/cl/130950043/

LGTM=agl
R=golang-codereviews, agl
CC=agl, golang-codereviews
https://golang.org/cl/138800043

Generated by a+c.

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

The two converted files were nearly identical.
Instead of continuing that duplication, I merged them
into a single traceback.go.

Tested on arm, amd64, amd64p32, and 386.

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

The code I wrote originally works for trivial functions
that are inlined at a call site in another package,
because that was how I wrote my local test.
Make hex(x) work for non-inlinable functions too.

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

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

Previously, if all connections were busy, we would always
re-prepare the statement on the connection we were assigned from
the pool.  That meant that if all connections were busy most of the
time, the number of prepared statements for each connection would
keep increasing over time.

Instead, after getting a free connection, check to see if the
statement has already been prepared on it, and reuse the statement
handle if so.

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

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

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

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

LGTM=rsc
R=rsc, ality
CC=golang-codereviews
https://golang.org/cl/137030043

It looks like this has just always been broken:
the race detector handles running Go code on g0 of the main thread
and on g0 of any extra threads created by non-Go code, but it does
not handle running Go code on g0 of non-main threads created by Go.
Handle that.

Should fix the race build failures on the dashboard.

We're running into this now because we are running more
and more Go code on g0.

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/137910043

The file in repo has been updated recently, but all these changes
are gone off the web site now. It seems web site gets updated once
in a while, so we'll update our file occasionally.

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