[release-branch.go1.3] time: removed from tests now obsolete assumption about Australian tz abbreviations

??? CL 130920043 / 7dba9475ee72
time: removed from tests now obsolete assumption about Australian tz abbreviations

Australian timezones abbreviation for standard and daylight saving time were recently
changed from EST for both to AEST and AEDT in the icann tz database (see changelog
on www.iana.org/time-zones).

A test in the time package was written to check that the ParseInLocation function
understand that Feb EST and Aug EST are different time zones, even though they are
both called EST. This is no longer the case, and the Date function now returns
AEST or AEDT for australian tz on every Linux system with an up to date tz database
(and this makes the test fail).

Since I wasn't able to find another country that 1) uses daylight saving and 2) has
the same abbreviation for both on tzdata, I changed the test to make sure that
ParseInLocation does not get confused when it parses, in different locations, two
dates with the same abbreviation (this was suggested in the mailing list).

Fixes issue 8547.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/130920043

Committer: Brad Fitzpatrick <bradfitz@golang.org>
???

LGTM=dsymonds
R=rsc, dsymonds
CC=golang-codereviews
https://codereview.appspot.com/153720043
[release-branch.go1.3] net: temporarily skip TestAcceptIgnoreSomeErrors

??? CL 138120043 / 9a36c3ea7015
net: temporarily skip TestAcceptIgnoreSomeErrors

Update issue 8662

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/138120043

Committer: Brad Fitzpatrick <bradfitz@golang.org>
???

LGTM=dsymonds
R=dsymonds
CC=golang-codereviews
https://codereview.appspot.com/149200043
[release-branch.go1.3] runtime: hide cgocallback_gofunc calling cgocallbackg from linker

The linker error at
http://build.golang.org/log/42c57ff6b57ab36f6622417108bb5697e4d36fa7
is a false positive: cgocallback_gofunc is invoked on the g0 stack,
as explained in its comments, and then it switches to the m->curg
stack to invoke cgocallbackg. Checking the stacksplit sequence
on the g0 stack doesn't make sense, nor does carrying a check
that starts on the g0 stack over to the curg stack.
Change the code to use an indirect call so that the linker
stacksplit check does not follow through it.

LGTM=bradfitz, adg
R=golang-codereviews, bradfitz, adg
CC=golang-codereviews, iant, r
https://codereview.appspot.com/146510043
[release-branch.go1.3] runtime: fix GOTRACEBACK reading on Windows, Plan 9

Only Unix was resetting the traceback_cache variable
after initializing the environment. Reset it on all systems
by resetting in parsedebugvars.

Fixes issue 8813.

LGTM=adg, alex.brainman
R=golang-codereviews, adg, alex.brainman
CC=golang-codereviews, iant, r
https://codereview.appspot.com/152760043
[release-branch.go1.3] nacltest.bash: unset GOROOT

The GOROOT baked into the go command being run is correct.
The GOROOT in the environment may not be. Remove it.

Fixes nacltest.bash if you have GOROOT set elsewhere.

This is already fixed in the default branch.

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://codereview.appspot.com/147380044
[release-branch.go1.3] cmd/5l, cmd/6l, cmd/8l: fix nacl binary corruption bug

??? CL 135050043 / 57dfd03985a9
cmd/5l, cmd/6l, cmd/8l: fix nacl binary corruption bug

NaCl requires the addition of a 32-byte "halt sled" at the end
of the text segment. This means that segtext.len is actually
32 bytes shorter than reality. The computation of the file offset
of the end of the data segment did not take this 32 bytes into
account, so if len and len+32 rounded up (by 64k) to different
values, the symbol table overwrote the last page of the data
segment.

The last page of the data segment is usually the C .string
symbols, which contain the strings used in error prints
by the runtime. So when this happens, your program
probably crashes, and then when it does, you get binary
garbage instead of all the usual prints.

The chance of hitting this with a randomly sized text segment
is 32 in 65536, or 1 in 2048.

If you add or remove ANY code while trying to debug this
problem, you're overwhelmingly likely to bump the text
segment one way or the other and make the bug disappear.

Correct all the computations to use segdata.fileoff+segdata.filelen
instead of trying to rederive segdata.fileoff.

This fixes the failure during the nacl/amd64p32 build.

TBR=iant
CC=golang-codereviews
https://codereview.appspot.com/135050043
???

LGTM=bradfitz
R=golang-codereviews
CC=adg, bradfitz, golang-codereviews, iant
https://codereview.appspot.com/151150044
[release-branch.go1.3] doc: document go1.3.3

??? CL 149280044 / ce32e953ef6f
doc: document go1.3.3

LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/149280044
???

TBR=r
R=golang-codereviews
CC=golang-codereviews
https://codereview.appspot.com/151170043
go1.3.3

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/151190043