This lays the groundwork for making Go robust when the system's
calendar time jumps around. All input values to the runtimeTimer
struct now use the runtime clock as a common reference point.
This affects net.Conn.Set[Read|Write]Deadline(), time.Sleep(),
time.Timer, etc. Under normal conditions, behavior is unchanged.

Each platform and architecture's implementation of runtime·nanotime()
should be modified to use a monotonic system clock when possible.

Platforms/architectures modified and tested with monotonic clock:
  linux/x86     - clock_gettime(CLOCK_MONOTONIC)

Update #6007

LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, alex.brainman, stephen.gutekanst, dave, rsc, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/53010043

LGTM=rsc
R=golang-codereviews, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/64770043

Update #6963 Fixes pretty printing maps and updates
functions for interacting with $len(). goroutine $n bt
remains not working. Tested on gdb using python 2 and 3.
Fixes #7052
Update #6963
Fixes #6698

LGTM=rsc
R=golang-codereviews, josharian, rsc
CC=golang-codereviews
https://golang.org/cl/53590043

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

One defer was not removed in CL61150043.

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

After "runtime: combine small NoScan allocations" finalizers
for small objects run more non deterministically.
TestRaceFin episodically fails on my darwin/amd64.

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

Also updates documentation.

LGTM=minux.ma
R=iant, bradfitz, nightlyone, minux.ma
CC=golang-codereviews
https://golang.org/cl/58660044

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

As per request from minux in CL 61520049, this CL consolidates
existing test cases for Unix-like systems into one file except
Linux-specific credential test.

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

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

Fix build for 10.6 Darwin builders and OpenBSD builers.

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

Fixes #7223.

LGTM=rsc
R=golang-codereviews, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/63040043

Fix build for Dragonfly BSD.
Fixes #7318.
Fixes #7367.

LGTM=jsing, iant
R=jsing, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/64340043

LGTM=minux.ma, r
R=golang-codereviews, minux.ma, r
CC=golang-codereviews
https://golang.org/cl/67280043

Generated by addca.

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

Fixes #7361.

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

crypto/tls has two functions for creating a client connection: Dial,
which most users are expected to use, and Client, which is the
lower-level API.

Dial does what you expect: it gives you a secure connection to the host
that you specify and the majority of users of crypto/tls appear to work
fine with it.

Client gives more control but needs more care. Specifically, if it
wasn't given a server name in the tls.Config then it didn't check that
the server's certificates match any hostname - because it doesn't have
one to check against. It was assumed that users of the low-level API
call VerifyHostname on the certificate themselves if they didn't supply
a hostname.

A review of the uses of Client both within Google and in a couple of
external libraries has shown that nearly all of them got this wrong.

Thus, this change enforces that either a ServerName or
InsecureSkipVerify is given. This does not affect tls.Dial.

See discussion at https://groups.google.com/d/msg/golang-nuts/4vnt7NdLvVU/b1SJ4u0ikb0J.

Fixes #7342.

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

Generated by addca.

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

The old error was "call of reflect.Value.Field on ptr Value".

http://play.golang.org/p/Zm-ZbQaPeR

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

Generated by addca.

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

SetPanicOnFault allows recovery from unexpected memory faults.
This can be useful if you are using a memory-mapped file
or probing the address space of the current program.

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

Package runtime's C functions written to be called from Go
started out written in C using carefully constructed argument
lists and the FLUSH macro to write a result back to memory.

For some functions, the appropriate parameter list ended up
being architecture-dependent due to differences in alignment,
so we added 'goc2c', which takes a .goc file containing Go func
declarations but C bodies, rewrites the Go func declaration to
equivalent C declarations for the target architecture, adds the
needed FLUSH statements, and writes out an equivalent C file.
That C file is compiled as part of package runtime.

Native Client's x86-64 support introduces the most complex
alignment rules yet, breaking many functions that could until
now be portably written in C. Using goc2c for those avoids the
breakage.

Separately, Keith's work on emitting stack information from
the C compiler would require the hand-written functions
to add #pragmas specifying how many arguments are result
parameters. Using goc2c for those avoids maintaining #pragmas.

For both reasons, use goc2c for as many Go-called C functions
as possible.

This CL is a replay of the bulk of CL 15400047 and CL 15790043,
both of which were reviewed as part of the NaCl port and are
checked in to the NaCl branch. This CL is part of bringing the
NaCl code into the main tree.

No new code here, just reformatting and occasional movement
into .h files.

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

Match used len(ar.files) == 0 to mean "match everything"
but it also deleted matched things from the list, so once you
had matched everything you asked for, match returned true
for whatever was left in the archive too.

Concretely, if you have an archive containing f1, f2, then
        pack t foo.a f1
would match f1 and then, because len(ar.files) == 0 after
deleting f1 from the match list, also match f2.

Avoid the problem by recording explicitly whether match
matches everything.

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

The message used to say that there was a type
mismatch, which is not necessarily true.

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/66600044

Fixes #7363.

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

The liblink refactor changed the DWARF .debug_line flow control. The mapping was off by one pcline entry. The fix here preserves pc until it can be compared to pcline.pc.

Sample dwarfdump .debug_line output for main.main from the program in issue 7351, before liblink (correct):

0x0000003c: 00 Extended: <9> 02 DW_LNE_set_address( 0x0000000000002000 )
0x00000047: 03 DW_LNS_advance_line( 6 )
0x00000049: 01 DW_LNS_copy
            0x0000000000002000      1      7      0 is_stmt

0x0000004a: 8b address += 21,  line += 1
            0x0000000000002021      1      8      0 is_stmt

0x0000004b: 02 DW_LNS_advance_pc( 153 )
0x0000004e: 03 DW_LNS_advance_line( 1 )
0x00000050: 01 DW_LNS_copy
            0x00000000000020ba      1      9      0 is_stmt

After liblink (off by one entry):

0x00001bbf: 00 Extended: <9> 02 DW_LNE_set_address( 0x0000000000002000 )
0x00001bca: 02 DW_LNS_advance_pc( 33 )
0x00001bcc: 03 DW_LNS_advance_line( 6 )
0x00001bce: 01 DW_LNS_copy
            0x0000000000002021      1      7      0 is_stmt

0x00001bcf: 02 DW_LNS_advance_pc( 153 )
0x00001bd2: 03 DW_LNS_advance_line( 1 )
0x00001bd4: 01 DW_LNS_copy
            0x00000000000020ba      1      8      0 is_stmt

0x00001bd5: 02 DW_LNS_advance_pc( 153 )
0x00001bd8: 03 DW_LNS_advance_line( 1 )
0x00001bda: 01 DW_LNS_copy
            0x0000000000002153      1      9      0 is_stmt

After this CL (the line 9 pc offset changed due to intervening compiler changes):

0x00001d07: 00 Extended: <9> 02 DW_LNE_set_address( 0x0000000000002000 )
0x00001d12: 03 DW_LNS_advance_line( 6 )
0x00001d14: 01 DW_LNS_copy
            0x0000000000002000      1      7      0 is_stmt

0x00001d15: 8b address += 21,  line += 1
            0x0000000000002021      1      8      0 is_stmt

0x00001d16: 02 DW_LNS_advance_pc( 189 )
0x00001d19: 03 DW_LNS_advance_line( 1 )
0x00001d1b: 01 DW_LNS_copy
            0x00000000000020de      1      9      0 is_stmt

Fixes #7351.

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

Rename should fail when the directory doesn't match.
It will fix the newly introduced test from cmd/pack
on Plan 9.

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

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

Try to prevent messages like this:
        './pack' file does not exist����������������������������������������������������������������������������������������������������
TBR=adonovan

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/66270043

otherwise go build command adds .exe suffix

Fixes #7362

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

Plan 9 uses single quotes, not double quotes. I should have known.

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

Windows at least doesn't emit one.
Maybe fix Windows build.

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

Get more information to help understand build failure on Plan 9.
Also Windows.
(TestHello is failing because GOCHAR does not appear in output.
What does?)

Update #7362

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

[Repeat of CL 64100044, after 32-bit fix in CL 66170043.]

Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.

The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.

This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).

There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.

The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.

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

The code here is being restored after its deletion in CL 14430048.

I restored the copy in cmd/6g in CL 56430043 but neglected the
other two.

This is the reason that enabling precisestack only worked on amd64.

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

When Go 1.3 is released, this will keep existing
Go 1.2 build scripts that use 'go tool pack grc' working.
For efficiency, such scripts should be changed to
use 6g -pack instead, but keeping the old behavior
available enables a more graceful transition.

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

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

There are probably more of these, but bound and len are 64 bits so use %lld
in message about array index out of bounds.
Fixes the 386 build.

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

Taking my own advice from a review of addr2line.

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

We never updated libmach for the new object file format,
so it the existing 'go tool addr2line' is broken.
Reimplement in Go to fix.

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