Change-Id: I624b336a9eb27fbbc8ef13f141023b4f60966245
Reviewed-on: https://go-review.googlesource.com/8240Reviewed-by: Ian Lance Taylor <iant@golang.org>

runtime·main·f is normalized by the linker to runtime.main.f, as is
the compiler-generated symbol runtime.main·f.  Change the former to
runtime·mainPC instead.

Fixes issue #9934

Change-Id: I656a6fa6422d45385fa2cc55bd036c6affa1abfe
Reviewed-on: https://go-review.googlesource.com/8234
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

For shared libraries we need to be more flexible in how these symbols
are handled (e.g. sometimes tlsg needs to be global, or you can get
a SDYNIMPORT symbol that has .Hide == true) so handling these cases
in genasmsym makes everything much more regular.

Even ignoring shared libraries, I think this is a bit cleaner.

Change-Id: If5beb093a261e79f4496183226e1765ee7aa6717
Reviewed-on: https://go-review.googlesource.com/8230
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

After moving the darwin/arm builder to new hardware several new flaky
error messages appeared. This provided enough information to Google
to make it clear that iOS build systems have been flaky for many
years, and that is unlikely to change any time soon.

However, all of the pain of lldb and using a breakpoint early in
program initialization gives us an advantage: all install and
initialization flakiness appears to happen before the Go program ever
gets going. So if we see an error or we timeout before we reach our
breakpoint (before any test code has executed), we can assume it is
the fault of the builder and restart without risking hiding a flaky
Go test.

This code has successfully processed the last 8 builds. I am hopeful.

Change-Id: Ide24aaae4fa7bdab9d8f4432bb85d8f2256c7606
Reviewed-on: https://go-review.googlesource.com/8241Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

In the spirit of nacltest.bash and androidtest.bash. Sets up the
exec script and reboots the device.

The reboot helps make sure previous runs do not interfere with the
current run. It is reasonably easy for a bad program, e.g. one with
a corrupt stack, to get the device stuck.

Change-Id: I61317527741c45a70c390fe21adc4895510fc79f
Reviewed-on: https://go-review.googlesource.com/8242Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

Change-Id: Icbc42bcff5a3eabe9f43cff7fcc126141e209ded
Reviewed-on: https://go-review.googlesource.com/8203Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Extend escape analysis to convT2E and conT2I. If the interface value
does not escape supply runtime with a stack buffer for the object copy.

This is a straight port from .c to .go of Dmitry's patch

Change-Id: Ic315dd50d144d94dd3324227099c116be5ca70b6
Reviewed-on: https://go-review.googlesource.com/8201Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Windows XP SP2 and Windows 2003 do not support SHA2.

Change-Id: Ica5faed040e9ced8b79fe78d512586e0e8788b3f
Reviewed-on: https://go-review.googlesource.com/8167
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Currently, various functions are marked with the comment

  // May run without a P, so write barriers are not allowed.

However, "running without a P" is ambiguous. We intended these to mean
that m.p may be nil (which is the condition checked by the write
barrier). The comment could also be taken to mean that a
stop-the-world may happen, which is not the case for these functions
because they run in situations where there is in fact a function on
the stack holding a P locally, it just isn't in m.p.

Change these comments to state precisely what we mean, that m.p may be
nil.

Change-Id: I4a4a1d26aebd455e5067540e13b9f96a7482146c
Reviewed-on: https://go-review.googlesource.com/8209Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: Id82c3111d7571263208ced3d011ad80f3fe55984
Reviewed-on: https://go-review.googlesource.com/7892Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

False positives (var incorrectly escapes) are marked with BAD.

Change-Id: I002ac5965ec6748adafa2c4c657c97d8f7ff75d0
Reviewed-on: https://go-review.googlesource.com/5311Reviewed-by: Keith Randall <khr@golang.org>

The previous wording implied that reads would return no error, rather
than EOF. It's convenient for users to know that Close() is equivalent
to CloseWithError(nil) because it can remove a branch from their error
handling code where they want to close the pipe in the appropriate way.
For example:

    https://github.com/jacobsa/gcloud/blob/6e9a8cec0a3f0834da3e9c9725dfe0bf79cccebb/gcs/bucket.go#L637-L643

Change-Id: I618bffe556eb518011e7ba5cdce1eb0ff536350e
Reviewed-on: https://go-review.googlesource.com/8152Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Don't test so much at once.

Fixes #10278

Change-Id: I32a9cb81a3cffecc7ce4f83c35a4b589bcd3a9f7
Reviewed-on: https://go-review.googlesource.com/8213Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When Windows Error Reporting dialog is disabled on amd64
Windows XP or 2003, the continue handler does not fire. Newer
versions work correctly regardless of WER.

Fixes #10162

Change-Id: I84ea36ee188b34d1421a8db6231223cf61b4111b
Reviewed-on: https://go-review.googlesource.com/8165Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

rp.Close happened concurrently with rp.Read. Order them.

Fixes #10280

Change-Id: I7b083bcc336d15396c4e42fc4654ba34fad4a4cc
Reviewed-on: https://go-review.googlesource.com/8211Reviewed-by: Dave Cheney <dave@cheney.net>

The false positives (var incorrectly escapes) are marked with BAD.

Change-Id: If64fabb6ea96de44a1177d9ab12e2ccc579fe0c4
Reviewed-on: https://go-review.googlesource.com/5294Reviewed-by: Keith Randall <khr@golang.org>

10 false positives (var incorrectly escapes to heap) are marked with BAD.

Change-Id: I773b13a18ff55aaa499a2a28a979118422cc5322
Reviewed-on: https://go-review.googlesource.com/5293Reviewed-by: Keith Randall <khr@golang.org>

Fix build after http://golang.org/cl/5297
The compiler was changed to not print implicit map capacity in error messages.

Change-Id: I852f668680c3c69c5eecc7964e46202a97014d6a
Reviewed-on: https://go-review.googlesource.com/8212Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

The false positive (var incorrectly escapes to heap) is marked with BAD.

Change-Id: I11877fa8e976094b31a221abd88ae32d351c85ee
Reviewed-on: https://go-review.googlesource.com/5292Reviewed-by: Keith Randall <khr@golang.org>

False positives (var incorrectly escapes) are marked with BAD.

Change-Id: I8383fa3f77e2156d781d994968636ba9a17bb975
Reviewed-on: https://go-review.googlesource.com/5297Reviewed-by: Keith Randall <khr@golang.org>

False positives (var incorrectly escapes) are marked with BAD.

Change-Id: I0114d87ee467fe1e3b27642f8c5a04d4a9664211
Reviewed-on: https://go-review.googlesource.com/5295Reviewed-by: Keith Randall <khr@golang.org>

False positives (var incorrectly escapes) are marked with BAD.

Change-Id: I3027b6e0f5b48325e6169599400cc59e1394809f
Reviewed-on: https://go-review.googlesource.com/5431Reviewed-by: Keith Randall <khr@golang.org>

False positives (var incorrectly escapes) are marked with BAD.

Change-Id: I9e9a3f71b060520103bcf289829a2efdf6f2b517
Reviewed-on: https://go-review.googlesource.com/5298Reviewed-by: Keith Randall <khr@golang.org>

False positives (var incorrectly escapes) are marked with BAD.

Change-Id: I646a29ffe24d963c63db09cba81dbc101d7c7242
Reviewed-on: https://go-review.googlesource.com/5296Reviewed-by: Keith Randall <khr@golang.org>

Racy tests do not fail currently, they do os.Exit(0).
So if you run go test without -v, you won't even notice.
This was probably introduced with testing.TestMain.

Racy programs do not have the right to finish successfully.

Change-Id: Id133d7424f03d90d438bc3478528683dd02b8846
Reviewed-on: https://go-review.googlesource.com/4371Reviewed-by: Russ Cox <rsc@golang.org>

This change consolidates test helpers that test platform capabilities.
testNetwork, testAddress and testListenArgs report whether given
ariguments are testable on the current platform configuration to
mitigate to receive weird test results.

Change-Id: Ie1ed568a1f9cc50f3155945ea01562904bc2c389
Reviewed-on: https://go-review.googlesource.com/8076Reviewed-by: Ian Lance Taylor <iant@golang.org>

We need this in order to pass the "-shared" flag to the assembler.

Change-Id: I9c15cfe4d32c1e5e8cae1b9b2c924cfd77923b55
Reviewed-on: https://go-review.googlesource.com/7694Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Suggested by iant@, this change:
  - looks for a symbol _rt0_<GOARCH>_<GOOS>_lib,
  - if the symbol is present, adds a new entry into the .init_array ELF
    section that points to the symbol.

The end-effect is that the symbol _rt0_<GOARCH>_<GOOS>_lib will be
invoked as soon as the (ELF) shared library is loaded, which will in turn
initialize the runtime. (To be implemented.)

Change-Id: I99911a180215a6df18f8a18483d12b9b497b48f4
Reviewed-on: https://go-review.googlesource.com/7692
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: If986ed2cf94efba92763d00a3182047c05d6f805
Reviewed-on: https://go-review.googlesource.com/8133Reviewed-by: Minux Ma <minux@golang.org>

covermode is not passed to 6.out, so it should not be grouped
with the flags that are. Move it to the "local" section.

Change-Id: Id487898962e7ab7adf98b0854c2f1802116bec11
Reviewed-on: https://go-review.googlesource.com/8132Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: Iacbf06cf30a8a9630d8ee1f6934cbdef93ae0fc9
Reviewed-on: https://go-review.googlesource.com/8163Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

1) Large allocation in this test caused crash. This was not
detected by builder because builder runs tests with -test.short.

2) The command "go" for forking doesn't exist in some platforms
including android. This change uses the test binary itself which
is guaranteed to exist.

This change also adds logging of the total samples collected in
TestCPUProfileMultithreaded test that is flaky in android-arm
builder.

Change-Id: I225c6b7877d811edef8b25e7eb00559450640c42
Reviewed-on: https://go-review.googlesource.com/8131Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The previously-submitted https://go-review.googlesource.com/#/c/6701
didn't include dragonfly, freebsd, nacl, netbsd, openbsd, or solaris.
(or things like darwin/arm or ppc64 or arm64)

So do them all.

Note I had to copy the function into tables_nacl.go. I found that
preferable to creating a new file just to have suitable build
tags. It's likely this function will be mirrored to plan9 and windows
later too, each of the 4 with their own policy of which error values
are common.

The corresponding x/sys CL for this CL is https://golang.org/cl/8190
but it excludes nacl (not in x/sys) and solaris (already broken).

Update Issue #8859

Change-Id: I91902615692b29b69c905edd9e126a26337294f6
Reviewed-on: https://go-review.googlesource.com/8192Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Added the inverse of TypeByExtension for discovering an appropriate
extensions for a given MIME type.

Fixes #10144

Change-Id: I6a80e1af3db5d45ad6a4c7ff4ccfdf6a4f424367
Reviewed-on: https://go-review.googlesource.com/7444
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Update #8859

Change-Id: I5b0005b308e83954a495f06d27b7d8d30e813820
Reviewed-on: https://go-review.googlesource.com/8193Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: Ia7a08bc855db87890d35b2a1667e245ce5ecf472
Reviewed-on: https://go-review.googlesource.com/8197Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

There is no top-level Values function.

Change-Id: I3ea2eea0b5f77f3e1a3f75d1a6472507ef2888bb
Reviewed-on: https://go-review.googlesource.com/8196Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I6a91d255b9e9f66b0288b82af4303f9a9b4b373c
Reviewed-on: https://go-review.googlesource.com/8191Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #8859

Change-Id: If8098e6edad1f83dc35fa84f4431689e8ee97678
Reviewed-on: https://go-review.googlesource.com/6701Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The previous change was
https://go-review.googlesource.com/#/c/8073/

Change-Id: I0c48502d1ba90fb5d41c5e66346a8e7f4ee87ce7
Reviewed-on: https://go-review.googlesource.com/8151Reviewed-by: Nigel Tao <nigeltao@golang.org>