Fixes #5584.

R=golang-dev, chaishushan, alex.brainman
CC=golang-dev
https://golang.org/cl/12720043

It timeouts on freebsd builders:
http://build.golang.org/log/3d8169e13bff912bebf6fd3c54b34ad2d29a7221
but there are always runnable goroutines,
which suggests that it's slowly progressing.

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

        The ARM external linking CL used BLX instructions in gcc assembler. Replace with BL to retain support on older ARM processors.

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

1. Do less iterations in short mode
2. Bound number of times SetDeadline is executed

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

        The ARM external linking CL left missed changes to sys_freebsd_arm.s and sys_netbsd_arm.s already done to sys_linux_arm.s.

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

The TLS block on Darwin is not the same as on ELF.

TBR=elias.naur
CC=golang-dev
https://golang.org/cl/12741044

        The shared library changes broke the windows build because __attribute__ ((visibility ("hidden"))) is not supported in windows gcc. This change removes the attribute, as it is only needed when building shared libraries.

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

Fixes an issue where prepared statements that outlive many
connections become expensive to invoke.

Fixes #6081

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

Generated by addca.

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

This CL is an aggregate of 10271047, 10499043, 9733044. Descriptions of each follow:

10499043
runtime,cmd/ld: Merge TLS symbols and teach 5l about ARM TLS

This CL prepares for external linking support to ARM.

The pseudo-symbols runtime.g and runtime.m are merged into a single
runtime.tlsgm symbol. When external linking, the offset of a thread local
variable is stored at a memory location instead of being embedded into a offset
of a ldr instruction. With a single runtime.tlsgm symbol for both g and m, only
one such offset is needed.

The larger part of this CL moves TLS code from gcc compiled to internally
compiled. The TLS code now uses the modern MRC instruction, and 5l is taught
about TLS fallbacks in case the instruction is not available or appropriate.

10271047
This CL adds support for -linkmode external to 5l.

For 5l itself, use addrel to allow for D_CALL relocations to be handled by the
host linker. Of the cases listed in rsc's comment in issue 4069, only case 5 and
63 needed an update. One of the TODO: addrel cases was since replaced, and the
rest of the cases are either covered by indirection through addpool (cases with
LTO or LFROM flags) or stubs (case 74). The addpool cases are covered because
addpool emits AWORD instructions, which in turn are handled by case 11.

In the runtime, change the argv argument in the rt0* functions slightly to be a
pointer to the argv list, instead of relying on a particular location of argv.

9733044
The -shared flag to 6l outputs a shared library, implemented in Go
and callable from non-Go programs such as C.

The main part of this CL change the thread local storage model.
Go uses the fastest and least general mode, local exec. TLS data in shared
libraries normally requires at least the local dynamic mode, however, this CL
instead opts for using the initial exec mode. Initial exec mode is faster than
local dynamic mode and can be used in linux since the linker has reserved a
limited amount of TLS space for performance sensitive TLS code.

Initial exec mode requires an extra load from the GOT table to determine the
TLS offset. This penalty will not be paid if ld is not in -shared mode, since
TLS accesses will be reduced to local exec.

The elf sections .init_array and .rela.init_array are added to register the Go
runtime entry with cgo at library load time.

The "hidden" attribute is added to Cgo functions called from Go, since Go
does not generate call through the GOT table, and adding non-GOT relocations for
a global function is not supported by gcc. Cgo symbols don't need to be global
and avoiding the GOT table is also faster.

The changes to 8l are only removes code relevant to the old -shared mode where
internal linking was used.

This CL only address the low level linker work. It can be submitted by itself,
but to be useful, the runtime changes in CL 9738047 is also needed.

Design discussion at
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/zmjXkGrEx6Q

Fixes #5590.

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

1. Handle select statements.
2. Handle chan close.
3. Show top frame in debug mode (chansend/chanrecv/selectgo).
Fixes #6049.

R=golang-dev, daniel.morsing, rsc
CC=golang-dev
https://golang.org/cl/12694050

TBR=dvyukov
CC=golang-dev
https://golang.org/cl/12920043

mkvar was taking care of the "LeftAddr" case,
effectively hiding it from the temp-merging optimization.

Move it into prog.c.

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

See golang.org/s/go12encoding for design.

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

See golang.org/s/go12encoding for design.

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

fat fingers - did not intend to submit.
depends on the Unmarshaler CL anyway.

««« original CL description
encoding/xml: add, support Marshaler interface

See golang.org/s/go12xml for design.

Fixes #2771.
Fixes #4169.
Fixes #5975.
Fixes #6125.

R=golang-dev, iant, dan.kortschak
CC=golang-dev
https://golang.org/cl/12603044
»»»

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

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

See golang.org/s/go12encoding for design.

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

See golang.org/s/go12xml for design.

Fixes #2771.
Fixes #4169.
Fixes #5975.
Fixes #6125.

R=golang-dev, iant, dan.kortschak
CC=golang-dev
https://golang.org/cl/12603044

Fixes #5789.

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

Fixes #5126.

R=golang-dev, dsymonds, bradfitz, r, rsc, rogpeppe
CC=golang-dev
https://golang.org/cl/12566046

Do not use ? :
I cannot say this enough.

TBR=dvyukov
CC=golang-dev
https://golang.org/cl/12903043

Accessor to find where the bytes of a file start.

R=golang-dev, rsc, dsymonds, adg
CC=golang-dev
https://golang.org/cl/12784045

Update #4856

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

Update #6081

R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/12810043

Update #6138

TestOver65kFiles spends all its time garbage collecting.
Removing the 1.4 MB of allocations per each of the 65k
files brings this from 34 seconds to 0.23 seconds.

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

Use the fast path calculation to shorten the code.
No effect on benchmarks.

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

Before,
        go test -bench .
would just dump the long generic "go help" message. Confusing and
unhelpful. Now the message is short and on point and also reminds the
user about the oft-forgotten "go help testflag".

        % go test -bench
        go test: missing argument for flag bench
        run "go help test" or "go help testflag" for more information
        %

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

Now builders say:
pkg/net/dnsclient_unix_test.go:10: imported and not used: "runtime"

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

Windows builders say:
pkg\net\dnsclient_unix_test.go:24: undefined: dnsConfig
pkg\net\dnsclient_unix_test.go:25: undefined: exchange

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

The schedtrace value sets dump period in milliseconds.
In default mode the trace looks as follows:
SCHED 0ms: gomaxprocs=4 idleprocs=0 threads=3 idlethreads=0 runqueue=0 [1 0 0 0]
SCHED 1001ms: gomaxprocs=4 idleprocs=3 threads=6 idlethreads=3 runqueue=0 [0 0 0 0]
SCHED 2008ms: gomaxprocs=4 idleprocs=1 threads=6 idlethreads=1 runqueue=0 [0 1 0 0]
If GODEBUG=scheddetail=1 is set as well, then the detailed trace is printed:
SCHED 0ms: gomaxprocs=4 idleprocs=0 threads=3 idlethreads=0 runqueue=0 singleproc=0 gcwaiting=1 mlocked=0 nmspinning=0 stopwait=0 sysmonwait=0
  P0: status=3 tick=1 m=0 runqsize=1/128 gfreecnt=0
  P1: status=3 tick=0 m=-1 runqsize=0/128 gfreecnt=0
  P2: status=3 tick=0 m=-1 runqsize=0/128 gfreecnt=0
  P3: status=3 tick=0 m=-1 runqsize=0/128 gfreecnt=0
  M2: p=-1 curg=-1 mallocing=0 throwing=0 gcing=0 locks=1 dying=0 helpgc=0 spinning=0 lockedg=-1
  M1: p=-1 curg=-1 mallocing=0 throwing=0 gcing=0 locks=1 dying=0 helpgc=0 spinning=0 lockedg=-1
  M0: p=0 curg=1 mallocing=0 throwing=0 gcing=0 locks=1 dying=0 helpgc=0 spinning=0 lockedg=1
  G1: status=2() m=0 lockedm=0
  G2: status=1() m=-1 lockedm=-1

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

They don't work on older chips, just like the x86-32 64-bit atomics.

Update #6134

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

Breaks the build.  Old bucket arrays kept by iterators
still need to be scanned.

««« original CL description
runtime: tell GC not to scan internal hashmap structures.
We'll do it ourselves via hash_gciter, thanks.
Fixes bug 6119.

R=golang-dev, dvyukov, cookieo9, rsc
CC=golang-dev
https://golang.org/cl/12840043
»»»

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

We'll do it ourselves via hash_gciter, thanks.
Fixes bug 6119.

R=golang-dev, dvyukov, cookieo9, rsc
CC=golang-dev
https://golang.org/cl/12840043

The NetBSD and OpenBSD failures are apparently real,
not due to the test bug fixed in 100b9fc0c46f.

««« original CL description
runtime/pprof: test netbsd and openbsd again

Maybe these will work now.

R=golang-dev, dvyukov, bradfitz
CC=golang-dev
https://golang.org/cl/12787044
»»»

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

Fixes #6100.

R=golang-dev, dave, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/12703045

Currently it's possible that a goroutine
that periodically executes non-blocking
cgo/syscalls is never preempted.
This change splits scheduler and syscall
ticks to prevent such situation.

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

Currently we lose lots of profiling signals.
Most notably, GC is not accounted at all.
But stack splits, scheduler, syscalls, etc are lost as well.
This creates seriously misleading profile.
With this change all profiling signals are accounted.
Now I see these additional entries that were previously absent:
161  29.7%  29.7%      164  30.3% syscall.Syscall
 12   2.2%  50.9%       12   2.2% scanblock
 11   2.0%  55.0%       11   2.0% markonly
 10   1.8%  58.9%       10   1.8% sweepspan
  2   0.4%  85.8%        2   0.4% runtime.newstack
It is still impossible to understand what causes stack splits,
but at least it's clear how many time is spent on them.
Update #2197.
Update #5659.

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

Fixes #6070.
Update #6055.

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

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