With TLS 1.2, when sending client certificates the code was omitting
the new (in TLS 1.2) signature and hash fields.

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

All these features have in fact been implemented.

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

Fixes #6395.

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

The uint64 divide function calls _mul64x32 to do a 64x32-bit multiply
and then compares the result against the 64-bit numerator.
If the result is bigger than the numerator, must use the slow path.

Unfortunately, the 64x32 produces a 96-bit product, and only the
low 64 bits were being used in the comparison. Return all 96 bits,
the bottom 64 via the original uint64* pointer, and the top 32
as the function's return value.

Fixes 386 build (broken by ARM division tests).

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

Fixes #6399.

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

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

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

This CL is required for all.bat to work out of the box on
my Windows 8 laptop.

These tests either require the firewall to be turned off
or require the user to be in the Administrators group.
I don't know which.

Alex may follow up with a refinement of the test to
allow them to run if the user is in the Administrators
group.

Fixes #6392.

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

Because we can, and because it otherwise might crash
the program if we think we're out of memory.

Fixes #6390.

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

The implementation of division in the 5 toolchain is a bit too magical.
Hide the magic from the traceback routines.

Also add a test for the results of the software divide routine.

Fixes #5805.

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

The kernel implementation of the fast system call path,
the one invoked by the SYSCALL instruction, is broken for
restarting system calls. A C program demonstrating this is below.

Change the system calls to use INT $0x80 instead, because
that (perhaps slightly slower) system call path actually works.

I filed http://www.freebsd.org/cgi/query-pr.cgi?pr=182161.

The C program demonstrating that it is FreeBSD's fault is below.
It reports the same "Bad address" failures from wait.

#include <sys/time.h>
#include <sys/signal.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

static void handler(int);
static void* looper(void*);

int
main(void)
{
        int i;
        struct sigaction sa;
        pthread_cond_t cond;
        pthread_mutex_t mu;

        memset(&sa, 0, sizeof sa);
        sa.sa_handler = handler;
        sa.sa_flags = SA_RESTART;
        memset(&sa.sa_mask, 0xff, sizeof sa.sa_mask);
        sigaction(SIGCHLD, &sa, 0);

        for(i=0; i<2; i++)
                pthread_create(0, 0, looper, 0);

        pthread_mutex_init(&mu, 0);
        pthread_mutex_lock(&mu);
        pthread_cond_init(&cond, 0);
        for(;;)
                pthread_cond_wait(&cond, &mu);

        return 0;
}

static void
handler(int sig)
{
}

int
mywait4(int pid, int *stat, int options, struct rusage *rusage)
{
        int result;

        asm("movq %%rcx, %%r10; syscall"
                : "=a" (result)
                : "a" (7),
                  "D" (pid),
                  "S" (stat),
                  "d" (options),
                  "c" (rusage));
}

static void*
looper(void *v)
{
        int pid, stat, out;
        struct rusage rusage;

        for(;;) {
                if((pid = fork()) == 0)
                        _exit(0);
                out = mywait4(pid, &stat, 0, &rusage);
                if(out != pid) {
                        printf("wait4 returned %d\n", out);
                }
        }
}

Fixes #6372.

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

Fixes #6312.

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

Fixes #6367.

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

http://golang.org/doc/go1.1#new_packages

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

The -S flag reports symbol size, but is missing from the usage message.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/13660046

Remove "References" section.
Remove most articles and redirect to blog.golang.org.
Move /ref/spec and /ref/mem to /doc/spec and /doc/mem.
Remove duplicate links from the remaining
"Documents", "The Project", and "Help" pages.
Defer to the wiki for more links and community content.
Update command reference and mention cover tool.
Add "Pop-out" text to the front page.
Pick one of four videos at random to feature on the front page.

Fixes #2547.
Fixes #5561.
Fixes #6321.

R=r, dominik.honnef
CC=golang-dev
https://golang.org/cl/13724043

Document the semantic changes within the gc toolchain.

Also delete the mention of unbalanced right delims in template
That change was rolled back.

Absent typos, things we've forgotten, and new things that happen,
the release notes are ready.

R=golang-dev, adg, dominik.honnef
CC=golang-dev
https://golang.org/cl/13368052

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

Fixes #5821.

R=golang-dev, kamil.kisiel
CC=golang-dev
https://golang.org/cl/13720043

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/13721043

Everything is done except compiler changes and additional platforms, if any.

R=golang-dev, dominik.honnef, adg
CC=golang-dev
https://golang.org/cl/13484045

Previously, fields of type chan or func caused an error.
Now we just treat them like unexported fields and ignore them.
This makes it easier to guarantee long-term compatibilty since
a substructure from another package cannot break gob
encoding by adding a func or chan field.

Fixes #6071

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

The test 'gp == m->curg' is not valid on Windows,
because the goroutine being profiled is not from the
current m.

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

Fixes #6369.

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

Fixes #5626.

R=golang-dev, dominik.honnef
CC=golang-dev
https://golang.org/cl/13702043

Just an oversight they were missing.
Fixes #6387

R=golang-dev, dominik.honnef, rsc
CC=golang-dev
https://golang.org/cl/13715043

Fake types describing the internal structure of hashmaps are
generated for use by precise GC.

Generating hash and eq functions for these fake types slows down
the build and wastes space: the go tool binary size is 13MB
instead of 12MB, and the package size on amd64 is 48.7MB instead
of 45.3MB.

R=golang-dev, daniel.morsing, r, khr, rsc, iant
CC=golang-dev
https://golang.org/cl/13698043

(StdinPipe was taken care of by CL 13329043.)

Fixes #6008.

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

Because profiling signals can arrive at any time, we must
handle the case where a profiling signal arrives halfway
through a goroutine switch. Luckily, although there is much
to think through, very little needs to change.

Fixes #6000.
Fixes #6015.

R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/13421048

Fixes #4876.

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

Fixes #6355.

zerrors_linux_{386,amd64,arm}.go were regenerated using mkerrors.sh but I opted to add the three TC.*FLUSH lines by hand to keep the diff smaller and avoid problems with the API checker.

I'll check freebsd and darwin, could I ask for help with net/open bsd.

R=mikioh.mikioh, jsing, minux.ma, bradfitz
CC=golang-dev
https://golang.org/cl/13660043

Keith is too clever for me.

R=ken2
CC=golang-dev, khr
https://golang.org/cl/13272050

goyacc: Fix debug printing of the lexed token's ID and name, and add whitespace in the 'stateX saw' message.

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

R=golang-dev, dave, adg, dsymonds
CC=golang-dev
https://golang.org/cl/13692043

It's too late to change this behavior: it breaks templates with minimized JavaScript.

Makes me sad because this common error can never be caught: "{foo}}".
Three cheers for compatibility.

(Leave in a fix to a broken test.)

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

This reverts CL 13261048. I have just learned that these are
no longer supported on code.google.com (that is, it is impossible
to create them), so there is little reason to add support in
Go 1.2.

Update #5408

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

Fixes #6356.

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

Fixes #6365.

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

Bug #1:

Issue 5406 identified an interesting case:
        defer iface.M()
may end up calling a wrapper that copies an indirect receiver
from the iface value and then calls the real M method. That's
two calls down, not just one, and so recover() == nil always
in the real M method, even during a panic.

[For the purposes of this entire discussion, a wrapper's
implementation is a function containing an ordinary call, not
the optimized tail call form that is somtimes possible. The
tail call does not create a second frame, so it is already
handled correctly.]

Fix this bug by introducing g->panicwrap, which counts the
number of bytes on current stack segment that are due to
wrapper calls that should not count against the recover
check. All wrapper functions must now adjust g->panicwrap up
on entry and back down on exit. This adds slightly to their
expense; on the x86 it is a single instruction at entry and
exit; on the ARM it is three. However, the alternative is to
make a call to recover depend on being able to walk the stack,
which I very much want to avoid. We have enough problems
walking the stack for garbage collection and profiling.
Also, if performance is critical in a specific case, it is already
faster to use a pointer receiver and avoid this kind of wrapper
entirely.

Bug #2:

The old code, which did not consider the possibility of two
calls, already contained a check to see if the call had split
its stack and so the panic-created segment was one behind the
current segment. In the wrapper case, both of the two calls
might split their stacks, so the panic-created segment can be
two behind the current segment.

Fix this by propagating the Stktop.panic flag forward during
stack splits instead of looking backward during recover.

Fixes #5406.

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

This is a follow-up to feedback from gri in
https://golang.org/cl/12837044/. Most of the wording
and naming improvements are lifted shamelessly from him.

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