Float type from a mutex to atomic bit array in a manner akin to
Google Guava's AtomicDouble[0], including adding a benchmark for the
type (benchcmp included below) along with some expvar_test.go cruft
being fixed.

benchmark             old ns/op     new ns/op     delta
BenchmarkFloatSet     115           9.37          -91.85%
BenchmarkFloatAdd     114           17.1          -85.00%

benchmark             old allocs     new allocs     delta
BenchmarkFloatSet     0              0              +0.00%
BenchmarkFloatAdd     0              0              +0.00%

benchmark             old bytes     new bytes     delta
BenchmarkFloatSet     0             0             +0.00%
BenchmarkFloatAdd     0             0             +0.00%

[0] - http://goo.gl/m4dtlI

Change-Id: I4ce6a913734ec692e3ed243f6e6f7c11da4c6036
Reviewed-on: https://go-review.googlesource.com/3687Reviewed-by: Rob Pike <r@golang.org>

This test checks the working directory is
always consistent after Chdir in a Go program.

Fixes #10035.

Change-Id: I6abf0e4fcd40680ee572c6b40fc52ab17ef38d54
Reviewed-on: https://go-review.googlesource.com/6382Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

In Plan 9, goroutines can run in different processes,
which don't share their working directory. However,
Go expects the working directory to be program-wide.

We use a Fixwd function to fix the working directory
before calling system calls which depend on the
working directory.

In fixwdLocked, the working directory is not fixed
when getwd returns an error. However, an error can
happen is some cases, notably when the directory
has been previously removed in another process.

Fixes #10422.

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

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

Currently, Entry has a Val method that looks up an attribute and
returns its value. Now that Field has more fields than the attribute
and its value, it's useful to return the whole Field and let the
caller retrieve the parts it needs.

This change adds an AttrField method to Entry that does the same
lookup at Val, but returns the whole *Field rather than just the
value.

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

To return DWARF attribute values, debug/dwarf maps the DWARF attribute
value classes to Go types. Unfortunately, this mapping is ambiguous in
a way that makes it impossible to correctly interpret some DWARF
attributes as of DWARF 4. For example, AttrStartScope can be either a
constant or a rangelistptr. The attribute is interpreted differently
depending on its class, but debug/dwarf maps both classes to int64, so
the caller can't distinguish them from the Go type.
AttrDataMemberLocation is similar.

To address this, this change adds a field to type Field that indicates
the exact DWARF attribute value class of that field's value. This
makes it possible to distinguish value classes that can't be
distinguished by their Go type alone.

The root of this type ambiguity was DWARF itself. For example, DWARF 2
made no distinction between constants that were just constants and
constants that were section offsets because no attribute could have
both meanings. Hence, the single int64 type was sufficient. To avoid
introducing just another layer of ambiguity, this change takes pains
to canonicalize ambiguous classes in DWARF 2 and 3 files into the
unambiguous classes of DWARF 4.

Of course, there's no guarantee that future DWARF versions won't do
the same thing again and further subdivide the DWARF 4 classes. This
change gets ahead of this somewhat by distinguishing the various *ptr
classes even though the encoding does not. If there's some other form
of split, we can handle this in a backwards-compatible way by
introducing, for example, a Class5 field and type.

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

Uses ar to create an archive when -buildmode=c-archive.

A small example (that I hope to turn into a test in a later CL):

goarchive.go:
	package main

	import "fmt"

	import "C"

	func init() {
		fmt.Println("ran go init")
	}

	//export FuncInGo
	func FuncInGo() {
		fmt.Println("called a go function")
	}

	func main() {
		fmt.Println("in main")
	}

This can be compiled with:

	go build -ldflags=-buildmode=c-archive -o=libgo.a goarchive.go

main.c:

	#include <stdio.h>

	extern void FuncInGo();

	int main(void) {
		printf("c hello\n");
		FuncInGo();
		printf("c goodbye\n");
		return 0;
	}

Can be compiled with:

	cc main.c libgo.a

Apple provide a warning about the lack of PIE, but still produce a
binary which runs and outputs (on darwin/amd64):

	c hello
	ran go init
	called a go function
	c goodbye

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

Tested by using -buildmode=c-archive to generate an archive, add it
to an Xcode project and calling a Go function from an iOS app. (I'm
still investigating proper buildmode tests for all.bash.)

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

Just like darwin/arm.

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

Just like darwin/arm, cannot fork..

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

Just like darwin/arm.

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

Just like darwin/arm.

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

Just like darwin/arm.

Change-Id: Ib64a3e8ff11249a20b0208bd3b900db318c682b7
Reviewed-on: https://go-review.googlesource.com/8817Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Similar to darwin/arm. This issue is quite worrying and I hope it
can be addressed for Go 1.5.

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

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

Change-Id: Id469165b1acd383837b1f4e1e6f961e10dfa5d61
Reviewed-on: https://go-review.googlesource.com/8332Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

While here, this changes DWAbbrev's attr field from a [30]DWAttrForm
with zero-termination to a simple []DWAttrForm, and updates its users
accordingly.

Passes "go build -toolexec 'toolstash -cmp' -a std" on linux/amd64.

Change-Id: I52b5f7a749bdb3e7588fc8ebdb8fee2cf8cab602
Reviewed-on: https://go-review.googlesource.com/8762
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>

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

The symbols for the actual data in a constant string or bytes literal should
be local.

Change-Id: Idafcfba9a638eaa4e460e5103d96843960559b35
Reviewed-on: https://go-review.googlesource.com/8772Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

When dynamically linking Go code, it is no longer safe to assume that
strings that end up in method names are identical if they are equal.

The performance impact seems to be noise:

benchmark                    old ns/op     new ns/op     delta
BenchmarkAssertI2E2          13.3          13.1          -1.50%
BenchmarkAssertE2I           23.5          23.2          -1.28%
BenchmarkAssertE2E2Blank     0.83          0.82          -1.20%
BenchmarkConvT2ISmall        60.7          60.1          -0.99%
BenchmarkAssertI2T           10.2          10.1          -0.98%
BenchmarkAssertE2T           10.2          10.3          +0.98%
BenchmarkConvT2ESmall        56.7          57.2          +0.88%
BenchmarkConvT2ILarge        59.4          58.9          -0.84%
BenchmarkConvI2E             13.0          12.9          -0.77%
BenchmarkAssertI2E           13.4          13.3          -0.75%
BenchmarkConvT2IUintptr      57.9          58.3          +0.69%
BenchmarkConvT2ELarge        55.9          55.6          -0.54%
BenchmarkAssertI2I           23.8          23.7          -0.42%
BenchmarkConvT2EUintptr      55.4          55.5          +0.18%
BenchmarkAssertE2E           6.12          6.11          -0.16%
BenchmarkAssertE2E2          14.4          14.4          +0.00%
BenchmarkAssertE2T2          10.0          10.0          +0.00%
BenchmarkAssertE2T2Blank     0.83          0.83          +0.00%
BenchmarkAssertE2TLarge      10.7          10.7          +0.00%
BenchmarkAssertI2E2Blank     0.83          0.83          +0.00%
BenchmarkConvI2I             23.4          23.4          +0.00%

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

This will fruitlessly rebuild stale packages that are in a shared
library.

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

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

This will make it possible to access the gcimporter (and gccgoimporter,
eventually) from the forthcoming gc/importer package, without exposing
compiler names in package names.

This change was created by manually adjusting the gcimporter paths in
go/types.bash and then running sh go/types.bash (i.e., by revendoring
gcimporter). The only manual changes are in go/types.bash.

Change-Id: Idc282439742288c09caa58b3a66d77aec0325faf
Reviewed-on: https://go-review.googlesource.com/8764Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>

Change-Id: Ieadbd2b1ad442ba3eb2ad5f552d96c93ba3e5a2e
Reviewed-on: https://go-review.googlesource.com/8790Reviewed-by: Rob Pike <r@golang.org>

Issue 9483 suggests several approaches to correlating logs from
machines in different time zones. This approach is the simplest and
really should be sufficient: provide a way to clamp the time stamps
to UTC.

Fixes #9483.

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

Jumping to an offset past a symbol isn't something that is really
supported by dynamic linkers, so do it by hand.

Change-Id: Ifff8834c6cdfa3d521ebd8479d2e93906df9b258
Reviewed-on: https://go-review.googlesource.com/8238Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

Skip the test when there is no .gosymtab section in the executable
rather than crashing.

Change-Id: Ieb3df07e307f50c33cdafab38f9b5d1ac0e55c04
Reviewed-on: https://go-review.googlesource.com/5110Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>

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

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

A similar fix was applied in 54568685
but another instance of 'pc' was missed.

Also adds a test for the goroutine gdb command.

It currently uses goroutine 2 for the test, since goroutine 1 has
its stack pointer set to 0 for some reason.

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

Change-Id: I9e8a0dc152ef9403ff5ece0c161bda3a2f4448a8
Reviewed-on: https://go-review.googlesource.com/8760Reviewed-by: Rob Pike <r@golang.org>

This is a version of Time.Format that doesn't require allocation.

This is an updated version of 0af302f5
submitted by @bradfitz which was later rolled back.

Fixes #5192
Updates #5195

Change-Id: I4e6255bee1cf3914a6cc8d9d2a881cfeb273c08e
Reviewed-on: https://go-review.googlesource.com/1760Reviewed-by: Rob Pike <r@golang.org>

Now that getg is an intrinsic, more runtime functions
gets inlined (in particular, LockOSThread).
Runtime code gets race instrumented after inlining into
other packages. This can lead to false positives,
as race detector ignores all internal synchronization in runtime.
Inling of LockOSThread lead to false race reports on m contents.
See the issue for an example.

Fixes #10380

Change-Id: Ic9b760b53c28c2350bc54a5d4677fcd1c1f86e5f
Reviewed-on: https://go-review.googlesource.com/8690Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, when allocation reaches the concurrent GC trigger size, we
start the concurrent collector by ready'ing its G. This simply puts it
on the end of the P's run queue, which means we may not actually start
GC for some time as the current G continues to run and then the P
drains other Gs already on its run queue. Since the mutator can
continue to allocate, the heap can potentially be much larger than we
intended by the time GC actually starts. Furthermore, how much larger
is difficult to predict since it depends on the scheduler.

Fix this by preempting the current G and switching directly to the
concurrent GC G as soon as we reach the trigger heap size.

On the garbage benchmark from the benchmarks subrepo with
GOMAXPROCS=4, this reduces the time from triggering the GC to the
beginning of sweep termination by 10 to 30 milliseconds, which reduces
allocation after the trigger by up to 10MB (a large fraction of the
64MB live heap the benchmark tries to maintain).

One other known source of delay before we "really" start GC is the
sweep finalization performed before sweep termination. This has
similar negative effects on heap size and predictability, but is an
orthogonal problem. This change adds a TODO for this.

Change-Id: I8bae98cb43685c1bf353ff55868e4647e3743c47
Reviewed-on: https://go-review.googlesource.com/8513Reviewed-by: Rick Hudson <rlh@golang.org>

These were appropriate for STW GC, since it interrupted the allocating
Goroutine, but don't apply to concurrent GC, which runs on its own
Goroutine. Forced GC is still STW, but it makes sense to attribute the
GC to the goroutine that called runtime.GC().

Change-Id: If12418ca66dc7e53b8b16025af4e03adb5d9577e
Reviewed-on: https://go-review.googlesource.com/8715Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently, GC disables preemption between the traceGCStart and
traceGCDone, so it never moves Ps. Consequently, the trace verifier
attaches information about GC to its per-P state and will fail if GC
starts on one P and ends on another.

GC will soon be preemptible and may end on a different P than it
began. Hence, this change lifts this per-P verifier state to global
state.

Change-Id: I82256e2baab1ff3c4453fec312079018423b4b51
Reviewed-on: https://go-review.googlesource.com/8714Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

exitsyscallfast checks for freezetheworld, but does so only by
checking if stopwait is positive. This can also happen during
stoptheworld, which is harmless, but confusing. Shortly, it will be
important that we get to the p.status cas even if stopwait is set.

Hence, make this test more specific so it only triggers with
freezetheworld and not other uses of stopwait.

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

Currently, the only way to know the Go type of an attribute of some
DWARF attribute class was to read the dwarf package code (or
experiment).  This makes it hard to go from the DWARF specification to
writing code that uses the dwarf package.

Fix this by adding a table to the documentation comment of the Field
type that gives the correspondence between DWARF attribute classes and
Go types.

Change-Id: I57c678a551fa1eb46f8207085d5a53d44985e3e7
Reviewed-on: https://go-review.googlesource.com/7280Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>

The existing code used ints for the (slow) decimal conversion and
assumed that they were 32bit wide.

This change uses uints and the appropriate width (32 or 64bit)
depending on platform.

The performance difference is in the noise for the usual (optimized)
case which does not use the slow path conversion:

benchmark                               old ns/op     new ns/op     delta
BenchmarkFormatFloatDecimal             298           299           +0.34%
BenchmarkFormatFloat                    388           392           +1.03%
BenchmarkFormatFloatExp                 365           364           -0.27%
BenchmarkFormatFloatNegExp              364           362           -0.55%
BenchmarkFormatFloatBig                 482           476           -1.24%
BenchmarkAppendFloatDecimal             100           102           +2.00%
BenchmarkAppendFloat                    199           201           +1.01%
BenchmarkAppendFloatExp                 174           175           +0.57%
BenchmarkAppendFloatNegExp              169           174           +2.96%
BenchmarkAppendFloatBig                 286           286           +0.00%
BenchmarkAppendFloat32Integer           99.9          102           +2.10%
BenchmarkAppendFloat32ExactFraction     161           164           +1.86%
BenchmarkAppendFloat32Point             199           201           +1.01%
BenchmarkAppendFloat32Exp               167           168           +0.60%
BenchmarkAppendFloat32NegExp            163           169           +3.68%
BenchmarkAppendFloat64Fixed1            137           134           -2.19%
BenchmarkAppendFloat64Fixed2            144           146           +1.39%
BenchmarkAppendFloat64Fixed3            138           140           +1.45%
BenchmarkAppendFloat64Fixed4            144           145           +0.69%

The performance difference is significant if the fast path conversion is
explicitly turned off (ftoa.go:101):

benchmark                               old ns/op     new ns/op     delta
BenchmarkFormatFloatDecimal             459           427           -6.97%
BenchmarkFormatFloat                    1560          1180          -24.36%
BenchmarkFormatFloatExp                 5501          3128          -43.14%
BenchmarkFormatFloatNegExp              24085         14360         -40.38%
BenchmarkFormatFloatBig                 1409          1081          -23.28%
BenchmarkAppendFloatDecimal             248           226           -8.87%
BenchmarkAppendFloat                    1315          982           -25.32%
BenchmarkAppendFloatExp                 5274          2869          -45.60%
BenchmarkAppendFloatNegExp              23905         14054         -41.21%
BenchmarkAppendFloatBig                 1194          860           -27.97%
BenchmarkAppendFloat32Integer           167           175           +4.79%
BenchmarkAppendFloat32ExactFraction     182           184           +1.10%
BenchmarkAppendFloat32Point             556           564           +1.44%
BenchmarkAppendFloat32Exp               1134          918           -19.05%
BenchmarkAppendFloat32NegExp            2679          1801          -32.77%
BenchmarkAppendFloat64Fixed1            274           238           -13.14%
BenchmarkAppendFloat64Fixed2            494           368           -25.51%
BenchmarkAppendFloat64Fixed3            1833          1008          -45.01%
BenchmarkAppendFloat64Fixed4            6133          3596          -41.37%

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

Fix tracing of syscall exit after:
https://go-review.googlesource.com/#/c/7504/

Change-Id: Idcde2aa826d2b9a05d0a90a80242b6bfa78846ab
Reviewed-on: https://go-review.googlesource.com/8728Reviewed-by: Rick Hudson <rlh@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>