Russ Cox [Mon, 31 Oct 2016 16:09:03 +0000 (12:09 -0400)]
cmd/pprof: move cmd/internal/pprof back to cmd/pprof/internal
CL 21870 moved the entire cmd/pprof/internal directory to cmd/internal/pprof
for use by cmd/trace, but really cmd/trace only needed cmd/pprof/internal/profile,
which became cmd/internal/pprof/profile, and then internal/pprof/profile.
Move the rest back under cmd/pprof so that it is clear that no other code
is reaching into the guts of cmd/pprof. Just like functions should not be
exported unless necessary, internals should not be made visible to more
code than necessary.
Raúl Silvera noted after the commit of CL 21870 that only the profile package
should have moved, but there was no followup fix (until now).
Change-Id: I603f4dcb0616df1e5d5eb7372e6fccda57e05079
Reviewed-on: https://go-review.googlesource.com/32453
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Munday [Wed, 2 Nov 2016 15:41:40 +0000 (11:41 -0400)]
bytes, strings: update s390x code to match amd64 changes
Updates the s390x-specific files in these packages with the changes
to the amd64-specific files made during the review of CL 31690. I'd
like to keep these files in sync unless there is a reason to
diverge.
Ian Lance Taylor [Tue, 1 Nov 2016 19:06:22 +0000 (12:06 -0700)]
cmd/go: use cgo -srcdir when using SWIG
SWIG generates cgo input files in the work directory. When those files
are passed directly to cgo, cgo generates long file names that include
the object directory (with slashes replaced by underscores). Instead,
use cgo's new -srcdir option to give it short file names.
When using both SWIG and cgo, copy the cgo files into the object
directory first.
Use a shorter object file name when compiling the C file generated by
SWIG.
Fixes #17070.
Change-Id: Ic558603f1731636d9999f3130ad0224b24bd7dcb
Reviewed-on: https://go-review.googlesource.com/32485
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
Ian Lance Taylor [Tue, 1 Nov 2016 21:13:34 +0000 (14:13 -0700)]
cmd/cgo: only record typedef name for pointer to struct
In a function argument, we handle a typedef for a pointer specially,
using the pointer type rather than the typedef, to permit the Go calls
to match the laxer type conversions permitted in C. We record the
typedef so that we use that type in the C code, in case it has a special
attribute. However, using the typedef is wrong when using a pointer to a
basic type, because the C code may sometimes use the typedef and
sometimes not, and using the typedef in all cases will cause incorrect
type errors on the Go side. Fortunately we only really need to use the
typedef when pointing to a struct/union/class, and in such a case
confusion is unlikely.
Fixes #17723.
Change-Id: Id2eaeb156faeaf2e8eb9cf0b8f95b44caf8cfbd2
Reviewed-on: https://go-review.googlesource.com/32536
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
Robert Griesemer [Tue, 1 Nov 2016 21:46:59 +0000 (14:46 -0700)]
go/importer: handle multiple imports of the same object
Before aliases, and because we chose a simple export format for them,
a package may now export the same object more than once if there are
multiple exported aliases referring to that object. The go/importer
made the assumption this couldn't happen. Adjust it.
Fixes #17726.
Change-Id: Ibb9fc669a8748200b45ad78934d7453e5a5aad82
Reviewed-on: https://go-review.googlesource.com/32538 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Ian Lance Taylor [Tue, 1 Nov 2016 20:04:56 +0000 (13:04 -0700)]
cmd/go: remove _cgo_flags from gccgo archive built using SWIG
Since SWIG uses cgo, when using SWIG with gccgo, the go tool will add a
_cgo_flags file to the package archive, just as it does with cgo. We
need to remove that file from the archive passed to the linker, just as
we do with cgo.
Change-Id: I5ef4fea92eec419f870fbf6f678691d15901ee6c
Reviewed-on: https://go-review.googlesource.com/32535
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
David Crawshaw [Mon, 31 Oct 2016 03:53:09 +0000 (23:53 -0400)]
cmd/link: support plugins with no exported symbols
A plugin with no exported symbols is still potentially very useful.
Its init functions are called on load, and it so it can have visible
side effects.
Fixes #17681
Change-Id: Icdca31f48e5ab13c99020a2ef724f3de47dcd74b
Reviewed-on: https://go-review.googlesource.com/32437
Run-TryBot: David Crawshaw <crawshaw@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Crawshaw [Tue, 1 Nov 2016 19:28:55 +0000 (15:28 -0400)]
runtime: resolve type offsets using source module
The runtime.typeEquals function is used during typelinksinit to
determine the canonical set of *_type values to use throughout the
runtime. As such, it is run against non-canonical *_type values, that
is, types from modules that are duplicates of a type from another
module that was loaded earlier in the program life.
These non-canonical *_type values sometimes contain pointers. These
pointers are pointing to position-independent data, and so they are set
by ld.so using dynamic relocations when the module is loaded. As such,
the pointer can point to the equivalent memory from a previous module.
This means if typesEqual follows a pointer inside a *_type, it can end
up at a piece of memory from another module. If it reads a typeOff or
nameOff from that memory and attempts to resolve it against the
non-canonical *_type from the later module, it will end up with a
reference to junk memory.
Instead, resolve against the pointer the offset was read from, so the
data is valid.
Fixes #17709.
Should no longer matter after #17724 is resolved in a later Go.
Change-Id: Ie88b151a3407d82ac030a97b5b6a19fc781901cb
Reviewed-on: https://go-review.googlesource.com/32513
Run-TryBot: David Crawshaw <crawshaw@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
When the err from ReadFile is non-nil, we call t.Fatal(err).
Switch t.Fatal to t.Error + return.
ensure that close(results) happens on that code path as well.
Ilya Tocar [Fri, 21 Oct 2016 20:23:48 +0000 (23:23 +0300)]
bytes,strings: use IndexByte more often in Index on AMD64
IndexByte+compare is faster than indexShortStr in good case, when
first byte is rare, but is more costly in bad cases.
Start with IndexByte and switch to indexShortStr if we encounter
false positives more often than once per 8 bytes.
Brad Fitzpatrick [Tue, 1 Nov 2016 17:12:48 +0000 (17:12 +0000)]
net/http: add Transport.ProxyConnectHeader to control headers to proxies
Fixes #13290
Change-Id: I0f7e7683d86db501cbedb6a0b7349ceb0769701c
Reviewed-on: https://go-review.googlesource.com/32481 Reviewed-by: Martin Möhrmann <martisch@uos.de> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Thu, 27 Oct 2016 21:36:39 +0000 (17:36 -0400)]
runtime: align stack pointer in sigfwd
sigfwd calls an arbitrary C signal handler function. The System V ABI
for x86_64 (and the most recent revision of the ABI for i386) requires
the stack to be 16-byte aligned.
Fixes: #17641
Change-Id: I77f53d4a8c29c1b0fe8cfbcc8d5381c4e6f75a6b
Reviewed-on: https://go-review.googlesource.com/32107
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brad Fitzpatrick [Tue, 1 Nov 2016 15:24:11 +0000 (15:24 +0000)]
net/http, net/http/httptest: make http2's TrailerPrefix work for http1
Go's http1 implementation originally had a mechanism to send HTTP
trailers based on pre-declaring the trailer keys whose values you'd
later let after the header was written.
http2 copied the same mechanism, but it was found to be unsufficient
for gRPC's wire protocol. A second trailer mechanism was added later
(but only to http2) for handlers that want to send a trailer without
knowing in advance they'd need to.
Copy the same mechanism back to http1 and document it.
Fixes #15754
Change-Id: I8c40d55e28b0e5b7087d3d1a904a392c56ee1f9b
Reviewed-on: https://go-review.googlesource.com/32479 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Lynn Boger [Tue, 1 Nov 2016 15:43:34 +0000 (10:43 -0500)]
cmd/vendor/golang.org/x/arch/ppc64/ppc64asm: skip TestObjdumpPowerManual if not ppc64x
Skip TestObjdumpPowerManual if the host system is not ppc64 or ppc64le.
This test depends on using the host objdump and comparing output, which
does not work as expected if the test is run on another host.
Orignates from golang.org/x/arch/ppc64/ppc64asm commit 8e2d4898.
David Crawshaw [Mon, 31 Oct 2016 12:59:05 +0000 (08:59 -0400)]
plugin: do not leak cRelName on error path
Fixes #17683
Change-Id: I46f45c63796b58e8a8f14e37592231cbe7cd6934
Reviewed-on: https://go-review.googlesource.com/32438 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
David Crawshaw [Mon, 31 Oct 2016 00:30:38 +0000 (20:30 -0400)]
runtime: access modules via a slice
The introduction of -buildmode=plugin means modules can be added to a
Go program while it is running. This means there exists some time
while the program is running with the module is on the moduledata
linked list, but it has not been initialized to the satisfaction of
other parts of the runtime. Notably, the GC.
This CL adds a new way of access modules, an activeModules function.
It returns a slice of modules that is built in the background and
atomically swapped in. The parts of the runtime that need to wait on
module initialization can use this slice instead of the linked list.
Fixes #17455
Change-Id: I04790fd07e40c7295beb47cea202eb439206d33d
Reviewed-on: https://go-review.googlesource.com/32357 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Munday [Fri, 7 Oct 2016 16:16:26 +0000 (12:16 -0400)]
cmd/compile: improve s390x rules for folding ADDconst into loads/stores
There is no benefit to folding ADDconsts unless the resultant immediate
will fit into a 20-bit signed integer, so limit these rules accordingly.
Also the signed load operations were missing, so I've added them, and
I've also removed some MOVDaddr rules that were dead code (MOVDaddrs
are rematerializable on s390x which means they can't take inputs other
than SP or SB).
Change-Id: Iebeba78da37d3d71d32d4b7f49fe4ea9095d40ec
Reviewed-on: https://go-review.googlesource.com/30616
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
Martin Möhrmann [Sat, 29 Oct 2016 23:54:19 +0000 (01:54 +0200)]
runtime: improve atoi implementation
- Adds overflow checks
- Adds parsing of negative integers
- Adds boolean return value to signal parsing errors
- Adds atoi32 for parsing of integers that fit in an int32
- Adds tests
Handling of errors to provide error messages
at the call sites is left to future CLs.
Updates #17718
Change-Id: I3cacd0ab1230b9efc5404c68edae7304d39bcbc0
Reviewed-on: https://go-review.googlesource.com/32390 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Daniel Martí [Thu, 27 Oct 2016 18:47:47 +0000 (19:47 +0100)]
testing: don't warn if -bench was passed
In a previous change, cmd/go was taught to show a "no tests ran" warning
if test did nothing. But it missed a case - if no tests nor examples ran
but any benchmarks were meant to be run, it would still produce the
warning. This meant that running only benchmarks, which is common, would
be confusing:
$ go test -run='^$' -bench=.
testing: warning: no tests to run
BenchmarkFoo-4 300000 5056 ns/op
[...]
I believe this was because of a copy-paste error in the tests. This was
being tested, but on the wrong file which does contain a test that was
being run. Fix the path and fix the now failing test by never showing
the warning if -bench was given a non-empty string.
The rationale is that if -bench was given but there was no output, it's
obvious that nothing happened as benchmarks always produce output even
without -v. So showing a warning in those cases is redundant.
To make future typos less likely, make sure that no tests are being run
in the cases where we only want to run benchmarks.
Fixes #17603.
Change-Id: I4c626caf39f72260c6a9761c06446663f465f947
Reviewed-on: https://go-review.googlesource.com/32157 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Emmanuel Odeke [Fri, 28 Oct 2016 15:11:39 +0000 (08:11 -0700)]
net/http/httputil: add ModifyResponse to reverseProxy
Adds ModifyResponse, an optional func to ReverseProxy
that modifies a response in the backend, right before
the headers of the response are written to the internal
response writer.
If ModifyResponse returns an error, the proxy returns
a StatusBadGateway error.
Joe Tsai [Tue, 1 Nov 2016 00:34:42 +0000 (17:34 -0700)]
encoding/json: marshal with null when RawMessage is nil
This CL expands upon a change made in (http://golang.org/cl/21811)
to ensure that a nil RawMessage gets serialized as "null" instead of
being a nil slice.
The added check only triggers when the RawMessage is nil. We do not
handle the case when the RawMessage is non-nil, but empty.
Austin Clements [Mon, 31 Oct 2016 21:37:05 +0000 (17:37 -0400)]
runtime: perform write barriers on direct channel receive
Currently we have write barriers for direct channel sends, where the
receiver is blocked and the sender is writing directly to the
receiver's stack; but not for direct channel receives, where the
sender is blocked and the receiver is reading directly from the
sender's stack.
This was okay with the old write barrier because either 1) the
receiver would write the received pointer into the heap (causing it to
be shaded), 2) the pointer would still be on the receiver's stack at
mark termination and we would rescan it, or 3) the receiver dropped
the pointer so it wasn't necessarily reachable anyway.
This is not okay with the write barrier because it lets a grey stack
send a white pointer to a black stack and then remove it from its own
stack. If the grey stack was the sole grey-protector of this pointer,
this hides the object from the garbage collector.
Fix this by making direct receives perform a stack-to-stack write
barrier just like direct sends do.
Fixes #17694.
Change-Id: I1a4cb904e4138d2ac22f96a3e986635534a5ae41
Reviewed-on: https://go-review.googlesource.com/32450 Reviewed-by: Rick Hudson <rlh@golang.org>
Dhananjay Nakrani [Sat, 29 Oct 2016 19:10:21 +0000 (12:10 -0700)]
cmd/compile: avoid nil-ing out a node's Type in typecheckcomplit() on error
typecheckcomplit nils out node's type, upon finding new errors.
This hides new errors in children's node as well as the type info
of current node. This change fixes that.
Fixes #17645.
Change-Id: Ib473291f31c7e8fa0307cb1d494e0c112ddd3583
Reviewed-on: https://go-review.googlesource.com/32324 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Austin Clements [Sun, 30 Oct 2016 21:59:06 +0000 (17:59 -0400)]
runtime: make assists perform root jobs
Currently, assists can only perform heap marking jobs. However, at the
beginning of GC, there are only root jobs and no heap marking jobs. As
a result, there's often a period at the beginning of a GC cycle where
no goroutine has accumulated assist credit, but at the same time it
can't get any credit because there are no heap marking jobs for it to
do yet. As a result, many goroutines often block on the assist queue
at the very beginning of the GC cycle.
This commit fixes this by allowing assists to perform root marking
jobs. The tricky part of this (and the reason we haven't done this
before) is that stack scanning jobs can lead to deadlocks if the
goroutines performing the stack scanning are themselves
non-preemptible, since two non-preemptible goroutines may try to scan
each other. To address this, we use the same insight d6625ca used to
simplify the mark worker stack scanning: as long as we're careful with
the stacks and only drain jobs while on the system stack, we can put
the goroutine into a preemptible state while we drain jobs. This means
an assist's user stack can be scanned while it continues to do work.
This reduces the rate of assist blocking in the x/benchmarks HTTP
benchmark by a factor of 3 and all remaining blocking happens towards
the *end* of the GC cycle, when there may genuinely not be enough work
to go around.
Ideally, assists would get credit for working on root jobs. Currently
they do not; however, this change prioritizes heap work over root jobs
in assists, so they're likely to mostly perform heap work. In contrast
with mark workers, for assists, the root jobs act only as a backstop
to create heap work when there isn't enough heap work.
Fixes #15361.
Change-Id: If6e169863e4ad75710b0c8dc00f6125b41e9a595
Reviewed-on: https://go-review.googlesource.com/32432 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Sun, 30 Oct 2016 21:46:49 +0000 (17:46 -0400)]
runtime: lift systemstack part of gcAssistAlloc
This lifts the part of gcAssistAlloc that runs on the system stack to
its own function in preparation for letting assists perform root jobs
(notably stack scanning). This makes it easy to see that there are no
references to the user stack once we've entered gcAssistAlloc1, which
means it's safe to shrink the stack while in gcAssistAlloc1.
This does not yet make assists perform root jobs, so it's not actually
possible for the stack to shrink yet. That will happen in the next
commit.
The code in gcAssistAlloc1 is identical to the code that's currently
passed in a closure to systemstack with one exception. Currently, we
set the "completed" variable in the enclosing scope to indicate that
the assist completed the mark phase. This is exactly the sort of
cross-stack reference lifting this function is meant to prevent. We
replace this variable with setting gp.param to nil or non-nil to
indicate the completion status.
Dhananjay Nakrani [Sun, 30 Oct 2016 19:47:53 +0000 (12:47 -0700)]
cmd/compile: initialize Decldepth in all cases
Previously, on encountering Func.Nname.Type == nil, typecheckfunc()
returned without initializing Decldepth for that func. This causes
typecheckclosure() to fatal. This change ensures that we initialize
Decldepth in all cases.
Keith Randall [Mon, 31 Oct 2016 04:10:03 +0000 (21:10 -0700)]
cmd/compile: make [0]T and [1]T SSAable types
We used to have to keep on-stack copies of these types.
Now they can be registerized.
[0]T is kind of trivial but might as well handle it.
This change enables another change I'm working on to improve how x.(T)
expressions are handled (#17405). This CL helps because now all
types that are direct interface types are registerizeable (e.g. [1]*byte).
No higher-degree arrays for now because non-constant indexes are hard.
Update #17405
Change-Id: I2399940965d17b3969ae66f6fe447a8cefdd6edd
Reviewed-on: https://go-review.googlesource.com/32416
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
David Chase [Fri, 28 Oct 2016 17:33:57 +0000 (13:33 -0400)]
cmd/compile: mark temps with new AutoTemp flag, and use it.
This is an extension of
https://go-review.googlesource.com/c/31662/
to mark all the temporaries, not just the ssa-generated ones.
Before-and-after ls -l `go tool -n compile` shows a 3%
reduction in size (or rather, a prior 3% inflation for
failing to filter temps out properly.)
Replaced name-dependent "is it a temp?" tests with calls to
*Node.IsAutoTmp(), which depends on AutoTemp. Also replace
calls to istemp(n) with n.IsAutoTmp(), to reduce duplication
and clean up function name space. Generated temporaries
now come with a "." prefix to avoid (apparently harmless)
clashes with legal Go variable names.
Fixes #17644.
Fixes #17240.
Change-Id: If1417f29c79a7275d7303ddf859b51472890fd43
Reviewed-on: https://go-review.googlesource.com/32255
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Matthew Dempsky [Mon, 31 Oct 2016 19:01:32 +0000 (12:01 -0700)]
cmd/compile: remove legacy debug flags
-M, -P, and -R were for debugging backend passes that no longer
exists.
-g is used for debugging instructions generated with Gins, but the SSA
backend mostly generates instructions directly. The handful of
instructions still generated with Gins are pretty useless for
debugging.
-x was used to debug the old lexer, but now it only causes us to print
file names as they're parsed, and only if we manually hack the
compiler to enable tracing.
Mike Strosaker [Fri, 28 Oct 2016 23:50:16 +0000 (19:50 -0400)]
crypto/sha256: improve performance for sha256.block on ppc64le
Adds an assembly implementation of sha256.block for ppc64le to improve its
performance. This implementation is largely based on the original amd64
implementation, which unrolls the 64 iterations of the inner loop.
Fixes #17652
benchmark old ns/op new ns/op delta
BenchmarkHash8Bytes 1263 767 -39.27%
BenchmarkHash1K 14048 7766 -44.72%
BenchmarkHash8K 102245 55626 -45.60%
benchmark old MB/s new MB/s speedup
BenchmarkHash8Bytes 6.33 10.43 1.65x
BenchmarkHash1K 72.89 131.85 1.81x
BenchmarkHash8K 80.12 147.27 1.84x
Change-Id: Ib4adf429423b20495580400be10bd7e171bcc70b
Reviewed-on: https://go-review.googlesource.com/32318 Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Mike Strosaker [Sat, 29 Oct 2016 06:36:41 +0000 (02:36 -0400)]
crypto/sha512: improve performance for sha512.block on ppc64le
Adds an assembly implementation of sha512.block for ppc64le to improve its
performance. This implementation is largely based on the original amd64
implementation, unrolling the 80 iterations of the inner loop.
Fixes #17660
benchmark old ns/op new ns/op delta
BenchmarkHash8Bytes 1715 1133 -33.94%
BenchmarkHash1K 10098 5513 -45.41%
BenchmarkHash8K 68004 35278 -48.12%
benchmark old MB/s new MB/s speedup
BenchmarkHash8Bytes 4.66 7.06 1.52x
BenchmarkHash1K 101.40 185.72 1.83x
BenchmarkHash8K 120.46 232.21 1.93x
Change-Id: Ifd55a49a24cb159b3a09a8e928c3f37727aca103
Reviewed-on: https://go-review.googlesource.com/32320 Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
David Crawshaw [Mon, 31 Oct 2016 01:19:59 +0000 (21:19 -0400)]
runtime: make module typemaps visible to the GC
The map[typeOff]*_type object is created at run time and stored in
the moduledata. The moduledata object is marked by the linker as
SNOPTRDATA, so the reference is ignored by the GC. Running
misc/cgo/testplugin/test.bash with GOGC=1 will eventually collect
the typemap and crash.
This bug probably comes up in -linkshared binaries in Go 1.7.
I don't know why we haven't seen a report about this yet.
Fixes #17680
Change-Id: I0e9b5c006010e8edd51d9471651620ba665248d3
Reviewed-on: https://go-review.googlesource.com/32430
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Crawshaw [Sun, 30 Oct 2016 19:31:21 +0000 (15:31 -0400)]
cmd/link, plugin: use full plugin path for symbols
Plumb the import path of a plugin package through to the linker, and
use it as the prefix on the exported symbol names.
Before this we used the basename of the plugin file as the prefix,
which could conflict and result in multiple loaded plugins sharing
symbols that are distinct.
Fixes #17155
Fixes #17579
Change-Id: I7ce966ca82d04e8507c0bcb8ea4ad946809b1ef5
Reviewed-on: https://go-review.googlesource.com/32355 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Gudger [Sat, 29 Oct 2016 03:09:02 +0000 (20:09 -0700)]
syscall: remove X__cmsg_data from Cmsghdr
This field is a zero length array and has little use. Since Go 1.5, trailing
zero-length arrays take up space. Both syscall.UnixRights() and
syscall.ParseSocketControlMessage() depend on being able to do an unsafe cast
of socket control message data to Cmsghdr this is only safe if the socket
control message data is greater than or equal to the size of Cmsghdr. Since
control message data that is equal in size to Cmsghdr without X__cmsg_data is
a valid socket control message, we must remove X__cmsg_data or not perform the
unsafe cast.
Removing X__cmsg_data will prevent Go code that uses X__cmsg_data from
compiling, but removing the unsafe cast will cause Go code that uses
X__cmsg_data to fail or exhibit undefined behavior at runtime. It was
therefore decided that removing X__cmsg_data was the better option.
Daniel Theophanes [Mon, 17 Oct 2016 06:11:55 +0000 (23:11 -0700)]
database/sql: add context helper methods and transaction types
Prior to this change, it was implied that transaction properties
would be carried in the context value. However, no such properties
were defined, not even common ones. Define two common properties:
isolation level and read-only. Drivers may choose to support
additional transaction properties. It is not expected any
further transaction properties will be added in the future.
Dmitry Vyukov [Fri, 28 Oct 2016 15:12:39 +0000 (17:12 +0200)]
runtime/race: update race runtime
This updates the runtime to HEAD to keep it aligned and fixes some bugs.
http://llvm.org/viewvc/llvm-project?view=revision&revision=285454
fixes the crash on darwin related to unaligned data section (#17065).
http://llvm.org/viewvc/llvm-project?view=revision&revision=285451
enables core dumps by default (#16527).
http://llvm.org/viewvc/llvm-project?view=revision&revision=285455
adds a hook to obtain number of races reported so far (#15972).
Can now be obtained with:
//go:nosplit
func RaceReportCount() int {
var n uint64
racecall(&__tsan_report_count, uintptr(unsafe.Pointer(&n)), 0, 0, 0)
return int(n)
}
Fixes #16527.
Fixes #17065.
Update #15972.
Change-Id: I8f869cb6275c9521a47303f3810a9965e9314357
Reviewed-on: https://go-review.googlesource.com/32160
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joe Tsai [Sat, 29 Oct 2016 19:25:20 +0000 (12:25 -0700)]
compress/gzip: only encode MTIME if it is valid
The GZIP format records the ModTime as an uint32 counting seconds since
the Unix epoch. The zero value is explicitly defined in section 2.3.1
as meaning no timestamp is available.
Currently, the Writer always encodes the ModTime even if it is the zero
time.Time value, which causes the Writer to try and encode the value
-62135596800 into the uint32 MTIME field. This causes an overflow and
results in our GZIP files having MTIME fields indicating a date in 2042-07-13.
We alter the Writer to only encode ModTime if the value does not underflow
the MTIME field (i.e., it is newer than the Unix epoch). We do not attempt
to fix what happens when the timestamp overflows in the year 2106.
We alter the Reader to only decode ModTime if the value is non-zero.
There is no risk of overflowing time.Time when decoding.
Russ Cox [Tue, 25 Oct 2016 12:59:35 +0000 (08:59 -0400)]
cmd/link: fix -X importpath.name=value when import path needs escaping
After the final slash, dots are %-escaped when constructing a symbol name,
so that in the actual symbol table, the import path githost.com/my.git
becomes githost.com/my%2egit. In this case, -X githost.com/my.git.Value=foo
needs to set githost.com/my%2egit.Value. This is a detail of the object format
and not something users should know or depend on, so apply the escaping
as needed.
People who have run across this already and figured out and started using
the escaped forms with -X will find those forms not working anymore.
That is, -X githost.com/my%2egit.Value=foo is the Go 1.7 workaround but
will stop working in Go 1.8 once this proper fix is in place.
People who need to keep scripts working with older and newer versions of Go
can safely pass both forms, and one will be ignored:
Zev Goldstein [Fri, 28 Oct 2016 15:42:27 +0000 (11:42 -0400)]
path/filepath: fix Abs on Windows
The filepath.Abs function in windows did not call Clean as the
documentation claimed. This change not only fixes that behavior but
also adjusts TestAbs to verify Abs calls Clean as documented.
Fixes #17210
Change-Id: I20c5f5026042fd7bd9d929ff5b17c8b2653f8afe
Reviewed-on: https://go-review.googlesource.com/32292 Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
* Before:
./issue17631.go:20: unknown struct { about string; before map[string]uint;
update map[string]int; updateTime time.Time; expect map[string]int } field
'updates' in struct literal
* After:
./issue17631.go:20: unknown field 'updates' in struct literal of type { about string;
before map[string]uint; update map[string]int; updateTime time.Time;
expect map[string]int }
Dmitry Vyukov [Fri, 28 Oct 2016 22:53:49 +0000 (00:53 +0200)]
runtime/race: ignore user GORACE env var in tests
I did 'export GORACE=atexit_sleep_ms=0' in a console
and then was puzzled as to why race tests fail.
Existing GORACE env var may (or may not) override
the one that we setup.
Filter out GORACE as we do for other important env vars.
Than McIntosh [Fri, 28 Oct 2016 17:28:56 +0000 (13:28 -0400)]
test: add test for gccgo issue #17640
Change-Id: Iec35f9b62982da40de400397bc456149216303dc
Reviewed-on: https://go-review.googlesource.com/32297 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Fri, 28 Oct 2016 22:25:31 +0000 (18:25 -0400)]
time: clarify Equal docs
The docs used to imply that using == would compare Locations, but of
course it just compares Location pointers, which will have unpredictable
results depending on how the pointers are loaded.
Peter Weinberger [Fri, 28 Oct 2016 19:12:18 +0000 (15:12 -0400)]
runtime: ensure elapsed cycles are not negative
On solaris/amd64 sometimes the reported cycle count is negative. Replace
with 0.
Change-Id: I364eea5ca072281245c7ab3afb0bf69adc3a8eae
Reviewed-on: https://go-review.googlesource.com/32258 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Fri, 28 Oct 2016 21:18:36 +0000 (17:18 -0400)]
runtime: fix SP adjustment on amd64p32
On amd64p32, rt0_go attempts to reserve 128 bytes of scratch space on
the stack, but due to a register mixup this ends up being a no-op. Fix
this so we actually reserve the stack space.
Change-Id: I04dbfbeb44f3109528c8ec74e1136bc00d7e1faa
Reviewed-on: https://go-review.googlesource.com/32331
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Sun, 23 Oct 2016 15:07:49 +0000 (11:07 -0400)]
runtime: disable stack rescanning by default
With the hybrid barrier in place, we can now disable stack rescanning
by default. This commit adds a "gcrescanstacks" GODEBUG variable that
is off by default but can be set to re-enable STW stack rescanning.
The plan is to leave this off but available in Go 1.8 for debugging
and as a fallback.
With this change, worst-case mark termination time at GOMAXPROCS=12
*not* including time spent stopping the world (which is still
unbounded) is reliably under 100 µs, with a 95%ile around 50 µs in
every benchmark I tried (the go1 benchmarks, the x/benchmarks garbage
benchmark, and the gcbench activegs and rpc benchmarks). Including
time spent stopping the world usually adds about 20 µs to total STW
time at GOMAXPROCS=12, but I've seen it add around 150 µs in these
benchmarks when a goroutine takes time to reach a safe point (see
issue #10958) or when stopping the world races with goroutine
switches. At GOMAXPROCS=1, where this isn't an issue, worst case STW
is typically 30 µs.
The go-gcbench activegs benchmark is designed to stress large numbers
of dirty stacks. This commit reduces 95%ile STW time for 500k dirty
stacks by nearly three orders of magnitude, from 150ms to 195µs.
This has little effect on the throughput of the go1 benchmarks or the
x/benchmarks benchmarks.
It reduces the tail latency of the x/benchmarks HTTP benchmark:
name old p50-time new p50-time delta
XHTTP-12 489µs ± 0% 491µs ± 1% +0.54% (p=0.000 n=20+18)
name old p95-time new p95-time delta
XHTTP-12 957µs ± 1% 960µs ± 1% +0.28% (p=0.002 n=20+17)
name old p99-time new p99-time delta
XHTTP-12 1.76ms ± 1% 1.64ms ± 1% -7.20% (p=0.000 n=20+18)
Comparing to the beginning of the hybrid barrier implementation
("runtime: parallelize STW mcache flushing") shows that the hybrid
barrier trades a small performance impact for much better STW latency,
as expected. The magnitude of the performance impact is generally
small:
Updates #17099, since you can't have a rescan list bug if there's no
rescan list. I'm not marking it as fixed, since gcrescanstacks can
still be set to re-enable the rescan lists.
Change-Id: I6e926b4c2dbd4cd56721869d4f817bdbb330b851
Reviewed-on: https://go-review.googlesource.com/31766 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Sun, 23 Oct 2016 15:03:56 +0000 (11:03 -0400)]
runtime: implement unconditional hybrid barrier
This implements the unconditional version of the hybrid deletion write
barrier, which always shades both the old and new pointer. It's
unconditional for now because barriers on channel operations require
checking both the source and destination stacks and we don't have a
way to funnel this information into the write barrier at the moment.
As part of this change, we modify the typed memclr operations
introduced earlier to invoke the write barrier.
This has basically no overall effect on benchmark performance. This is
good, since it indicates that neither the extra shade nor the new bulk
clear barriers have much effect. It also has little effect on latency.
This is expected, since we haven't yet modified mark termination to
take advantage of the hybrid barrier.
Updates #17503.
Change-Id: Iebedf84af2f0e857bd5d3a2d525f760b5cf7224b
Reviewed-on: https://go-review.googlesource.com/31765 Reviewed-by: Rick Hudson <rlh@golang.org>
Austin Clements [Wed, 26 Oct 2016 21:05:41 +0000 (17:05 -0400)]
runtime: avoid getfull() barrier most of the time
With the hybrid barrier, unless we're doing a STW GC or hit a very
rare race (~once per all.bash) that can start mark termination before
all of the work is drained, we don't need to drain the work queue at
all. Even draining an empty work queue is rather expensive since we
have to enter the getfull() barrier, so it's worth avoiding this.
Conveniently, it's quite easy to detect whether or not we actually
need the getufull() barrier: since the world is stopped when we enter
mark termination, everything must have flushed its work to the work
queue, so we can just check the queue. If the queue is empty and we
haven't queued up any jobs that may create more work (which should
always be the case with the hybrid barrier), we can simply have all GC
workers perform non-blocking drains.
Also conveniently, this solution is quite safe. If we do somehow screw
something up and there's work on the work queue, some worker will
still process it, it just may not happen in parallel.
This is not the "right" solution, but it's simple, expedient,
low-risk, and maintains compatibility with debug.gcrescanstacks. When
we remove the gcrescanstacks fallback in Go 1.9, we should also fix
the race that starts mark termination early, and then we can eliminate
work draining from mark termination.
Updates #17503.
Change-Id: I7b3cd5de6a248ab29d78c2b42aed8b7443641361
Reviewed-on: https://go-review.googlesource.com/32186 Reviewed-by: Rick Hudson <rlh@golang.org>