CL 170720043 missed this one when adding +PCQuantum.

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

Fixes #9046.

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

For some reason lsof is now hanging on my workstation
without the -b (avoid blocking in the kernel) option.
Adding -b makes the test pass and shouldn't hurt.

I don't know how recent the -b option is.  If the builders
are ok with it, it's probably ok.

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

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

Gentraceback may grow the stack.
One of the gentraceback wrappers may grow the stack.
One of the gentraceback callback calls may grow the stack.
Various stack pointers are stored in various stack locations
as type uintptr during the execution of these calls.
If the stack does grow, these stack pointers will not be
updated and will start trying to decode stack memory that
is no longer valid.

It may be possible to change the type of the stack pointer
variables to be unsafe.Pointer, but that's pretty subtle and
may still have problems, even if we catch every last one.
An easier, more obviously correct fix is to require that
gentraceback of the currently running goroutine must run
on the g0 stack, not on the goroutine's own stack.

Not doing this causes faults when you set
        StackFromSystem = 1
        StackFaultOnFree = 1

The new check in gentraceback will catch future lapses.

The more general problem is calling getcallersp but then
calling a function that might relocate the stack, which would
invalidate the result of getcallersp. Add note to stubs.go
declaration of getcallersp explaining the problem, and
check all existing calls to getcallersp. Most needed fixes.

This affects Callers, Stack, and nearly all the runtime
profiling routines. It does not affect stack copying directly
nor garbage collection.

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

Fixes #9020.

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

LGTM=r, adg
R=adg, r, 0xjnml, dr.volker.dobler
CC=golang-codereviews
https://golang.org/cl/166980044

The new rules for split functions mean that we are exposed
to the common bug of a function that loops forever at EOF.
Pick these off by shutting down the scanner if too many
consecutive empty tokens are delivered.

Fixes #9020.

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

The test intended to skip direct calls when creating
registerization variables was testing p->to.type instead of
p->to.name, so it always failed, causing regopt to create
unnecessary variables for these names.

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

One failing case this removes is:

var bytes = []byte("hello, world")
var copy_bytes = bytes

We could handle this in the compiler, but it requires special
case for a variable that is initialized to the value of a
variable that is initialized to a string literal converted to
[]byte.  This seems an unlikely case--it never occurs in the
standrd library--and it seems unnecessary to write the code to
handle it.

If we do want to support this case, one approach is
https://golang.org/cl/171840043.

The other failing cases are of the form

var bx bool
var copy_bx = bx

The compiler used to initialize copy_bx to false.  However,
that led to issue 7665, since bx may be initialized in non-Go
code.  The compiler no longer assumes that bx must be false,
so copy_bx can not be statically initialized.

We can fix these with https://golang.org/cl/169040043
if we also pass -complete to the compiler as part of this
test.  This is OK but it's too late in the release cycle.

Fixes #8746.

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

The check for unknown command line debug flags in gc was
incorrect: the loop over debugtab terminates when it reaches a
nil entry, but it was only reporting an error if the parser
had passed the last entry of debugtab (which it never did).
Fix this by reporting the usage error if the loop reaches a
nil entry.

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

(The assertion depends on a per-package gensym counter whose
value varies based on what else is in the package.)

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

Previously, the flags argument to mallocgc was an int in Go,
but a uint32 in C.  Change the Go type to use uint32 so these
agree.  The largest flag value is 2 (and of course no flag
values are negative), so this won't change anything on little
endian architectures, but it matters on big endian.

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

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

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