CL 36800043 and CL 36930044 have a merge conflict that I overlooked.

R=golang-dev
CC=golang-dev
https://golang.org/cl/39850043

Fixes #6849.
Fixes #6867.

R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/35870043

Three changes:
1. mention "move" to clarify things up.
2. use {old,new}path instead of {old,new}name, which makes it clear what
   relative path would do here.
3. mention "OS-specific restrictions might apply".

Fixes #6887.

R=golang-dev, alex.brainman, iant, r
CC=golang-dev
https://golang.org/cl/36930044

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/38920043

Fixes #6899

R=golang-dev, r, cshapiro, iant, rsc
CC=golang-dev
https://golang.org/cl/38120043

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/39780043

Nothing looks at __.SYMDEF, and the object file format is changing.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/39580044

The linker is in charge of providing the one true declaration.

R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/39560043

Fixes #6833

R=minux.ma, iant
CC=golang-dev
https://golang.org/cl/35790045

R=golang-dev, 0intro, rsc
CC=golang-dev
https://golang.org/cl/39680044

warning: src/cmd/8c/list.c:124 format mismatch d VLONG, arg 3
warning: src/cmd/8c/list.c:134 format mismatch d VLONG, arg 3
warning: src/cmd/8c/list.c:142 format mismatch d VLONG, arg 3
warning: src/cmd/8c/list.c:152 format mismatch d VLONG, arg 3
warning: src/cmd/8c/list.c:156 format mismatch d VLONG, arg 4
warning: src/cmd/8c/list.c:160 format mismatch d VLONG, arg 4
warning: src/cmd/8c/list.c:165 format mismatch d VLONG, arg 4
warning: src/cmd/8c/list.c:167 format mismatch d VLONG, arg 3
warning: src/cmd/8c/list.c:172 format mismatch d VLONG, arg 4
warning: src/cmd/8c/list.c:174 format mismatch d VLONG, arg 3
warning: src/cmd/8c/list.c:178 format mismatch d VLONG, arg 3
warning: src/cmd/8c/list.c:184 format mismatch d VLONG, arg 3

warning: src/cmd/8g/list.c:91 format mismatch d VLONG, arg 4
warning: src/cmd/8g/list.c:100 format mismatch d VLONG, arg 4
warning: src/cmd/8g/list.c:114 format mismatch d VLONG, arg 5
warning: src/cmd/8g/list.c:118 format mismatch d VLONG, arg 5
warning: src/cmd/8g/list.c:122 format mismatch d VLONG, arg 5
warning: src/cmd/8g/list.c:126 format mismatch d VLONG, arg 5
warning: src/cmd/8g/list.c:136 format mismatch d VLONG, arg 4

warning: src/cmd/8l/list.c:107 format mismatch d VLONG, arg 4
warning: src/cmd/8l/list.c:125 format mismatch ux VLONG, arg 4
warning: src/cmd/8l/list.c:128 format mismatch ux VLONG, arg 4
warning: src/cmd/8l/list.c:130 format mismatch d VLONG, arg 4
warning: src/cmd/8l/list.c:134 format mismatch d VLONG, arg 5
warning: src/cmd/8l/list.c:138 format mismatch d VLONG, arg 6
warning: src/cmd/8l/list.c:143 format mismatch d VLONG, arg 5
warning: src/cmd/8l/list.c:148 format mismatch d VLONG, arg 5
warning: src/cmd/8l/list.c:150 format mismatch d VLONG, arg 4
warning: src/cmd/8l/list.c:154 format mismatch d VLONG, arg 4
warning: src/cmd/8l/list.c:158 format mismatch d VLONG, arg 4
warning: src/cmd/8l/obj.c:132 format mismatch ux VLONG, arg 2

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/39710043

Fixes a regression introduced in revision 4cb93e2900d0.

That revision changed runtime·memmove to use SSE MOVOU
instructions for sizes between 17 and 256 bytes. We were
using memmove to save a copy of the note string during
the note handler. The Plan 9 kernel does not allow the
use of floating point in note handlers (which includes
MOVOU since it touches the XMM registers).

Arguably, runtime·memmove should not be using MOVOU when
GO386=387 but that wouldn't help us on amd64. It's very
important that we guard against any future changes so we
use a simple copy loop instead.

This change is extracted from CL 9796043 (since that CL
is still being ironed out).

R=rsc
CC=golang-dev
https://golang.org/cl/34640045

R=golang-dev, minux.ma, iant
CC=golang-dev
https://golang.org/cl/36300045

R=jas, lucio.dere, rsc
CC=golang-dev
https://golang.org/cl/14604047

The funcdata symbol incorrectly named the dead value map the
dead pointer map.  The dead value map identifies all dead
values, including pointers and non-pointers, in a stack frame.
The purpose of this map is to allow the runtime to poison
locations of dead data to catch lost invariants.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/38670043

TBR=iant
CC=golang-dev
https://golang.org/cl/39540043

TBR=iant
CC=golang-dev
https://golang.org/cl/39530043

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/36300044

TBR=iant
CC=golang-dev
https://golang.org/cl/39510043

TBR=iant
CC=golang-dev
https://golang.org/cl/39400044

That option turns off word wrapping of individual
error messages generated by clang. The wrapping
makes the errors harder to read and conflicts with the
idea of a terminal window that can be resized.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/35810043

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/39280043

The new linker will disallow this on arm
(it is already disallowed on amd64 and 386)
in order to be able to lay out each function
separately.

The restriction is only for jumps into the middle
of a function; jumps to the beginning of a function
remain fine.

Prereq for linker cleanup (golang.org/s/go13linker).

R=iant, r, minux.ma
CC=golang-dev
https://golang.org/cl/35800043

Preparation for golang.org/s/go13linker work.

This CL does not build by itself. It depends on 35740044
and 35790044 and will be submitted at the same time.

R=iant
CC=golang-dev
https://golang.org/cl/34590045

Preparation for golang.org/s/go13linker work.

This CL does not build by itself. It depends on 35740044
and 35790044 and will be submitted at the same time.

R=iant
CC=golang-dev
https://golang.org/cl/34580044

Preparation for golang.org/s/go13linker work.

This CL does not build by itself. It depends on 35740044
and 35790044 and will be submitted at the same time.

R=iant
CC=golang-dev
https://golang.org/cl/35830043

There is an enormous amount of code moving around in this CL,
but the code is the same, and it is invoked in the same ways.
This CL is preparation for the new linker structure, not the new
structure itself.

The new library's definition is in include/link.h.

The main change is the use of a Link structure to hold all the
linker-relevant state, replacing the smattering of global variables.
The Link structure should both make it clearer which state must
be carried around and make it possible to parallelize more easily
later.

The main body of the linker has moved into the architecture-independent
cmd/ld directory. That includes the list of known header types, so the
distinction between Hplan9x32 and Hplan9x64 is removed (no other
header type distinguished 32- and 64-bit formats), and code for unused
formats such as ipaq kernels has been deleted.

The code being deleted from 5l, 6l, and 8l reappears in liblink or in ld.
Because multiple files are being merged in the liblink directory,
it is not possible to show the diffs nicely in hg.

The Prog and Addr structures have been unified into an
architecture-independent form and moved to link.h, where they will
be shared by all tools: the assemblers, the compilers, and the linkers.
The unification makes it possible to write architecture-independent
traversal of Prog lists, among other benefits.

The Sym structures cannot be unified: they are too fundamentally
different between the linker and the compilers. Instead, liblink defines
an LSym - a linker Sym - to be used in the Prog and Addr structures,
and the linker now refers exclusively to LSyms. The compilers will
keep using their own syms but will fill out the corresponding LSyms in
the Prog and Addr structures.

Although code from 5l, 6l, and 8l is now in a single library, the
code has been arranged so that only one architecture needs to
be linked into a particular program: 5l will not contain the code
needed for x86 instruction layout, for example.

The object file writing code in liblink/obj.c is from cmd/gc/obj.c.

Preparation for golang.org/s/go13linker work.

This CL does not build by itself. It depends on 35740044
and will be submitted at the same time.

R=iant
CC=golang-dev
https://golang.org/cl/35790044

In addition to adding the library, change the way the anames array is created.
Previously, it was written to src/cmd/6l/enam.c (and similarly for 5l and 8l)
and each of the other tools (6g, 6c, 6a) compiled the 6l/enam.c file in addition
to their own sources.

Now that there is a library shared by all these programs, move the anames
array into that library. To eliminate name conflicts, name the array after
the architecture letter: anames5, anames6, anames8.

First step to linker cleanup (golang.org/s/go13linker).

This CL does not build by itself. It depends on the CLs introducing
liblink and changing commands to use it.

R=iant
CC=golang-dev
https://golang.org/cl/35740044

We are not clearing dead values in the garbage collector so it
is not worth the RSS cost to materialize the data and write it
out to the binary.

R=golang-dev, iant, cshapiro
CC=golang-dev
https://golang.org/cl/38650043

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/38640043

When enabled this new debugging mode will allocate objects on
their own page and never recycle memory addresses.  This is an
essential tool to root cause a broad class of heap corruption.

R=golang-dev, dave, daniel.morsing, dvyukov, rsc, iant, cshapiro
CC=golang-dev
https://golang.org/cl/22060046

R=iant
CC=golang-dev
https://golang.org/cl/38560043

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/38590043

R=golang-dev
CC=golang-dev
https://golang.org/cl/38130043

cmd/5g, cmd/5l, cmd/6g, cmd/6l, cmd/8g, cmd/8l, cmd/gc, runtime: generate pointer maps by liveness analysis

This change allows the garbage collector to examine stack
slots that are determined as live and containing a pointer
value by the garbage collector.  This results in a mean
reduction of 65% in the number of stack slots scanned during
an invocation of "GOGC=1 all.bash".

Unfortunately, this does not yet allow garbage collection to
be precise for the stack slots computed as live.  Pointers
confound the determination of what definitions reach a given
instruction.  In general, this problem is not solvable without
runtime cost but some advanced cooperation from the compiler
might mitigate common cases.

R=golang-dev, rsc, cshapiro
CC=golang-dev
https://golang.org/cl/14430048

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/31900043

Nothing significant so far (right?), but let's lay the keystone.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/36830043

R=golang-dev, r, rsc
CC=golang-dev
https://golang.org/cl/23320044

Output for an allocation and free (sweep) follows

MProf_Malloc(p=0xc2100210a0, size=0x50, type=0x0 <single object>)
        #0 0x46ee15 runtime.mallocgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:141
        #1 0x47004f runtime.settype_flush /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:612
        #2 0x45f92c gc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2071
        #3 0x45f89e mgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2050
        #4 0x45258b runtime.mcall /usr/local/google/home/cshapiro/go/src/pkg/runtime/asm_amd64.s:179

MProf_Free(p=0xc2100210a0, size=0x50)
        #0 0x46ee15 runtime.mallocgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:141
        #1 0x47004f runtime.settype_flush /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:612
        #2 0x45f92c gc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2071
        #3 0x45f89e mgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2050
        #4 0x45258b runtime.mcall /usr/local/google/home/cshapiro/go/src/pkg/runtime/asm_amd64.s:179

R=golang-dev, dvyukov, rsc, cshapiro
CC=golang-dev
https://golang.org/cl/21990045

Shaves 1% off of binary size.

update #6853

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/35940047