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

Based on cl/69170045 by Elias Naur.

There are currently several schemes for acquiring a TLS
slot to save the g register. None of them appear to work
for android. The closest are linux and darwin.

Linux uses a linker TLS relocation. This is not supported
by the android linker.

Darwin uses a fixed offset, and calls pthread_key_create
until it gets the slot it wants. As the runtime loads
late in the android process lifecycle, after an
arbitrary number of other libraries, we cannot rely on
any particular slot being available.

So we call pthread_key_create, take the first slot we are
given, and put it in runtime.tlsg, which we turn into a
regular variable in cmd/ld.

Makes android/arm cgo binaries work.

LGTM=minux
R=elias.naur, minux, dave, josharian
CC=golang-codereviews
https://golang.org/cl/106380043

The code in GC that handles gp->gobuf.ctxt is wrong,
because it does not mark the ctxt object itself,
if just queues the ctxt object for scanning.
So the ctxt object can be collected as garbage.
However, Gobuf.ctxt is void*, so it's always marked and
scanned through G.

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

Currently it says:
--- PASS: TestDecrypt-2 (0.11s)
pem_decrypt_test.go:17: test 0. %!s(x509.PEMCipher=1)
--- PASS: TestEncrypt-2 (0.00s)
pem_decrypt_test.go:42: test 0. %!s(x509.PEMCipher=1)

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

runtime·usleep and runtime·osyield fall back to calling an
assembly wrapper for the libc functions in the absence of a m,
so they can be called in cgo callback context.

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

A temporary 512 bytes buffer is allocated for every call to
readHeader. This buffer isn't returned to the caller and it could
be reused to lower the number of memory allocations.

This CL improves it by using a pool and zeroing out the buffer before
putting it back into the pool.

benchmark                  old ns/op     new ns/op     delta
BenchmarkListFiles100k     545249903     538832687     -1.18%

benchmark                  old allocs    new allocs    delta
BenchmarkListFiles100k     2105167       2005692       -4.73%

benchmark                  old bytes     new bytes     delta
BenchmarkListFiles100k     105903472     54831527      -48.22%

This improvement is very important if your code has to deal with a lot
of tarballs which contain a lot of files.

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

A temporary 512 bytes buffer is allocated for every call to
writeHeader. This buffer could be reused the lower the number
of memory allocations.

benchmark                   old ns/op     new ns/op     delta
BenchmarkWriteFiles100k     634622051     583810847     -8.01%

benchmark                   old allocs     new allocs     delta
BenchmarkWriteFiles100k     2701920        2602621        -3.68%

benchmark                   old bytes     new bytes     delta
BenchmarkWriteFiles100k     115383884     64349922      -44.23%

This change is very important if your code has to write a lot of
tarballs with a lot of files.

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