Found using the vet check in CL 106370045.

This is a second attempt at CL 101670044, which omitted the deps_test change.

This adds dependencies to net/rpc:

        encoding
        encoding/base64
        encoding/json
        html
        unicode/utf16

The obvious correctness and security warrants the additional dependencies.

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

Generated by a+c.

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

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

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

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

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

When we've switched to 8K pages,
heap started to grow by 128K instead of 64K,
because it was implicitly assuming that pages are 4K.
Fix that and make the code more robust.

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

LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/107640044

LGTM=0intro, dave
R=dave, 0intro
CC=golang-codereviews
https://golang.org/cl/106560044

Also remove arch-specific Go files in the Plan 9 syscall package

LGTM=0intro
R=0intro, dave
CC=ality, golang-codereviews, jas, mischief, rsc
https://golang.org/cl/112720043

LGTM=0intro
R=0intro
CC=ality, dave, golang-codereviews, jas, mischief, rsc
https://golang.org/cl/104570043

size instead of abusing text symbol

cmd/addr2line needs to know the virtual address of the start
of the text segment (load address plus header size). For
this, it used the text symbol added by the linker. This is
wrong on amd64. Header size is 40 bytes, not 32 like on 386
and arm. Function alignment is 16 bytes causing text to be
at 0x200030.

debug/plan9obj now exports both the load address and the
header size; cmd/addr2line uses this new information and
doesn't rely on text anymore.

LGTM=0intro
R=0intro, gobot, ality
CC=ality, golang-codereviews, jas, mischief
https://golang.org/cl/106460044

LGTM=0intro, r
R=0intro, r
CC=ality, golang-codereviews, jas, mischief
https://golang.org/cl/108420043

LGTM=0intro, r
R=0intro, r
CC=ality, dave, golang-codereviews, jas, mischief, rsc
https://golang.org/cl/111910043

LGTM=0intro, r
R=0intro, r
CC=ality, dave, golang-codereviews, jas, mischief, rsc
https://golang.org/cl/105580044

NetlinkRIB is currently allocating a page sized slice of bytes in a
for loop and it's also calling Getpagesize() in the same for loop.

This CL changes NetlinkRIB to preallocate the page sized slice of
bytes before reaching the for loop. This reduces memory allocations
and lowers the number of calls to Getpagesize() to 1 per NetlinkRIB
call.

This CL reduces the allocated memory from 141.5 MB down to 52 MB in
a test.

LGTM=crawshaw, dave
R=dave, dsymonds, crawshaw
CC=bradfitz, dsymonds, golang-codereviews
https://golang.org/cl/110920043

Fixes #8165.

After this change, the panic is replaced by a message:

        $ go build -o out ...doesntexist
        warning: "...doesntexist" matched no packages
        no packages to build

The motivation to return 1 exit error code is to allow -o flag
to be used to guarantee that the output binary is written to
when exit status is 0. If someone uses an import path pattern
to specify a single package and suddenly that matches no packages,
it's better to return exit code 1 instead of silently doing nothing.
This is consistent with the case when -o flag is given and multiple
packages are matched.
It's also somewhat consistent with the current behavior with the
panic, except that gave return code 2. But it's similar in
that it's also non-zero (indicating failure).
I've changed the language to be similar to output of go test
when an import path pattern matches no packages (it also has a return status of
1):

        $ go test ...doesntexist
        warning: "...doesntexist" matched no packages
        no packages to test

LGTM=adg
R=golang-codereviews, josharian, gobot, adg
CC=golang-codereviews
https://golang.org/cl/107140043

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

http://gcc.gnu.org/PR61746

http://code.google.com/p/gofrontend/issues/detail?id=35

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/111980043

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/108450044

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

Maxstring is not updated in the new string routines,
this makes runtime think that long strings are bogus.
Fixes #8339.

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

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/104600043

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/107600043

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

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

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

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/111970043

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

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

Broke build; missing deps_test change. Will re-send the original with the appropriate fix.

««« original CL description
net/rpc: use html/template to render html

Found using the vet check in CL 106370045.

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

TBR=r
CC=golang-codereviews
https://golang.org/cl/110880044

Found using the vet check in CL 106370045.

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

The code generating the .debug_frame section emits pairs of "advance PC",
"set SP offset" pseudo-instructions. Before the fix, the PC advance comes
out before the SP setting, which means the emitted offset for a block is
actually the value at the end of the block, which is incorrect for the
block itself.

The easiest way to fix this problem is to emit the SP offset before the
PC advance.

One delicate point: the last instruction to come out is now an
"advance PC", which means that if there are padding intsructions after
the final RET, they will appear to have a non-zero offset. This is odd
but harmless because there is no legal way to have a PC in that range,
or to put it another way, if you get here the SP is certainly screwed up
so getting the wrong (virtual) frame pointer is the least of your worries.

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

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

LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/109080048

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/109470044

LGTM=crawshaw, dave
R=golang-codereviews, crawshaw, dave
CC=golang-codereviews
https://golang.org/cl/104520044

Both stdout and stderr are sent to /dev/null in android
apps. Introducing fatalf allows android to implement its
own copy that sends fatal errors to __android_log_print.

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

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

It snuck into cl/106380043. Too many active clients.

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