On heavily loaded build servers, a 5 second timeout is too aggressive,
which causes this test to fail spuriously.

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

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

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

Using -test.cpu=1,1 made it crash before.

Fixes #9024

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

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

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

Fixes #9029

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

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

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

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

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

+ Regression test.

Fixes #9026.

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

It doesn't simplify, because it wasn't even possible before.

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

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

TBR=rsc
R=r, rsc
CC=golang-codereviews
https://golang.org/cl/164240043

TBR=adg
CC=golang-codereviews
https://golang.org/cl/167890043

If you get a stack of PCs from Callers, it would be expected
that every PC is immediately after a call instruction, so to find
the line of the call, you look up the line for PC-1.
CL 163550043 now explicitly documents that.

The most common exception to this is the top-most return PC
on the stack, which is the entry address of the runtime.goexit
function. Subtracting 1 from that PC will end up in a different
function entirely.

To remove this special case, make the top-most return PC
goexit+PCQuantum and then implement goexit in assembly
so that the first instruction can be skipped.

Fixes #7690.

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

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

First draft now complete.

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

This removes a bunch of ugly duplicate code.
The end goal is to factor the disassembly code
into cmd/internal/objfile too, so that pprof can use it,
but one step at a time.

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

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

Originally traceback was only used for printing the stack
when an unexpected signal came in. In that case, the
initial PC is taken from the signal and should be used
unaltered. For the callers, the PC is the return address,
which might be on the line after the call; we subtract 1
to get to the CALL instruction.

Traceback is now used for a variety of things, and for
almost all of those the initial PC is a return address,
whether from getcallerpc, or gp->sched.pc, or gp->syscallpc.
In those cases, we need to subtract 1 from this initial PC,
but the traceback code had a hard rule "never subtract 1
from the initial PC", left over from the signal handling days.

Change gentraceback to take a flag that specifies whether
we are tracing a trap.

Change traceback to default to "starting with a return PC",
which is the overwhelmingly common case.

Add tracebacktrap, like traceback but starting with a trap PC.

Use tracebacktrap in signal handlers.

Fixes #7690.

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

Attempt to clear up confusion about how to turn
the PCs reported by Callers into the file and line
number people actually want.

Fixes #7690.

LGTM=r, chris.cs.guy
R=r, chris.cs.guy
CC=golang-codereviews
https://golang.org/cl/163550043

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

Stupid mistake in previous CL.

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

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

TBR=austin
CC=golang-codereviews
https://golang.org/cl/167820043

TBR=austin
CC=golang-codereviews
https://golang.org/cl/162420043

Fixes #8803.

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

Fixes #9006.

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

It now echoes what strconv.FormatFloat says.

Fixes #9012.

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

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

Fixes #8861.
Fixes #8911.

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

Fixes #8588.

LGTM=austin
R=austin
CC=golang-codereviews, khr
https://golang.org/cl/159700044

goprintf is a printf-like print for Go.
It is used in the code generated by 'defer print(...)' and 'go print(...)'.

Normally print(1, 2, 3) turns into

        printint(1)
        printint(2)
        printint(3)

but defer and go need a single function call to give the runtime;
they give the runtime something like goprintf("%d%d%d", 1, 2, 3).

Variadic functions like goprintf cannot be described in the new
type information world, so we have to replace it.

Replace with a custom function, so that defer print(1, 2, 3) turns
into

        defer func(a1, a2, a3 int) {
                print(a1, a2, a3)
        }(1, 2, 3)

(and then the print becomes three different printints as usual).

Fixes #8614.

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

In CL 160670043 the write function was changed
so a zero-length write is now allowed. This leads
the ExampleWriter_Init test to fail.

The reason is that Plan 9 preserves message
boundaries, while the os library expects systems
that don't preserve them. We have to ignore
zero-length writes so they will never turn into EOF.

This issue was previously discussed in CL 7406046.

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

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

Also a few other minor changes.

Fixes #8712.

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

TBR=crawshaw
CC=golang-codereviews
https://golang.org/cl/162390043

LGTM=rsc, aram, minux
R=golang-codereviews, aram, minux, rsc
CC=golang-codereviews
https://golang.org/cl/162370045