Rick Hudson [Thu, 12 Mar 2015 18:19:21 +0000 (14:19 -0400)]
runtime: Remove write barriers during STW.
The GC assumes that there will be no asynchronous write barriers when
the world is stopped. This keeps the synchronization between write
barriers and the GC simple. However, currently, there are a few places
in runtime code where this assumption does not hold.
The GC stops the world by collecting all Ps, which stops all user Go
code, but small parts of the runtime can run without a P. For example,
the code that releases a P must still deschedule its G onto a runnable
queue before stopping. Similarly, when a G returns from a long-running
syscall, it must run code to reacquire a P.
Currently, this code can contain write barriers. This can lead to the
GC collecting reachable objects if something like the following
sequence of events happens:
1. GC stops the world by collecting all Ps.
2. G #1 returns from a syscall (for example), tries to install a
pointer to object X, and calls greyobject on X.
3. greyobject on G #1 marks X, but does not yet add it to a write
buffer. At this point, X is effectively black, not grey, even though
it may point to white objects.
4. GC reaches X through some other path and calls greyobject on X, but
greyobject does nothing because X is already marked.
5. GC completes.
6. greyobject on G #1 adds X to a work buffer, but it's too late.
7. Objects that were reachable only through X are incorrectly collected.
To fix this, we check the invariant that no asynchronous write
barriers happen when the world is stopped by checking that write
barriers always have a P, and modify all currently known sources of
these writes to disable the write barrier. In all modified cases this
is safe because the object in question will always be reachable via
some other path.
Some of the trace code was turned off, in particular the
code that traces returning from a syscall. The GC assumes
that as far as the heap is concerned the thread is stopped
when it is in a syscall. Upon returning the trace code
must not do any heap writes for the same reasons discussed
above.
The Go runtime does something surprisingly similar, building the
runtime's envs []string using gostringnocopy. Both libc and the Go
runtime reusing memory interacts badly. When syscall.Setenv uses cgo
to call setenv(3), C modifies the underlying memory of a Go string.
This manifests on android/arm. With GOROOT=/data/local/tmp, a
runtime test calls syscall.Setenv("/os"), resulting in
runtime.GOROOT()=="/os\x00a/local/tmp/goroot".
Avoid this by copying environment string memory into Go.
Covered by runtime.TestFixedGOROOT on android/arm.
Change-Id: Id0cf9553969f587addd462f2239dafca1cf371fa
Reviewed-on: https://go-review.googlesource.com/7663 Reviewed-by: Keith Randall <khr@golang.org>
Dmitry Vyukov [Fri, 13 Mar 2015 13:02:47 +0000 (16:02 +0300)]
runtime: fix comment
IRIW requires 4 threads: first writes x, second writes y,
third reads x and y, fourth reads y and x.
This is Peterson/Dekker mutual exclusion algorithm based on
critical store-load sequences:
http://en.wikipedia.org/wiki/Dekker's_algorithm
http://en.wikipedia.org/wiki/Peterson%27s_algorithm
Dmitry Vyukov [Wed, 11 Mar 2015 15:29:12 +0000 (18:29 +0300)]
runtime: remove futile wakeups from trace
Channels and sync.Mutex'es allow another goroutine to acquire resource
ahead of an unblocked goroutine. This is good for performance, but
leads to futile wakeups (the unblocked goroutine needs to block again).
Futile wakeups caused user confusion during the very first evaluation
of tracing functionality on a real server (a goroutine as if acquires a mutex
in a loop, while there is no loop in user code).
This change detects futile wakeups on channels and emits a special event
to denote the fact. Later parser finds entire wakeup sequences
(unblock->start->block) and removes them.
sync.Mutex will be supported in a separate change.
Change-Id: Iaaaee9d5c0921afc62b449a97447445030ac19d3
Reviewed-on: https://go-review.googlesource.com/7380 Reviewed-by: Keith Randall <khr@golang.org>
David Crawshaw [Sun, 8 Mar 2015 15:37:02 +0000 (11:37 -0400)]
runtime/cgo: catch EXC_BAD_ACCESS on darwin/arm
The Go builders (and standard development cycle) for programs on iOS
require running the programs under lldb. Unfortunately lldb intercepts
SIGSEGV and will not give it back.
https://llvm.org/bugs/show_bug.cgi?id=22868
We get around this by never letting lldb see the SIGSEGV. On darwin,
Unix signals are emulated on top of mach exceptions. The debugger
registers a task-level mach exception handler. We register a
thread-level exception handler which acts as a faux signal handler.
The thread-level handler gets precedence over the task-level handler,
so we can turn the exception EXC_BAD_ACCESS into a panic before lldb
can see it.
Fixes #10043
Change-Id: I64d7c310dfa7ecf60eb1e59f094966520d473335
Reviewed-on: https://go-review.googlesource.com/7072 Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Austin Clements [Thu, 12 Mar 2015 18:26:04 +0000 (14:26 -0400)]
runtime: factor object dumping code out of greyobject
When checkmark fails, greyobject dumps both the object that pointed to
the unmarked object and the unmarked object. This code cluttered up
greyobject, was copy-pasted for the two objects, and the copy for
dumping the unmarked object was not entirely correct.
Extract object dumping out to a new function. This declutters
greyobject and fixes the bugs in dumping the unmarked object. The new
function is slightly cleaned up from the original code to have more
natural control flow and shows a marker on the field in the base
object that points to the unmarked object to make it easy to find.
Change-Id: Ib51318a943f50b0b99995f0941d03ee8876b9fcf
Reviewed-on: https://go-review.googlesource.com/7506 Reviewed-by: Rick Hudson <rlh@golang.org>
Russ Cox [Mon, 16 Mar 2015 23:03:09 +0000 (19:03 -0400)]
cmd/internal/gc: mv builtins builtin
This directory is processed by mkbuiltin.go and generates builtin.go.
It should be named builtin too, not builtins, both for consistency
and because file and directory names in general are singular unless
forced otherwise.
Commented on CL 6233 too.
Change-Id: Ic5d3671443ae9292b69fda118f61a11c88d823fa
Reviewed-on: https://go-review.googlesource.com/7660 Reviewed-by: Minux Ma <minux@golang.org>
Russ Cox [Sun, 8 Mar 2015 17:33:49 +0000 (13:33 -0400)]
cmd/gc: rewrite argtype to substitute in a single pass
Substituting in multiple passes meant walking the type
multiple times, and worse, if a complex type was substituted
in an early pass, later passes would follow it, possibly recursively,
until hitting the depth 10 limit.
Joël Stemmer [Fri, 6 Mar 2015 13:08:55 +0000 (14:08 +0100)]
crypto/tls: return correct hash function when using client certificates in handshake
Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for
AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it
did not take the arbitrary hash function into account in the TLS client
handshake when using client certificates.
The hashForClientCertificate method always returned SHA256 as its
hashing function, even if it actually used a different one to calculate
its digest. Setting up the connection would eventually fail with the
error "tls: failed to sign handshake with client certificate:
crypto/rsa: input must be hashed message".
Included is an additional test for this specific situation that uses the
SHA384 hash.
Fixes #9808
Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3
Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Nick Sullivan [Wed, 25 Feb 2015 01:55:25 +0000 (17:55 -0800)]
crypto/rsa: implement crypto.Decrypter
Decrypter is an interface to support opaque private keys that perform
decryption operations. This interface is analogous to the crypto.Signer
interface.
This change introduces the crypto.Decrypter interface and implements
the crypto.Decrypter interface for rsa.PrivateKey with both OAEP and
PKCS#1 v1.5 padding modes.
Change-Id: I433f649f84ed3c2148337d735cafd75f1d94a904
Reviewed-on: https://go-review.googlesource.com/3900 Reviewed-by: Adam Langley <agl@golang.org>
Rob Pike [Tue, 13 Jan 2015 22:13:42 +0000 (09:13 +1100)]
text/template: protect against explicit nil in field chains
An explicit nil in an expression like nil.Foo caused a panic
because the evaluator attempted to reflect on the nil.
A typeless nil like this cannot be used to do anything, so
just error out.
Fixes #9426
Change-Id: Icd2c9c7533dda742748bf161eced163991a12f54
Reviewed-on: https://go-review.googlesource.com/7643 Reviewed-by: David Symonds <dsymonds@golang.org>
Aram Hăvărneanu [Sun, 8 Mar 2015 12:58:16 +0000 (13:58 +0100)]
cmd/internal/obj, cmd/internal/obj/arm64: add support for GOARCH=arm64
ARM64 (ARMv8) has 32 general purpose, 64-bit integer registers
(R0-R31), 32 64-bit scalar floating point registers (F0-F31), and
32 128-bit vector registers (unused, V0-V31).
R31 is either the stack pointer (RSP), or the zero register (ZR),
depending on the instruction. Note the distinction between the
hardware stack pointer, RSP, and the virtual stack pointer SP.
The (hardware) stack pointer must be 16-byte aligned at all times;
the RSP register itself must be aligned, offset(RSP) only has to
have natural alignment.
Instructions are fixed-width, and are 32-bit wide. ARM64 supports
ARMv7 too (32-bit ARM), but not in the same process. In general,
there is not much in common between 32-bit ARM and ARM64, it's a
new architecture.
All implementations have floating point instructions.
This change adds a Prog.To3 field analogous to Prog.To. It is used
by exclusive load/store instructions such as STLXR which read from
one register, and write to both a register and a memory address.
STLXRW R1, (R0), R3
This will store the word contained in R1 to the memory address
pointed by R0. R3 will be updated with the status result of the
store. It is used to implement atomic operations.
No other changes are made to the portable Prog and Addr structures.
Joel Sing [Sun, 18 Jan 2015 10:02:58 +0000 (21:02 +1100)]
all: remove dragonfly/386 port
DragonFlyBSD dropped support for i386 in 4.0 and there is no longer a
dragonfly/386 - as such, remove the Go port.
Fixes #8951
Fixes #7580
Fixes #7421
Change-Id: I69022ab2262132e8f97153f14dc8c37c98527008
Reviewed-on: https://go-review.googlesource.com/7543 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net> Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Joel Sing <jsing@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Michael Hudson-Doyle [Sat, 7 Mar 2015 03:28:07 +0000 (16:28 +1300)]
cmd/internal/ld: remove some dead code
Just little bits and pieces I noticed were unused in passing, and
some more found with https://github.com/opennota/check.
Change-Id: I199fecdbf8dc2ff9076cf4ea81395275c7f171c3
Reviewed-on: https://go-review.googlesource.com/7033 Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Matthew Dempsky [Mon, 9 Mar 2015 18:14:35 +0000 (11:14 -0700)]
cmd/internal/gc: remove unused fields
Change-Id: I3096a7497955bc475739739ee23be387e9162867
Reviewed-on: https://go-review.googlesource.com/7210
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Sat, 14 Mar 2015 00:24:30 +0000 (17:24 -0700)]
math/big: wrap Float.Cmp result in struct to prevent wrong use
Float.Cmp used to return a value < 0, 0, or > 0 depending on how
arguments x, y compared against each other. With the possibility
of NaNs, the result was changed into an Accuracy (to include Undef).
Consequently, Float.Cmp results could still be compared for (in-)
equality with 0, but comparing if < 0 or > 0 would provide the
wrong answer w/o any obvious notice by the compiler.
This change wraps Float.Cmp results into a struct and accessors
are used to access the desired result. This prevents incorrect
use.
Change-Id: I34e6a6c1859251ec99b5cf953e82542025ace56f
Reviewed-on: https://go-review.googlesource.com/7526 Reviewed-by: Rob Pike <r@golang.org>
Matthew Dempsky [Fri, 6 Mar 2015 20:02:24 +0000 (12:02 -0800)]
cmd/internal/gc: remove namebuf variable
namebuf was a global char buffer in the C version of gc, which was
useful for providing common storage for constructing symbol and file
names. However, now that it's just a global Go string and the string
data is dynamically allocated anyway, it doesn't serve any purpose
except to force extra write barriers everytime it's assigned to.
Also, introduce Lookupf(fmt, args...) as shorthand for
Lookup(fmt.Sprintf(fmt, args...)), which was a very common pattern for
using namebuf.
Passes "go build -toolexec 'toolstash -cmp' -a std".
Notably, this CL shrinks 6g's text section by ~15kB:
$ size toolstash/6g tool/linux_amd64/6g
text data bss dec hex filename 4600805 605968 342988 5549761 54aec1 toolstash/6g 4585547 605968 342956 5534471 547307 tool/linux_amd64/6g
Change-Id: I98abb44fc7f43a2e2e48425cc9f215cd0be37442
Reviewed-on: https://go-review.googlesource.com/7080 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Hudson-Doyle [Sat, 7 Mar 2015 03:16:48 +0000 (16:16 +1300)]
cmd/internal/gc, etc: remove canemitecode of Naddr
The argument is never consulted apart from passing it to recursive
calls. So delete it.
Change-Id: Ia15eefb6385b3c99ea4def88f564f4e5a94c68ab
Reviewed-on: https://go-review.googlesource.com/7032 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Thu, 5 Mar 2015 21:10:33 +0000 (13:10 -0800)]
math/big: handle NaNs in Float.Cmp
Also:
- Implemented NewFloat convenience factory function (analogous to
NewInt and NewRat).
- Implemented convenience accessors for Accuracy values returned
from Float.Cmp.
- Added test and example.
Change-Id: I985bb4f86e6def222d4b2505417250d29a39c60e
Reviewed-on: https://go-review.googlesource.com/6970 Reviewed-by: Alan Donovan <adonovan@google.com>
Robert Griesemer [Thu, 5 Mar 2015 01:00:41 +0000 (17:00 -0800)]
math/big: added (internal) Float.form field for easier case distinctions
This is a fairly significant _internal_ representation change. Instead
of encoding 0, finite, infinite, and NaN values with special mantissa
and exponent values, a new (1 byte) 'form' field is used (without making
the Float struct bigger). The form field permits simpler and faster
case distinctions. As a side benefit, for zero and non-finite floats,
fewer fields need to be set. Also, the exponent range is not the full
int32 range (in the old format, infExp and nanExp were used to represent
Inf and NaN values and tests for those values sometimes didn't test
for the empty mantissa, so the range was reduced by 2 values).
The correspondence between the old and new fields is as follows.
Old representation:
Rob Pike [Tue, 10 Mar 2015 22:08:55 +0000 (15:08 -0700)]
flag: nicer usage messages
Make PrintDefaults print an easier-to-read format, and allow the user
to control it a bit by putting a hint into the usage string.
Here is the new doc comment for PrintDefaults, which does the work:
PrintDefaults prints, to standard error unless configured otherwise, a
usage message showing the default settings of all defined command-line
flags. For an integer valued flag x, the default output has the form
-x int
usage-message-for-x (default 7)
The usage message will appear on a separate line except for single-
letter boolean flags. Boolean flags omit the type, since they can be
used without an actual value, and the parenthetical default is omitted
if the default is the zero value for the type. The type, here int, can
be replaced by a string of the user's choosing by placing in the usage
string for the flag a back-quoted name; the first such item in the
message is taken to be a parameter name to show in the message and the
back quotes are stripped from the message when displayed. For instance,
given
flag.String("I", "", "search `directory` for include files")
the output will be
-I directory
search directory for include files.
Given
A = flag.Bool("A", false, "for bootstrapping, allow 'any' type")
B = flag.Bool("Alongflagname", false, "disable bounds checking")
C = flag.Bool("C", true, "a boolean defaulting to true")
D = flag.String("D", "", "set relative `path` for local imports")
F = flag.Float64("F", 2.7, "a non-zero float")
G = flag.Float64("G", 0, "a float that defaults to zero")
N = flag.Int("N", 27, "a non-zero int")
Z = flag.Int("Z", 0, "an int that defaults to zero")
T = flag.Duration("deltaT", 0, "a duration")
the old output was
-A=false: for bootstrapping, allow 'any' type
-Alongflagname=false: disable bounds checking
-C=true: a boolean defaulting to true
-D="": set relative `path` for local imports
-F=2.7: a non-zero float
-G=0: a float that defaults to zero
-N=27: a non-zero int
-Z=0: an int that defaults to zero
-deltaT=0: a duration
and the new output is
-A for bootstrapping, allow 'any' type
-Alongflagname
disable bounds checking
-C a boolean defaulting to true (default true)
-D path
set relative path for local imports
-F float
a non-zero float (default 2.7)
-G float
a float that defaults to zero
-N int
a non-zero int (default 27)
-Z int
an int that defaults to zero
-deltaT duration
a duration
Rob Pike [Wed, 11 Mar 2015 18:31:49 +0000 (11:31 -0700)]
cmd/asm: add MRC and MCR to end-to-end test for arm
The old, per-architecture operand printers didn't lock down the
format of the constant in the MRC and MCR instructions (a value
that could be presented more helpfully - maybe how the
input looks? - but that is an issue for another day). But there is
a portable standard printer now so we can enable tests for these
instructions.
Michael Hudson-Doyle [Mon, 9 Mar 2015 00:21:51 +0000 (13:21 +1300)]
cmd/internal/obj/x86: implement -shared computation of TLS base
Somehow, terribly embarrassingly, I lost part of the "re-enable
-shared on amd64" patch when rebasing before it got submitted.
This restores it and also fixes the addend to be the necessary -4.
Now updated so that Git will not put the new case into the wrong
switch.
Change-Id: I1d628232771a6d6ce6d085adf379f94a377822c5
Reviewed-on: https://go-review.googlesource.com/7126
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Geert-Johan Riemer [Mon, 19 Jan 2015 13:39:33 +0000 (14:39 +0100)]
archive/zip: add NewWriterWithOptions
When appending zip data to existing data such as a binary file the
zip headers must use the correct offset. NewWriterWithOptions
allows creating a Writer that uses the provided offset in the zip
headers.
Fixes #8669
Change-Id: I6ec64f1e816cc57b6fc8bb9e8a0918e586fc56b0
Reviewed-on: https://go-review.googlesource.com/2978 Reviewed-by: Andrew Gerrand <adg@golang.org>
Shenghou Ma [Wed, 11 Mar 2015 16:07:50 +0000 (12:07 -0400)]
runtime: don't return a slice with nil ptr but non-zero len from growslice
Fixes #10135.
Change-Id: Ic4c5ab15bcb7b9c3fcc685a788d3b59c60c26e1e Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/7400 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Thu, 5 Mar 2015 20:07:00 +0000 (15:07 -0500)]
debug/dwarf: factor parsing of unit lengths
Many headers in DWARF sections have a "unit length" that can be either
4 bytes or 12 bytes and indicates both the length of the unit and
whether the unit is in 32-bit or 64-bit format.
Currently, we implement unit length parsing in four different places.
Add a "unitLength" method to buf that parses a unit length and use it
in these four places.
Change-Id: I7950b91caaa92aa5e19aa63debc8ae46178ecc4d
Reviewed-on: https://go-review.googlesource.com/7281 Reviewed-by: Nigel Tao <nigeltao@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Matthew Dempsky [Fri, 6 Mar 2015 01:00:18 +0000 (17:00 -0800)]
cmd/internal/ld: fix package data parsing
The conversion of this logic from C introduced a few subtle behavior
changes. E.g., assigning "name := data[p0:]" and then "name =
name[:p1-p0]" actually caused name to span the vast majority of the
package data, as at the time of the second statement p0 points just
after the package name and p1 points to the end of the package data.
Similarly, the logic for advancing past the newline at the end of the
package line changed slightly: for a "package foo safe" line, the new
code would only advance up to the newline, but not past. (Albeit, in
practice this doesn't matter: newlines in package data are harmless.)
Lastly, "data[p0]" was incorrectly written as "data[0]" a few times.
Change-Id: I49017e16ba33a627f773532b418cbf85a84f2b4b
Reviewed-on: https://go-review.googlesource.com/7000 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Dmitry Vyukov [Tue, 10 Mar 2015 16:40:09 +0000 (19:40 +0300)]
cmd/trace: move goroutine analysis code to internal/trace
This allows to test goroutine analysis code in runtime/pprof tests.
Also fix a nil-deref crash in goroutine analysis code that happens on runtime/pprof tests.
Change-Id: Id7884aa29f7fe4a8d7042482a86fe434e030461e
Reviewed-on: https://go-review.googlesource.com/7301
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Matthew Dempsky [Wed, 11 Mar 2015 02:47:13 +0000 (19:47 -0700)]
cmd/yacc/testdata/expr: fix handling of negative numbers
Fixes #10129.
Change-Id: I9f56c483726f14b6c1909740549de236d5bf9cfb
Reviewed-on: https://go-review.googlesource.com/7340 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Dave Cheney [Tue, 10 Mar 2015 08:39:17 +0000 (19:39 +1100)]
debug/elf: fix arm build
This change adds the minimum necessary to implement applyRelocations.
For adg, this code uses the switch statement.
Change-Id: I0989daab8d0e36c2a4f6a315ced258b832744616
Reviewed-on: https://go-review.googlesource.com/7266 Reviewed-by: Ian Lance Taylor <iant@golang.org>