Call frame allocations can account for significant portion
of all allocations in a program, if call is executed
in an inner loop (e.g. to process every line in a log).
On the other hand, the allocation is easy to remove
using sync.Pool since the allocation is strictly scoped.
benchmark old ns/op new ns/op delta
BenchmarkCall 634 338 -46.69%
BenchmarkCall-4 496 167 -66.33%
benchmark old allocs new allocs delta
BenchmarkCall 1 0 -100.00%
BenchmarkCall-4 1 0 -100.00%
Update #7818
Change-Id: Icf60cce0a9be82e6171f0c0bd80dee2393db54a7
Reviewed-on: https://go-review.googlesource.com/1954
Reviewed-by: Keith Randall <khr@golang.org>
This change extends existing test case to Windows for helping to fix
golang.org/issue/5395.
Change-Id: Iff077fa98ede511981df513f48d84c19375b3e04
Reviewed-on: https://go-review.googlesource.com/3304
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Pointers change from run to run, making it hard to use
the debug output to identify the reason for a changed
object file.
Change-Id: I0c954da0943092c48686afc99ecf75eba516de6a
Reviewed-on: https://go-review.googlesource.com/3352
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Rob Pike <r@golang.org>
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
Fixes#9452
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
New tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites.
Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a
Reviewed-on: https://go-review.googlesource.com/3340
Reviewed-by: Adam Langley <agl@golang.org>
The %61 hack was added when runtime was is in C.
Now the Go compiler does the optimization.
Change-Id: I79c3302ec4b931eaaaaffe75e7101c92bf287fc7
Reviewed-on: https://go-review.googlesource.com/3289
Reviewed-by: Keith Randall <khr@golang.org>
BenchmarkClient is intended for profiling
the client without the HTTP server code.
The server code runs in a subprocess.
Change-Id: I9aa128604d0d4e94dc5c0372dc86f962282ed6e8
Reviewed-on: https://go-review.googlesource.com/3164
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Consider the following code:
s := "(" + string(byteSlice) + ")"
Currently we allocate a new string during []byte->string conversion,
and pass it to concatstrings. String allocation is unnecessary in
this case, because concatstrings does memorize the strings for later use.
This change uses slicebytetostringtmp to construct temp string directly
from []byte buffer and passes it to concatstrings.
I've found few such cases in std lib:
s += string(msg[off:off+c]) + "."
buf.WriteString("Sec-WebSocket-Accept: " + string(c.accept) + "\r\n")
bw.WriteString("Sec-WebSocket-Key: " + string(nonce) + "\r\n")
err = xml.Unmarshal([]byte("<Top>"+string(data)+"</Top>"), &logStruct)
d.err = d.syntaxError("invalid XML name: " + string(b))
return m, ProtocolError("malformed MIME header line: " + string(kv))
But there are much more in our internal code base.
Change-Id: I42f401f317131237ddd0cb9786b0940213af16fb
Reviewed-on: https://go-review.googlesource.com/3163
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This is another case where we can say that the address refers to stack.
We create such temps for OSTRUCTLIT initialization.
This eliminates a handful of write barriers today.
But this come up a prerequisite for another change (capturing vars by value),
otherwise we emit writebarriers in writebarrier itself when
capture writebarrier arguments by value.
Change-Id: Ibba93acd0f5431c5a4c3d90ef1e622cb9a7ff50e
Reviewed-on: https://go-review.googlesource.com/3285
Reviewed-by: Russ Cox <rsc@golang.org>
Typecheck for range variables before typechecking for range body.
Body can refer to new vars declared in for range,
so it is preferable to typecheck them before the body.
Makes typecheck order consistent between ORANGE and OFOR.
This come up during another change that computes some predicates
on variables during typechecking.
Change-Id: Ic975db61b1fd5b7f9ee78896d4cc7d93c593c532
Reviewed-on: https://go-review.googlesource.com/3284
Reviewed-by: Russ Cox <rsc@golang.org>
Half of tests currently crash with GODEBUG=wbshadow.
_PageSize is set to 8192. So data can be extended outside
of actually mapped region during rounding. Which leads to crash
during initial copying to shadow.
Use _PhysPageSize instead.
Change-Id: Iaa89992bd57f86dafa16b092b53fdc0606213acb
Reviewed-on: https://go-review.googlesource.com/3286
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we scan maps even if k/v does not contain pointers.
This is required because overflow buckets are hanging off the main table.
This change introduces a separate array that contains pointers to all
overflow buckets and keeps them alive. Buckets themselves are marked
as containing no pointers and are not scanned by GC (if k/v does not
contain pointers).
This brings maps in line with slices and chans -- GC does not scan
their contents if elements do not contain pointers.
Currently scanning of a map[int]int with 2e8 entries (~8GB heap)
takes ~8 seconds. With this change scanning takes negligible time.
Update #9477.
Change-Id: Id8a04066a53d2f743474cad406afb9f30f00eaae
Reviewed-on: https://go-review.googlesource.com/3288
Reviewed-by: Keith Randall <khr@golang.org>
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
Fixes#9452
Tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Change-Id: Ie7e04057a3a26e6becb80e845ecb5004bb482745
Reviewed-on: https://go-review.googlesource.com/2422
Reviewed-by: Adam Langley <agl@golang.org>
The argument is unused in the C code but will be used in the Go translation,
because the Prog holds information needed to invoke the right meaning
of %A in the ctxt->diag calls in vaddr.
Change-Id: I501830f8ea0e909aafd8ec9ef5d7338e109d9548
Reviewed-on: https://go-review.googlesource.com/3041
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/3310
Reviewed-by: Russ Cox <rsc@golang.org>
- Remove more ? : expressions.
- Use uint32 **hash instead of uint32 *hash[] in function argument.
- Change array.c API to use int, not int32, to match Go's slices.
- Rename strlit to newstrlit, to avoid case-insensitive collision with Strlit.
- Fix a few incorrect printf formats.
- Rename a few variables from 'len' to n or length.
- Eliminate direct string editing building up names like convI2T.
Change-Id: I754cf553402ccdd4963e51b7039f589286219c29
Reviewed-on: https://go-review.googlesource.com/3278
Reviewed-by: Rob Pike <r@golang.org>
cmd/gc contains symbol references into the back end dirs like 6g.
It also contains a few files that include the back end header files and
are compiled separately for each back end, despite being in cmd/gc.
cmd/gc also defines main, which makes at least one reverse symbol
reference unavoidable. (Otherwise you can't get into back-end code.)
This was all expedient, but it's too tightly coupled, especially for a
program written Go.
Make cmd/gc into a true library, letting the back end define main and
call into cmd/gc after making the necessary references available.
cmd/gc being a real library will ease the transition to Go.
Change-Id: I4fb9a0e2b11a32f1d024b3c56fc3bd9ee458842c
Reviewed-on: https://go-review.googlesource.com/3277
Reviewed-by: Rob Pike <r@golang.org>
- Change forward reference to struct Node* to void* in liblink.
- Use explicit (Node*) casts in cmd/gc to get at that field.
- Define struct Array in go.h instead of hiding it in array.c.
- Remove some sizeof(uint32), sizeof(uint64) uses.
- Remove some ? : expressions.
- Rewrite some problematic mid-expression assignments.
Change-Id: I308c70140238a0cfffd90e133f86f442cd0e17d4
Reviewed-on: https://go-review.googlesource.com/3276
Reviewed-by: Rob Pike <r@golang.org>
This change is a recreation of the CL written
by Nick Owens on http://golang.org/cl/150730043.
If the stat buffer is too short, the kernel
informs us by putting the 2-byte size in the
buffer, so we read that and try again.
This follows the same algorithm as /sys/src/libc/9sys/dirfstat.c.
Fixes#8781.
Change-Id: I01b4ad3a5e705dd4cab6673c7a119f8bef9bbd7c
Reviewed-on: https://go-review.googlesource.com/3281
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Creating a tar containing files with 0000 permission bits is
not going to be useful.
Change-Id: Ie489c2891c335d32270b18f37b0e32ecdca536a6
Reviewed-on: https://go-review.googlesource.com/3271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previouslly, Stmt.connStmt calls DB.connIfFree on each Stmt.css.
Since Stmt.connStmt locks Stmt.mu, a concurrent use of Stmt causes lock
contention on Stmt.mu.
Additionally, DB.connIfFree locks DB.mu which is shared by DB.addDep and
DB.removeDep.
This change removes DB.connIfFree and makes use of a first unused
connection in idle connection pool to reduce lock contention
without making it complicated.
Fixes#9484
On EC2 c3.8xlarge (E5-2680 v2 @ 2.80GHz * 32 vCPU):
benchmark old ns/op new ns/op delta
BenchmarkManyConcurrentQuery-8 40249 34721 -13.73%
BenchmarkManyConcurrentQuery-16 45610 40176 -11.91%
BenchmarkManyConcurrentQuery-32 109831 43179 -60.69%
benchmark old allocs new allocs delta
BenchmarkManyConcurrentQuery-8 25 25 +0.00%
BenchmarkManyConcurrentQuery-16 25 25 +0.00%
BenchmarkManyConcurrentQuery-32 25 25 +0.00%
benchmark old bytes new bytes delta
BenchmarkManyConcurrentQuery-8 3980 3969 -0.28%
BenchmarkManyConcurrentQuery-16 3980 3982 +0.05%
BenchmarkManyConcurrentQuery-32 3993 3990 -0.08%
Change-Id: Ic96296922c465bac38a260018c58324dae1531d9
Reviewed-on: https://go-review.googlesource.com/2207
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Implemented:
- +, -, *, /, and some unary ops
- all rounding modes
- basic conversions
- string to float conversion
- tests
Missing:
- float to string conversion, formatting
- handling of +/-0 and +/-inf (under- and overflow)
- various TODOs and cleanups
With precision set to 24 or 53, the results match
float32 or float64 operations exactly (excluding
NaNs and denormalized numbers which will not be
supported).
Change-Id: I3121e90fc4b1528e40bb6ff526008da18b3c6520
Reviewed-on: https://go-review.googlesource.com/1218
Reviewed-by: Alan Donovan <adonovan@google.com>
Rename itod to uitoa to have consistent naming with other itoa functions.
Reduce redundant code by calling uitoa from itoa.
Reduce buffer to maximally needed size for conversion of 64bit integers.
Adjust calls to itoa functions in package net to use new name for itod.
Avoid calls to itoa if uitoa suffices.
Change-Id: I79deaede4d4b0c076a99a4f4dd6f644ba1daec53
Reviewed-on: https://go-review.googlesource.com/2212
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
The compiler has a phase ordering problem. Escape analysis runs
before wrapper generation. When a generated wrapper calls a method
defined in a different package, if that call is inlined, there will be
no escape information for the variables defined in the inlined call.
Those variables will be placed on the stack, which fails if they
actually do escape.
There are probably various complex ways to fix this. This is a simple
way to avoid it: when a generated wrapper calls a method defined in a
different package, treat all local variables as escaping.
Fixes#9537.
Change-Id: I530f39346de16ad173371c6c3f69cc189351a4e9
Reviewed-on: https://go-review.googlesource.com/3092
Reviewed-by: Russ Cox <rsc@golang.org>
The build was broken on Plan 9 after the
CL 2994, because of the use of getfields
in src/liblink/go.c.
This happened when building 8l, because
getfield was part of lib9 and tokenize
was part of the Plan 9 libc. However,
both getfields and tokenize depend on
utfrune, causing an incompatibility.
This change enables the build of tokenize
as part of lib9, so it doesn't use
tokenize from the Plan 9 libc anymore.
Change-Id: I2a76903b508bd92771c4754cd53dfc64df350892
Reviewed-on: https://go-review.googlesource.com/3121
Reviewed-by: Minux Ma <minux@golang.org>
Adjust triggergc so that we trigger when we have used 7/8
of the available heap memory. Do first collection when we
exceed 4Mbytes.
Change-Id: I467b4335e16dc9cd1521d687fc1f99a51cc7e54b
Reviewed-on: https://go-review.googlesource.com/3149
Reviewed-by: Austin Clements <austin@google.com>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Id7857fb9a3b4c957c7050b519552ef1c8e55461e
Reviewed-on: https://go-review.googlesource.com/3126
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Generated from a modified go vet.
Change-Id: Ibe82941283da9bd4dbc7fa624a33ffb12424daa2
Reviewed-on: https://go-review.googlesource.com/2817
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Generated from go vet.
Change-Id: I8fee4095e43034b868bfd2b07e21ac13d5beabbb
Reviewed-on: https://go-review.googlesource.com/2816
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Adujst triggergc so that we trigger when we have used 7/8
of the available memory.
Change-Id: I7ca02546d3084e6a04d60b09479e04a9a9837ae2
Reviewed-on: https://go-review.googlesource.com/3061
Reviewed-by: Russ Cox <rsc@golang.org>
According to RFC5280 the authority key identifier extension MUST included in all
CRLs issued. This patch includes the authority key identifier extension when the
Subject Key Identifier is present in the signing certificate.
RFC5280 states:
"The authority key identifier extension provides a means of identifying the
public key corresponding to the private key used to sign a CRL. The
identification can be based on either the key identifier (the subject key
identifier in the CRL signer's certificate) or the issuer name and serial
number. This extension is especially useful where an issuer has more than one
signing key, either due to multiple concurrent key pairs or due to changeover."
Conforming CRL issuers MUST use the key identifier method, and MUST include this
extension in all CRLs issued."
This CL has been discussed at: http://golang.org/cl/177760043
Change-Id: I9bf50521908bfe777ea2398f154c13e8c90d14ad
Reviewed-on: https://go-review.googlesource.com/2258
Reviewed-by: Adam Langley <agl@golang.org>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Ie4a4a583fb120ff484a5ccf267ecd2a9c5a3902b
Reviewed-on: https://go-review.googlesource.com/2254
Reviewed-by: Adam Langley <agl@golang.org>
Unless the first element is a Universal Naming Convention (UNC)[0]
path, Join shouldn't create a UNC path on Windows.
For example, Join inadvertently creates a UNC path on Windows when
told to join at least three non-empty path elements, where the first
element is `\` or `/`.
This CL prevents creation of a UNC path prefix when the first path
element isn't a UNC path.
Since this introduces some amount of Windows-specific logic, Join is
moved to a per GOOS implementation.
Fixes#9167.
[0]: http://msdn.microsoft.com/en-us/library/gg465305.aspx
Change-Id: Ib6eda597106cb025137673b33c4828df1367f75b
Reviewed-on: https://go-review.googlesource.com/2211
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Print out the object holding the reference to the object
that checkmark detects as not being properly marked.
Change-Id: Ieedbb6fddfaa65714504af9e7230bd9424cd0ae0
Reviewed-on: https://go-review.googlesource.com/2744
Reviewed-by: Austin Clements <austin@google.com>
Close the pipe for the body of a request when it is aborted and close
all pipes when child.serve terminates.
Fixes#6934
Change-Id: I1c5e7d2116e1ff106f11a1ef8e99bf70cf04162a
Reviewed-on: https://go-review.googlesource.com/1923
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Can't use bgwait, both because it can only be used from
one goroutine at a time and because it ends up queued
behind all the other pending commands. Use a separate
signaling mechanism so that we can notice we're dying
sooner.
Change-Id: I8652bfa2f9bb5725fa5968d2dd6a745869d01c01
Reviewed-on: https://go-review.googlesource.com/3010
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code in mfinal.go is moved from malloc*.go and mgc*.go
and substantially unchanged.
The code in mbitmap.go is also moved from those files, but
cleaned up so that it can be called from those files (in most cases
the code being moved was not already a standalone function).
I also renamed the constants and wrote comments describing
the format. The result is a significant cleanup and isolation of
the bitmap code, but, roughly speaking, it should be treated
and reviewed as new code.
The other files changed only as much as necessary to support
this code movement.
This CL does NOT change the semantics of the heap or type
bitmaps at all, although there are now some obvious opportunities
to do so in followup CLs.
Change-Id: I41b8d5de87ad1d3cd322709931ab25e659dbb21d
Reviewed-on: https://go-review.googlesource.com/2991
Reviewed-by: Keith Randall <khr@golang.org>
I also added new comments at the top of mbarrier.go,
but the rest of the code is just copy-and-paste.
Change-Id: Iaeb2b12f8b1eaa33dbff5c2de676ca902bfddf2e
Reviewed-on: https://go-review.googlesource.com/2990
Reviewed-by: Austin Clements <austin@google.com>
Otherwise, if you mistakenly refer to an undeclared 'shift' variable, you get 52.
Change-Id: I845fb29f23baee1d8e17b37bde0239872eb54316
Reviewed-on: https://go-review.googlesource.com/2909
Reviewed-by: Austin Clements <austin@google.com>
As shown in #9395, inaccurate implementation would be a cause of parsing
IPv4 header twice and corrupted upper-layer message issues.
Change-Id: Ia1a042e7ca58ee4fcb38fe9ec753c2ab100592ca
Reviewed-on: https://go-review.googlesource.com/3001
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The function is here ONLY for symmetry with package bytes.
This function should be used ONLY if it makes code clearer.
It is not here for performance. Remove any performance benefit.
If performance becomes an issue, the compiler should be fixed to
recognize the three-way compare (for all comparable types)
rather than encourage people to micro-optimize by using this function.
Change-Id: I71f4130bce853f7aef724c6044d15def7987b457
Reviewed-on: https://go-review.googlesource.com/3012
Reviewed-by: Rob Pike <r@golang.org>
cmd/dist now requires $GOROOT to be set explicitly.
Set it when invoking via 'go tool dist' so that users are unaffected.
Also, change go tool -n to drop trailing space in output
for 'go tool -n <anything>'.
Change-Id: I9b2c020e0a2f3fa7c9c339fadcc22cc5b6cb7cac
Reviewed-on: https://go-review.googlesource.com/3011
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gofmt inserts a blank line line between const and var declarations
Change-Id: I3f2ddbd9e66a74eb3f37a2fe641b93820b02229e
Reviewed-on: https://go-review.googlesource.com/3022
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This manually reverts 555da73 from #6372 which implies a
minimum FreeBSD version of 8-STABLE.
Updates docs to mention new minimum requirement.
Fixes#9627
Change-Id: I40ae64be3682d79dd55024e32581e3e5e2be8aa7
Reviewed-on: https://go-review.googlesource.com/3020
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Cygwin perl uses unix pathnames in windows. Include cygwin perl in the
list of special cases for unix pathname handling in test.cgi.
Change-Id: I30445a9cc79d62d022ecc232c35aa5015b7418dc
Reviewed-on: https://go-review.googlesource.com/2973
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This brings in cmd/dist written in Go, which is working on the primary builders.
If this breaks your build, you need to get Go 1.4 and put it in $HOME/go1.4
(or, if you want to use some other directory, set $GOROOT_BOOTSTRAP
to that directory).
To build Go 1.4 from source:
git clone -b release-branch.go1.4 $GOROOT $HOME/go1.4
cd $HOME/go1.4/src
./make.bash
Or use a binary release: https://golang.org/dl/.
See https://golang.org/s/go15bootstrap for more information.
Change-Id: Ie4ae834c76ea35e39cc54e9878819a9e51b284d9
The comment says to use (y-1), but then we did add(y.abs, natOne). We meant sub.
Fixes#9609
Change-Id: I4fe4783326ca082c05588310a0af7895a48fc779
Reviewed-on: https://go-review.googlesource.com/2961
Reviewed-by: Robert Griesemer <gri@golang.org>
Generated with a modified version of go vet and tested on android.
Change-Id: I1ff20135c5ab9de5a6dbf76ea2991167271ee70d
Reviewed-on: https://go-review.googlesource.com/2815
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We were failing ^uint16(0xffff) == 0, as we computed 0xffff0000 instead.
I could only trigger a failure for the above case, the other two tests
^uint16(0xfffe) == 1 and -uint16(0xffff) == 1 didn't seem to fail
previously. Somehow they get MOVHUs inserted for other reasons (used
by CMP instead of TST?). I fixed OMINUS anyway, better safe than
sorry.
Fixes#9604
Change-Id: I4c2d5bdc667742873ac029fdbe3db0cf12893c27
Reviewed-on: https://go-review.googlesource.com/2940
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
The implementation is the same assembly (or Go) routine.
Change-Id: Ib937c461c24ad2d5be9b692b4eed40d9eb031412
Reviewed-on: https://go-review.googlesource.com/2828
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
androidtest.bash copies some go source to the android device
where the tests are going to run. It's necessary because some
tests require files and resources to be present. The copy is
done through adb sync. The script hoped faking the directory
using symlinks to work, but it doesn't. (adb sync doesn't follow
the symlinks) We need proper copy.
Change-Id: If55abca4958f159859e58512b0045f23654167e3
Reviewed-on: https://go-review.googlesource.com/2827
Reviewed-by: David Crawshaw <crawshaw@golang.org>
runtime.rtype was a copy of reflect.rtype - update script to use that directly.
Introduces a basic test which will skip on systems without appropriate GDB.
Fixes#9326
Change-Id: I6ec74e947bd2e1295492ca34b3a8c1b49315a8cb
Reviewed-on: https://go-review.googlesource.com/2821
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Do not lose precision for durations specified without fractions
that can be represented by an int64 such as 1<<53+1 nanoseconds.
Previously there was some precision lost in floating point conversion.
Handle overflow for durations above 1<<63-1 nanoseconds but not earlier.
Add tests to cover the above cases.
Change-Id: I4bcda93cee1673e501ecb6a9eef3914ee29aecd2
Reviewed-on: https://go-review.googlesource.com/2461
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
6g does not implement dead code elimination for const switches like it
does for const if statements, so the undefined raiseproc() function
was resulting in a link-time failure.
Change-Id: Ie4fcb3716cb4fe6e618033071df9de545ab3e0af
Reviewed-on: https://go-review.googlesource.com/2830
Reviewed-by: Russ Cox <rsc@golang.org>
printf, vprintf, snprintf, gc_m_ptr, gc_g_ptr, gc_itab_ptr, gc_unixnanotime.
These were called from C.
There is no more C.
Now that vprintf is gone, delete roundup, which is unsafe (see CL 2814).
Change-Id: If8a7b727d497ffa13165c0d3a1ed62abc18f008c
Reviewed-on: https://go-review.googlesource.com/2824
Reviewed-by: Austin Clements <austin@google.com>
Moving the "don't really preempt" check up earlier in the function
introduced a race where gp.stackguard0 might change between
the early check and the later one. Since the later one is missing the
"don't really preempt" logic, it could decide to preempt incorrectly.
Pull the result of the check into a local variable and use an atomic
to access stackguard0, to eliminate the race.
I believe this will fix the broken OS X and Solaris builders.
Change-Id: I238350dd76560282b0c15a3306549cbcf390dbff
Reviewed-on: https://go-review.googlesource.com/2823
Reviewed-by: Austin Clements <austin@google.com>
Since CL 2750, the build is broken on Plan 9,
because a new function netpollinited was added
and called from findrunnable in proc1.go.
However, netpoll is not implemented on Plan 9.
Thus, we define netpollinited in netpoll_stub.go.
Fixes#9590
Change-Id: I0895607b86cbc7e94c1bfb2def2b1a368a8efbe6
Reviewed-on: https://go-review.googlesource.com/2759
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These were fixed in my local commit,
but I forgot that the web Submit button can't see that.
Change-Id: Iec3a70ce3ccd9db2a5394ae2da0b293e45ac2fb5
Reviewed-on: https://go-review.googlesource.com/2822
Reviewed-by: Russ Cox <rsc@golang.org>
During all.bash I got a crash in the GOMAXPROCS=2 runtime test reporting
that the write barrier in the assignment 'c.tiny = add(x, size)' had been
given a pointer pointing into an unexpected span. The problem is that
the tiny allocation was at the end of a span and c.tiny was now pointing
to the end of the allocation and therefore to the end of the span aka
the beginning of the next span.
Rewrite tinyalloc not to do that.
More generally, it's not okay to call add(p, size) unless you know that p
points at > (not just >=) size bytes. Similarly, pretty much any call to
roundup doesn't know how much space p points at, so those are all
broken.
Rewrite persistentalloc not to use add(p, totalsize) and not to use roundup.
There is only one use of roundup left, in vprintf, which is dead code.
I will remove that code and roundup itself in a followup CL.
Change-Id: I211e307d1a656d29087b8fd40b2b71010722fb4a
Reviewed-on: https://go-review.googlesource.com/2814
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
It could happen that mp.printlock++ happens, then on entry to lock,
the goroutine is preempted and then rescheduled onto another m
for the actual call to lock. Now the lock and the printlock++ have
happened on different m's. This can lead to printlock not being
unlocked, which either gives a printing deadlock or a crash when
the goroutine reschedules, because m.locks > 0.
Change-Id: Ib0c08740e1b53de3a93f7ebf9b05f3dceff48b9f
Reviewed-on: https://go-review.googlesource.com/2819
Reviewed-by: Rick Hudson <rlh@golang.org>
Go 1.4 should build what it knows how to build.
GOHOSTOS and GOHOSTARCH are for the Go 1.5 build only.
Change-Id: Id0f367f03485100a896e61cfdace4ac44a22e16d
Reviewed-on: https://go-review.googlesource.com/2818
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mostly this is using uint32 instead of int32 for unsigned values
like instruction encodings or float32 bit representations,
removal of ternary operations, and removal of #defines.
Delete sched9.c, because it is not compiled (it is still in the history
if we ever need it).
Change-Id: I68579cfea679438a27a80416727a9af932b088ae
Reviewed-on: https://go-review.googlesource.com/2658
Reviewed-by: Austin Clements <austin@google.com>
Normally, a panic/throw only shows the thread stack for the current thread
and all paused goroutines. Goroutines running on other threads, or other threads
running on their system stacks, are opaque. Change that when GODEBUG=crash,
by passing a SIGQUIT around to all the threads when GODEBUG=crash.
If this works out reasonably well, we might make the SIGQUIT relay part of
the standard panic/throw death, perhaps eliding idle m's.
Change-Id: If7dd354f7f3a6e326d17c254afcf4f7681af2f8b
Reviewed-on: https://go-review.googlesource.com/2811
Reviewed-by: Rick Hudson <rlh@golang.org>
There is a small possibility that runtime deadlocks when netpoll is just activated.
Consider the following scenario:
GOMAXPROCS=1
epfd=-1 (netpoll is not activated yet)
A thread is in findrunnable, sets sched.lastpoll=0, calls netpoll(true),
which returns nil. Now the thread is descheduled for some time.
Then sysmon retakes a P from syscall and calls handoffp.
The "If this is the last running P and nobody is polling network" check in handoffp fails,
since the first thread set sched.lastpoll=0. So handoffp decides that there is already
a thread that polls network and so it calls pidleput.
Now the first thread is scheduled again, finds no work and calls stopm.
There is no thread that polls network and so checkdead reports deadlock.
To fix this, don't set sched.lastpoll=0 when netpoll is not activated.
The deadlock can happen if cgo is disabled (-tag=netgo) and only on program startup
(when netpoll is just activated).
The test is from issue 5216 that lead to addition of the
"If this is the last running P and nobody is polling network" check in handoffp.
Update issue 9576.
Change-Id: I9405f627a4d37bd6b99d5670d4328744aeebfc7a
Reviewed-on: https://go-review.googlesource.com/2750
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The old name was too ambiguous (is it a verb? is it a predicate? is
it a constant?) and too close to debug.gccheckmark. Hopefully the new
name conveys that this variable indicates that we are currently doing
mark checking.
Change-Id: I031cd48b0906cdc7774f5395281d3aeeb8ef3ec9
Reviewed-on: https://go-review.googlesource.com/2656
Reviewed-by: Rick Hudson <rlh@golang.org>
1) Move non-preemption check even earlier in newstack.
This avoids a few priority inversion problems.
2) Always use atomic operations to update bitmap for 1-word objects.
This avoids lost mark bits during concurrent GC.
3) Stop using work.nproc == 1 as a signal for being single-threaded.
The concurrent GC runs with work.nproc == 1 but other procs are
running mutator code.
The use of work.nproc == 1 in getfull *is* safe, but remove it anyway,
since it is saving only a single atomic operation per GC round.
Fixes#9225.
Change-Id: I24134f100ad592ea8cb59efb6a54f5a1311093dc
Reviewed-on: https://go-review.googlesource.com/2745
Reviewed-by: Rick Hudson <rlh@golang.org>
Generated from a script using go vet then read by a human.
Change-Id: Ie5f7ab3a1075a9c8defbf5f827a8658e3eb55cab
Reviewed-on: https://go-review.googlesource.com/2746
Reviewed-by: Ian Lance Taylor <iant@golang.org>
https://go-review.googlesource.com/#/c/1876/ introduced a new
TestClipWithNilMP test, along with a code change that fixed a panic,
but the existing TestClip test already contained almost enough machinery
to cover that bug.
There is a small code change in this CL, but it is a no-op: (*x).y is
equivalent to x.y for a pointer-typed x, but the latter is cleaner.
Change-Id: I79cf6952a4999bc4b91f0a8ec500acb108106e56
Reviewed-on: https://go-review.googlesource.com/2304
Reviewed-by: Dave Cheney <dave@cheney.net>
Make auxv parsing in linux/arm less of a special case.
* rename setup_auxv to sysargs
* exclude linux/arm from vdso_none.go
* move runtime.checkarm after runtime.sysargs so arm specific
values are properly initialised
Change-Id: I1ca7f5844ad5a162337ff061a83933fc9a2b5ff6
Reviewed-on: https://go-review.googlesource.com/2681
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fix SmartOS build that was broken in 682922908f.
SmartOS pretends to be Ubuntu/Debian with respect to its SSL
certificate location.
Change-Id: I5405c6472c8a1e812e472e7301bf6084c17549d6
Reviewed-on: https://go-review.googlesource.com/2704
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For some cases we can ensure the correct order of elements in two
instead of three comparisons. It is unnecessary to compare m0 and
m1 again if m2 and m1 are not swapped.
benchmark old ns/op new ns/op delta
BenchmarkSortString1K 302721 299590 -1.03%
BenchmarkSortInt1K 124055 123215 -0.68%
BenchmarkSortInt64K 12291522 12203402 -0.72%
BenchmarkSort1e2 58027 57111 -1.58%
BenchmarkSort1e4 12426805 12341761 -0.68%
BenchmarkSort1e6 1966250030 1960557883 -0.29%
Change-Id: I2b17ff8dee310ec9ab92a6f569a95932538768a9
Reviewed-on: https://go-review.googlesource.com/2614
Reviewed-by: Robert Griesemer <gri@golang.org>
This change implements the requirement of
old Go to build new Go on Plan 9. Also fix
the build of the new cmd/dist written in Go.
This is similar to the make.bash change in
CL 2470, but applied to make.rc for Plan 9.
Change-Id: Ifd9a3bd8658e2cee6f92b4c7f29ce86ee2a93c53
Reviewed-on: https://go-review.googlesource.com/2662
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the previous sandbox implementation we read all sandboxed output
from standard output, and so all fake time writes were made to
standard output. Now we have a more sophisticated sandbox server
(see golang.org/x/playground/sandbox) that is capable of recording
both standard output and standard error, so allow fake time writes to
go to either file descriptor.
Change-Id: I79737deb06fd8e0f28910f21f41bd3dc1726781e
Reviewed-on: https://go-review.googlesource.com/2713
Reviewed-by: Minux Ma <minux@golang.org>
Skip the allocation testing (which was only used as a signal for
whether the interface was implemented by ResponseWriter), and just
test for it directly.
Fixes#9575
Change-Id: Ie230f1d21b104537d5647e9c900a81509d692469
Reviewed-on: https://go-review.googlesource.com/2720
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
These are corresponding Windows changes for the GOROOT_BOOTSTRAP and
dist changes in https://golang.org/cl/2470
Change-Id: I21da2d63a60d8ae278ade9bb71ae0c314a2cf9b5
Reviewed-on: https://go-review.googlesource.com/2674
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
RFC5280 states:
"This optional field describes the version of the encoded CRL. When
extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1)."
This CL has been discussed at: http://golang.org/cl/172560043
Change-Id: I8a72d7593d5ca6714abe9abd6a37437c3b69ab0f
Reviewed-on: https://go-review.googlesource.com/2259
Reviewed-by: Adam Langley <agl@golang.org>
And add names for the curve implemented in crypto/elliptic.
This permits a safer alternative to switching on BitSize
for code that implements curve-dependent cryptosystems.
(E.g., ECDSA on P-xxx curves with the matched SHA-2
instances.)
Change-Id: I653c8f47506648028a99a96ebdff8389b2a95fc1
Reviewed-on: https://go-review.googlesource.com/2133
Reviewed-by: Adam Langley <agl@golang.org>
According to RFC4055 a NULL parameter MUST be present in the signature
algorithm. This patch adds the NULL value to the Signature Algorithm
parameters in the signingParamsForPrivateKey function for RSA based keys.
Section 2.1 states:
"There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.
All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.
To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }"
This CL has been discussed at: http://golang.org/cl/177610043
Change-Id: Ic782161938b287f34f64ef5eb1826f0d936f2f71
Reviewed-on: https://go-review.googlesource.com/2256
Reviewed-by: Adam Langley <agl@golang.org>
While we're here, rename TestIssue7234 to Test7234 for consistency
with other tests.
Fixes#9557.
Change-Id: I22b0a212b31e7b4f199f6a70deb73374beb80f84
Reviewed-on: https://go-review.googlesource.com/2654
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Please see golang.org/cl/2588 for reasons behind the name change.
We also need NO_LOCAL_POINTERS for assembly function with non-zero
local frame size.
Change-Id: Iac60aa7e76f4c2ece3726e28878fd539bfebf7a4
Reviewed-on: https://go-review.googlesource.com/2589
Reviewed-by: Ian Lance Taylor <iant@golang.org>
* Use WORD declaration so 5a can't rewrite the instruction or complain
about forms it doesn't know about.
* Add the interpunct to function declaration.
Change-Id: I8494548db21b3ea52f0e1e0e547d9ead8b93dfd1
Reviewed-on: https://go-review.googlesource.com/2682
Reviewed-by: Minux Ma <minux@golang.org>
Previously, gccheckmark could only be enabled or disabled by calling
runtime.GCcheckmarkenable/GCcheckmarkdisable. This was a necessary
hack because GODEBUG was broken.
Now that GODEBUG works again, move control over gccheckmark to a
GODEBUG variable and remove these runtime functions. Currently,
gccheckmark is enabled by default (and will probably remain so for
much of the 1.5 development cycle).
Change-Id: I2bc6f30c21b795264edf7dbb6bd7354b050673ab
Reviewed-on: https://go-review.googlesource.com/2603
Reviewed-by: Rick Hudson <rlh@golang.org>
It was just an oversight that this one method of Logger was not
made available for the standard (std) Logger.
Fixes#9183
Change-Id: I2f251becdb0bae459212d09ea0e5e88774d16dea
Reviewed-on: https://go-review.googlesource.com/2686
Reviewed-by: Andrew Gerrand <adg@golang.org>
Renaming the function broke the race detector since it looked for the
name, didn't find it anymore and didn't insert the necessary
instrumentation.
Change-Id: I11fed6e807cc35be5724d26af12ceff33ebf4f7b
Reviewed-on: https://go-review.googlesource.com/2661
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
This CL introduces the bootstrap requirement that in order to
build the current release (or development version) of Go, you
need an older Go release (1.4 or newer) already installed.
This requirement is the whole point of this CL.
To enforce the requirement, convert cmd/dist from C to Go.
With this bootstrapping out of the way, we can move on to
replacing other, larger C programs like the Go compiler,
the assemblers, and the linker.
See golang.org/s/go15bootstrap for details.
Change-Id: I53fd08ddacf3df9fae94fe2c986dba427ee4a21d
Reviewed-on: https://go-review.googlesource.com/2470
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This CL makes the next one have nice cross-file diffs.
Change-Id: I9ce897dc505dea9923be4e823bae31f4f7fa2ee2
Reviewed-on: https://go-review.googlesource.com/2471
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also fix one unaligned stack size for nacl that is caught
by this change.
Fixes#9539.
Change-Id: Ib696a573d3f1f9bac7724f3a719aab65a11e04d3
Reviewed-on: https://go-review.googlesource.com/2600
Reviewed-by: Keith Randall <khr@golang.org>
CL 2520 omitted to set the type for an OCONVNOP node.
Typechecking obviously cannot do it for us.
5g inserts float64 <--> [u]int64 conversions at walk time.
The missing type caused it to crash.
Change-Id: Idce381f219bfef2e3a3be38d3ba3c258b71310ae
Reviewed-on: https://go-review.googlesource.com/2640
Reviewed-by: Keith Randall <khr@golang.org>
Recognize loops of the form
for i := range a {
a[i] = zero
}
in which the evaluation of a is free from side effects.
Replace these loops with calls to memclr.
This occurs in the stdlib in 18 places.
The motivating example is clearing a byte slice:
benchmark old ns/op new ns/op delta
BenchmarkGoMemclr5 3.31 3.26 -1.51%
BenchmarkGoMemclr16 13.7 3.28 -76.06%
BenchmarkGoMemclr64 50.8 4.14 -91.85%
BenchmarkGoMemclr256 157 6.02 -96.17%
Update #5373.
Change-Id: I99d3e6f5f268e8c6499b7e661df46403e5eb83e4
Reviewed-on: https://go-review.googlesource.com/2520
Reviewed-by: Keith Randall <khr@golang.org>
If an inbound connection is closed, cancel the outbound http request.
This is particularly useful if the outbound request may consume resources
unnecessarily until it is cancelled.
Fixes#8406
Change-Id: I738c4489186ce342f7e21d0ea3f529722c5b443a
Signed-off-by: Peter Waller <p@pwaller.net>
Reviewed-on: https://go-review.googlesource.com/2320
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#9541.
Change-Id: I5d659ad50d7c3d1c92ed9feb86cda4c1a6e62054
Reviewed-on: https://go-review.googlesource.com/2584
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reduce buffer to maximally needed size for conversion of 64bit integers.
Reduce number of used integer divisions.
benchmark old ns/op new ns/op delta
BenchmarkItoa 144 119 -17.36%
BenchmarkPrintln 783 752 -3.96%
Change-Id: I6d57a7feebf90f303be5952767107302eccf4631
Reviewed-on: https://go-review.googlesource.com/2215
Reviewed-by: Rob Pike <r@golang.org>
Random is bad, it can block and prevent binaries from starting.
Use urandom instead. We'd rather have bad random bits than no
random bits.
Change-Id: I360e1cb90ace5518a1b51708822a1dae27071ebd
Reviewed-on: https://go-review.googlesource.com/2582
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Minux Ma <minux@golang.org>
This is a replay of CL 189760043 that is in release-branch.go1.4,
but not in master branch somehow.
Change-Id: I11eb40a24273e7be397e092ef040e54efb8ffe86
Reviewed-on: https://go-review.googlesource.com/2541
Reviewed-by: Andrew Gerrand <adg@golang.org>
In 32-bit worlds, 8-byte objects are only aligned to 4-byte boundaries.
Change-Id: I91469a9a67b1ee31dd508a4e105c39c815ecde58
Reviewed-on: https://go-review.googlesource.com/2581
Reviewed-by: Keith Randall <khr@golang.org>
For a non-zero-sized struct with a final zero-sized field,
add a byte to the size (before rounding to alignment). This
change ensures that taking the address of the zero-sized field
will not incorrectly leak the following object in memory.
reflect.funcLayout also needs this treatment.
Fixes#9401
Change-Id: I1dc503dc5af4ca22c8f8c048fb7b4541cc957e0f
Reviewed-on: https://go-review.googlesource.com/2452
Reviewed-by: Russ Cox <rsc@golang.org>
Add compile time constants for bases 10 and 16 instead of computing the cutoff
value on every invocation of ParseUint by a division.
Reduce usage of slice operations.
amd64:
benchmark old ns/op new ns/op delta
BenchmarkAtoi 44.6 36.0 -19.28%
BenchmarkAtoiNeg 44.2 38.9 -11.99%
BenchmarkAtoi64 72.5 56.7 -21.79%
BenchmarkAtoi64Neg 66.1 58.6 -11.35%
386:
benchmark old ns/op new ns/op delta
BenchmarkAtoi 86.6 73.0 -15.70%
BenchmarkAtoiNeg 86.6 72.3 -16.51%
BenchmarkAtoi64 126 108 -14.29%
BenchmarkAtoi64Neg 126 108 -14.29%
Change-Id: I0a271132120d776c97bb4ed1099793c73e159893
Reviewed-on: https://go-review.googlesource.com/2460
Reviewed-by: Robert Griesemer <gri@golang.org>
run GC in its own background goroutine making the
caller runnable if resources are available. This is
critical in single goroutine applications.
Allow goroutines that allocate a lot to help out
the GC and in doing so throttle their own allocation.
Adjust test so that it only detects that a GC is run
during init calls and not whether the GC is memory
efficient. Memory efficiency work will happen later
in 1.5.
Change-Id: I4306f5e377bb47c69bda1aedba66164f12b20c2b
Reviewed-on: https://go-review.googlesource.com/2349
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This improves the printing of GC times to be both more human-friendly
and to provide enough information for the construction of MMU curves
and other statistics. The new times look like:
GC: #8 72413852ns @143036695895725 pause=622900 maxpause=427037 goroutines=11 gomaxprocs=4
GC: sweep term: 190584ns max=190584 total=275001 procs=4
GC: scan: 260397ns max=260397 total=902666 procs=1
GC: install wb: 5279ns max=5279 total=18642 procs=4
GC: mark: 71530555ns max=71530555 total=186694660 procs=1
GC: mark term: 427037ns max=427037 total=1691184 procs=4
This prints gomaxprocs and the number of procs used in each phase for
the benefit of analyzing mutator utilization during concurrent phases.
This also means the analysis doesn't have to hard-code which phases
are STW.
This prints the absolute start time only for the GC cycle. The other
start times can be derived from the phase durations. This declutters
the view for humans readers and doesn't pose any additional complexity
for machine readers.
This removes the confusing "cycle" terminology. Instead, this places
the phase duration after the phase name and adds a "ns" unit, which
both makes it implicitly clear that this is the duration of that phase
and indicates the units of the times.
This adds a "GC:" prefix to all lines for easier identification.
Finally, this generally cleans up the code as well as the placement of
spaces in the output and adds print locking so the statistics blocks
are never interrupted by other prints.
Change-Id: Ifd056db83ed1b888de7dfa9a8fc5732b01ccc631
Reviewed-on: https://go-review.googlesource.com/2542
Reviewed-by: Rick Hudson <rlh@golang.org>
Edge cases like base 2 and 36 conversions are now covered.
Many tests are mirrored from the itoa tests.
Added more test cases for syntax errors.
Change-Id: Iad8b2fb4854f898c2bfa18cdeb0cb4a758fcfc2e
Reviewed-on: https://go-review.googlesource.com/2463
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
I would like to create new syscalls in src/internal/syscall,
and I prefer not to add new shell scripts for that.
Replacement for CL 136000043.
Change-Id: I840116b5914a2324f516cdb8603c78973d28aeb4
Reviewed-on: https://go-review.googlesource.com/1940
Reviewed-by: Russ Cox <rsc@golang.org>
$GOTESTONLY controls which set of tests gets run. Only "std" is
supported. This should bring the time of plan9 builder down
from 90 minutes to a maybe 10-15 minutes when running on GCE.
(Plan 9 has performance problems when running on GCE, and/or with the
os/exec package)
This is a temporary workaround for one builder. The other Plan 9
builders will continue to do full builds. The plan9 buidler will be
renamed plan9-386-gcepartial or something to indicate it's not running
the 'test/*' directory, or API tests. Go on Plan 9 has bigger problems
for now. This lets us get trybots going sooner including Plan 9,
without waiting 90+ minutes.
Update #9491
Change-Id: Ic505e9169c6b304ed4029b7bdfb77bb5c8fa8daa
Reviewed-on: https://go-review.googlesource.com/2522
Reviewed-by: Rob Pike <r@golang.org>
This isn't the final answer, but it will give us a clue about what's
going on.
Update #9491
Change-Id: I997f6004eb97e86a4a89a8caabaf58cfdf92a8f0
Reviewed-on: https://go-review.googlesource.com/2510
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Increasing the timeout prevents the runtime test
to time out on the Plan 9 instances running on GCE.
Update golang/go#9491
Change-Id: Id9c2b0c4e59b103608565168655799b353afcd77
Reviewed-on: https://go-review.googlesource.com/2462
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now that there's no 6c compiler anymore, there's no need for cgo to
generate C headers that are compatible with it.
Fixes#9528
Change-Id: I43f53869719eb9a6065f1b39f66f060e604cbee0
Reviewed-on: https://go-review.googlesource.com/2482
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The compiler converts 'val, ok = m[key]' to
tmp, ok = <runtime call>
val = *tmp
For lookups of the form '_, ok = m[key]',
the second statement is unnecessary.
By not generating it we save a nil check.
Change-Id: I21346cc195cb3c62e041af8b18770c0940358695
Reviewed-on: https://go-review.googlesource.com/1975
Reviewed-by: Russ Cox <rsc@golang.org>
The equal algorithm used to take the size
equal(p, q *T, size uintptr) bool
With this change, it does not
equal(p, q *T) bool
Similarly for the hash algorithm.
The size is rarely used, as most equal functions know the size
of the thing they are comparing. For instance f32equal already
knows its inputs are 4 bytes in size.
For cases where the size is not known, we allocate a closure
(one for each size needed) that points to an assembly stub that
reads the size out of the closure and calls generic code that
has a size argument.
Reduces the size of the go binary by 0.07%. Performance impact
is not measurable.
Change-Id: I6e00adf3dde7ad2974adbcff0ee91e86d2194fec
Reviewed-on: https://go-review.googlesource.com/2392
Reviewed-by: Russ Cox <rsc@golang.org>
Use a lookup table to find the function which contains a pc. It is
faster than the old binary search. findfunc is used primarily for
stack copying and garbage collection.
benchmark old ns/op new ns/op delta
BenchmarkStackCopy 294746596 255400980 -13.35%
(findfunc is one of several tasks done by stack copy, the findfunc
time itself is about 2.5x faster.)
The lookup table is built at link time. The table grows the binary
size by about 0.5% of the text segment.
We impose a lower limit of 16 bytes on any function, which should not
have much of an impact. (The real constraint required is <=256
functions in every 4096 bytes, but 16 bytes/function is easier to
implement.)
Change-Id: Ic315b7a2c83e1f7203cd2a50e5d21a822e18fdca
Reviewed-on: https://go-review.googlesource.com/2097
Reviewed-by: Russ Cox <rsc@golang.org>
This implements support for calls to and from C in the ppc64 C ABI, as
well as supporting functionality such as an entry point from the
dynamic linker.
Change-Id: I68da6df50d5638cb1a3d3fef773fb412d7bf631a
Reviewed-on: https://go-review.googlesource.com/2009
Reviewed-by: Russ Cox <rsc@golang.org>
Cgo will need this for calls from C to Go and for handling signals
that may occur in C code.
Change-Id: I50cc4caf17cd142bff501e7180a1e27721463ada
Reviewed-on: https://go-review.googlesource.com/2008
Reviewed-by: Russ Cox <rsc@golang.org>
R13 is the C TLS pointer. Once we're calling to and from C code, if
we clobber R13 in our code, sigtramp won't know whether to get the
current g from REGG or from C TLS. The simplest solution is for Go
code to preserve the C TLS pointer. This is equivalent to what other
platforms do, except that on other platforms the TLS pointer is in a
special register.
Change-Id: I076e9cb83fd78843eb68cb07c748c4705c9a4c82
Reviewed-on: https://go-review.googlesource.com/2007
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This implements the ELF relocations and dynamic linking tables
necessary to support internal linking on ppc64. It also marks ppc64le
ELF files as ABI v2; failing to do this doesn't seem to confuse the
loader, but it does confuse libbfd (and hence gdb, objdump, etc).
Change-Id: I559dddf89b39052e1b6288a4dd5e72693b5355e4
Reviewed-on: https://go-review.googlesource.com/2006
Reviewed-by: Russ Cox <rsc@golang.org>
Most ppc64 relocations come in six or more variants where the basic
relocation formula is the same, but which bits of the computed value
are installed where changes. Introduce the concept of "variants" for
internal relocations to support this. Since this applies to
architecture-independent relocation types like R_PCREL, we do this in
relocsym.
Currently there is only an identity variant. A later CL that adds
support for ppc64 ELF relocations will introduce more.
Change-Id: I0c5f0e7dbe5beece79cd24fe36267d37c52f1a0c
Reviewed-on: https://go-review.googlesource.com/2005
Reviewed-by: Russ Cox <rsc@golang.org>
ppc64 has a bunch of these.
Change-Id: I3b93ed2bae378322a8dec036b1681e520b56ff53
Reviewed-on: https://go-review.googlesource.com/2003
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
ppc64 function symbols have both a global entry point and a local
entry point, where the difference is stashed in sym.other. We'll need
this information to generate calls to ELF ABI functions.
Change-Id: Ibe343923f56801de7ebec29946c79690a9ffde57
Reviewed-on: https://go-review.googlesource.com/2002
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Cache 2KB, 4KB, 8KB, and 16KB stacks. Larger stacks
will be allocated directly. There is no point in cacheing
32KB+ stacks as we ask for and return 32KB at a time
from the allocator.
Note that the minimum stack is 8K on windows/64bit and 4K on
windows/32bit and plan9. For these os/arch combinations,
the number of stack orders is less so that we have the same
maximum cached size.
Fixes#9045
Change-Id: Ia4195dd1858fb79fc0e6a91ae29c374d28839e44
Reviewed-on: https://go-review.googlesource.com/2098
Reviewed-by: Russ Cox <rsc@golang.org>
The ones at the end of M and G are just used to compute
their size for use in assembly. Generate the size explicitly.
The one at the end of itab is variable-sized, and at least one.
The ones at the end of interfacetype and uncommontype are not
needed, as the preceding slice references them (the slice was
originally added for use by reflect?).
The one at the end of stackmap is already accessed correctly,
and the runtime never allocates one.
Update #9401
Change-Id: Ia75e3aaee38425f038c506868a17105bd64c712f
Reviewed-on: https://go-review.googlesource.com/2420
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Fold in some startup randomness to make the hash vary across
different runs. This helps prevent attackers from choosing
keys that all map to the same bucket.
Also, reorganize the hash a bit. Move the *m1 multiply to after
the xor of the current hash and the message. For hash quality
it doesn't really matter, but for DDOS resistance it helps a lot
(any processing done to the message before it is merged with the
random seed is useless, as it is easily inverted by an attacker).
Update #9365
Change-Id: Ib19968168e1bbc541d1d28be2701bb83e53f1e24
Reviewed-on: https://go-review.googlesource.com/2344
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The gc toolchain no longer includes a C compiler, so mentions of "6c"
can be removed or replaced by 6g as appropriate. Similarly, some cgo
functions that previously generated C source output no longer need to.
Change-Id: I1ae6b02630cff9eaadeae6f3176c0c7824e8fbe5
Reviewed-on: https://go-review.googlesource.com/2391
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reader.Discard is the complement to Peek. It discards the next n bytes
of input.
We already have Reader.Buffered to see how many bytes of data are
sitting available in memory, and Reader.Peek to get that that buffer
directly. But once you're done with the Peek'd data, you can't get rid
of it, other than Reading it.
Both Read and io.CopyN(ioutil.Discard, bufReader, N) are relatively
slow. People instead resort to multiple blind ReadByte calls, just to
advance the internal b.r variable.
I've wanted this previously, several people have asked for it in the
past on golang-nuts/dev, and somebody just asked me for it again in a
private email. There are a few places in the standard library we'd use
it too.
Change-Id: I85dfad47704a58bd42f6867adbc9e4e1792bc3b0
Reviewed-on: https://go-review.googlesource.com/2260
Reviewed-by: Russ Cox <rsc@golang.org>
This CL only fixes the build, there are two failing tests:
RaceMapBigValAccess1 and RaceMapBigValAccess2
in runtime/race tests. I haven't investigated why yet.
Updates #9516.
Change-Id: If5bd2f0bee1ee45b1977990ab71e2917aada505f
Reviewed-on: https://go-review.googlesource.com/2401
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use direct binary insertion instead of recursive calls to symMerge
when one of the blocks has only one element.
benchmark old ns/op new ns/op delta
BenchmarkStableString1K 421999 397629 -5.77%
BenchmarkStableInt1K 123422 120592 -2.29%
BenchmarkStableInt64K 9629094 9620200 -0.09%
BenchmarkStable1e2 123089 120209 -2.34%
BenchmarkStable1e4 39505228 36870029 -6.67%
BenchmarkStable1e6 8196612367 7630840157 -6.90%
Change-Id: I49905a909e8595cfa05920ccf9aa00a8f3036110
Reviewed-on: https://go-review.googlesource.com/2219
Reviewed-by: Robert Griesemer <gri@golang.org>
sysReserve doesn't actually reserve the full amount requested on
64-bit systems, because of problems with ulimit. Instead it checks
that it can get the first 64 kB and assumes it can grab the rest as
needed. This doesn't work well with the "let the kernel pick an address"
mode, so don't do that. Pick a high address instead.
Change-Id: I4de143a0e6fdeb467fa6ecf63dcd0c1c1618a31c
Reviewed-on: https://go-review.googlesource.com/2345
Reviewed-by: Rick Hudson <rlh@golang.org>
The line 'mp.schedlink = mnext' has an implicit write barrier call,
which needs a valid g. Move it above the setg(nil).
Change-Id: If3e86c948e856e10032ad89f038bf569659300e0
Reviewed-on: https://go-review.googlesource.com/2347
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
There are two methods by which TLS clients signal the renegotiation
extension: either a special cipher suite value or a TLS extension.
It appears that I left debugging code in when I landed support for the
extension because there's a "+ 1" in the switch statement that shouldn't
be there.
The effect of this is very small, but it will break Firefox if
security.ssl.require_safe_negotiation is enabled in about:config.
(Although almost nobody does this.)
This change fixes the original bug and adds a test. Sadly the test is a
little complex because there's no OpenSSL s_client option that mirrors
that behaviour of require_safe_negotiation.
Change-Id: Ia6925c7d9bbc0713e7104228a57d2d61d537c07a
Reviewed-on: https://go-review.googlesource.com/1900
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
SignPSS is documented as allowing opts to be nil, but actually
crashes in that case. This change fixes that.
Change-Id: Ic48ff5f698c010a336e2bf720e0f44be1aecafa0
Reviewed-on: https://go-review.googlesource.com/2330
Reviewed-by: Minux Ma <minux@golang.org>
First, call clearcheckmarks immediately after changing checkmark,
so that there is less time when the checkmark flag and the bitmap
are inconsistent. The tiny gap between the two lines is fine, because
the world is stopped. Before, the gap was much larger and included
such code as "go bgsweep()", which allocated.
Second, modify gcphase only when the world is stopped.
As written, gcscan_m was changing gcphase from 0 to GCscan
and back to 0 while other goroutines were running.
Another goroutine running at the same time might decide to
sleep, see GCscan, call gcphasework, and start "helping" by
scanning its stack. That's fine, except that if gcphase flips back
to 0 as the goroutine calls scanblock, it will start draining the
work buffers prematurely.
Both of these were found wbshadow=2 (and a lot of hard work).
Eventually that will run automatically, but right now it still
doesn't quite work for all.bash, due to mmap conflicts with
pthread-created threads.
Change-Id: I99aa8210cff9c6e7d0a1b62c75be32a23321897b
Reviewed-on: https://go-review.googlesource.com/2340
Reviewed-by: Rick Hudson <rlh@golang.org>
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I5624b509a36650bce6834cf394b9da163abbf8c0
Reviewed-on: https://go-review.googlesource.com/2310
Reviewed-by: Rick Hudson <rlh@golang.org>
Use typedmemmove, typedslicecopy, and adjust reflect.call
to execute the necessary write barriers.
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Iec5b5b0c1be5589295e28e5228e37f1a92e07742
Reviewed-on: https://go-review.googlesource.com/2312
Reviewed-by: Keith Randall <khr@golang.org>
These depend on storing arbitrary integer values using
pointer atomics, and we can't support that anymore.
Change-Id: I8cadd6d462c3eebdbe7078f43fe7c779fa8f52b3
Reviewed-on: https://go-review.googlesource.com/2311
Reviewed-by: Rick Hudson <rlh@golang.org>
A side effect of this change is that when assertI2T writes to the
memory for the T being extracted, it can use typedmemmove
for write barriers.
There are other ways we could have done this, but this one
finishes a TODO in package runtime.
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Icbc8aabfd8a9b1f00be2e421af0e3b29fa54d01e
Reviewed-on: https://go-review.googlesource.com/2279
Reviewed-by: Keith Randall <khr@golang.org>
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I1320d5340a9e421c779f24f3b170e33974e56e4f
Reviewed-on: https://go-review.googlesource.com/2278
Reviewed-by: Rick Hudson <rlh@golang.org>
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Iea83d693480c2f3008b4e80d55821acff65970a6
Reviewed-on: https://go-review.googlesource.com/2277
Reviewed-by: Keith Randall <khr@golang.org>
Preparation for replacing many memmove calls in runtime
with typedmemmove, which is a clearer description of what
the routine is doing.
For the same reason, rename writebarriercopy to typedslicecopy.
Change-Id: I6f23bef2c2215509fefba175b16908f76dc7538c
Reviewed-on: https://go-review.googlesource.com/2276
Reviewed-by: Rick Hudson <rlh@golang.org>
Add write barrier to atomic operations manipulating pointers.
In general an atomic write of a pointer word may indicate racy accesses,
so there is no strictly safe way to attempt to keep the shadow copy
in sync with the real one. Instead, mark the shadow copy as not used.
Redirect sync/atomic pointer routines back to the runtime ones,
so that there is only one copy of the write barrier and shadow logic.
In time we might consider doing this for most of the sync/atomic
functions, but for now only the pointer routines need that treatment.
Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I852936b9a111a6cb9079cfaf6bd78b43016c0242
Reviewed-on: https://go-review.googlesource.com/2066
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The Gobuf.g goroutine pointer is almost always updated by assembly code.
In one of the few places it is updated by Go code - func save - it must be
treated as a uintptr to avoid a write barrier being emitted at a bad time.
Instead of figuring out how to emit the write barriers missing in the
assembly manipulation, change the type of the field to uintptr, so that
it does not require write barriers at all.
Goroutine structs are published in the allg list and never freed.
That will keep the goroutine structs from being collected.
There is never a time that Gobuf.g's contain the only references
to a goroutine: the publishing of the goroutine in allg comes first.
Goroutine pointers are also kept in non-GC-visible places like TLS,
so I can't see them ever moving. If we did want to start moving data
in the GC, we'd need to allocate the goroutine structs from an
alternate arena. This CL doesn't make that problem any worse.
Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I85f91312ec3e0ef69ead0fff1a560b0cfb095e1a
Reviewed-on: https://go-review.googlesource.com/2065
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Ic8624401d7c8225a935f719f96f2675c6f5c0d7c
Reviewed-on: https://go-review.googlesource.com/2064
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This is the detection code. It works well enough that I know of
a handful of missing write barriers. However, those are subtle
enough that I'll address them in separate followup CLs.
GODEBUG=wbshadow=1 checks for a write that bypassed the
write barrier at the next write barrier of the same word.
If a bug can be detected in this mode it is typically easy to
understand, since the crash says quite clearly what kind of
word has missed a write barrier.
GODEBUG=wbshadow=2 adds a check of the write barrier
shadow copy during garbage collection. Bugs detected at
garbage collection can be difficult to understand, because
there is no context for what the found word means.
Typically you have to reproduce the problem with allocfreetrace=1
in order to understand the type of the badly updated word.
Change-Id: If863837308e7c50d96b5bdc7d65af4969bf53a6e
Reviewed-on: https://go-review.googlesource.com/2061
Reviewed-by: Austin Clements <austin@google.com>
When constants were declared using unexported constants,
the type information was lost when those constants were filtered out.
This CL propagates the type information of unexported constants
so that it is available for display.
This is a follow-up to CL 144110044, which fixed this problem
specifically for _ constants.
Updates #5397.
Change-Id: I3f0c767a4007d88169a5634ab2870deea4e6a740
Reviewed-on: https://go-review.googlesource.com/2091
Reviewed-by: Robert Griesemer <gri@golang.org>
Noticed while investigating the speed of the runtime tests, as part
of debugging while Plan 9's runtime tests are timing out on GCE.
Change-Id: I95f5a3d967a0b45ec1ebf10067e193f51db84e26
Reviewed-on: https://go-review.googlesource.com/2283
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts commit ab0535ae3f.
I think it will remain useful to distinguish code that must
run on a system stack from code that can run on either stack,
even if that distinction is no
longer based on the implementation language.
That is, I expect to add a //go:systemstack comment that,
in terms of the old implementation, tells the compiler,
to pretend this function was written in C.
Change-Id: I33d2ebb2f99ae12496484c6ec8ed07233d693275
Reviewed-on: https://go-review.googlesource.com/2275
Reviewed-by: Russ Cox <rsc@golang.org>
This CL splits the (ever growing) list of ca cert locations by major unix
platforms (darwin, windows and plan9 are already handled seperately).
Although it is clear the unix variants cannot manage to agree on some standard
locations, we can avoid to some extent an artificial ranking of priority
amongst the supported GOOSs.
* Split certFiles definition by GOOS
* Include NetBSD ca cert location
Fixes#9285
Change-Id: I6df2a3fddf3866e71033e01fce43c31e51b48a9e
Reviewed-on: https://go-review.googlesource.com/2208
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This ensures that changing an image.YCbCr's Y values can't change its
chroma values, even after re-slicing up to capacity.
Change-Id: Icb626561522e336a3220e10f456c95330ae7db9e
Reviewed-on: https://go-review.googlesource.com/2209
Reviewed-by: Rob Pike <r@golang.org>
Previously, we ended up passing two compiled objects for the package
being tested when linking the test executable. Somewhat by luck, this
worked most of the time but occasionally it did not. This changes the
linking code to not pass two objects for the same ImportPath and to
always pass the object for the test version of the package and removes
some unecessary nil checks.
Change-Id: I7bbd3fc708f14672ee2cc6aed3397421fceb8a38
Reviewed-on: https://go-review.googlesource.com/1840
Reviewed-by: Ian Lance Taylor <iant@golang.org>
liblink used to encode both SETEQ BP and SETEQ CH as 0f 94 c5,
however, SETEQ BP should have used a REX prefix.
Fixes#8545.
Change-Id: Ie59c990cdd0ec506cffe4318e9ad1b48db5e57dd
Reviewed-on: https://go-review.googlesource.com/2270
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This CL adds missing ipv4-mapped ipv6 address test cases to TestParseIP.
Change-Id: I3144d2a88d409bd515cf52f8711d407bfa81ed68
Reviewed-on: https://go-review.googlesource.com/2205
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shell out to `uname -r` this time, so that the test will compile
even if the platform doesn't have syscall.Sysctl.
Change-Id: I3a19ab5d820bdb94586a97f4507b3837d7040525
Reviewed-on: https://go-review.googlesource.com/2271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test program requires static constructor, which in turn needs
external linking to work, but external linking never works on 10.6.
This should fix the darwin-{386,amd64} builders.
Change-Id: I714fdd3e35f9a7e5f5659cf26367feec9412444f
Reviewed-on: https://go-review.googlesource.com/2235
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the user provided a key but no value via -ldflag -X,
another linker flag was used as the value.
Placing the user's flags at the end avoids this problem.
It also provides the user the opportunity to
override existing linker flags.
Fixes#8810.
Change-Id: I96f4190713dc9a9c29142e56658446fba7fb6bc8
Reviewed-on: https://go-review.googlesource.com/2242
Reviewed-by: Minux Ma <minux@golang.org>
Remove use of itod on posix systems and replace with call to itoa.
Build and use same itoa function on all systems.
Fix infinite recursion in iota function for the case -1<<63.
Change-Id: I89d7e742383c5c4aeef8780501c78a3e1af87a6f
Reviewed-on: https://go-review.googlesource.com/2213
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Updated the issue tracker link the compiler prints out
when asking for a bug report after an internal error.
Change-Id: I092b118130f131c6344d9d058bea4ad6379032b8
Reviewed-on: https://go-review.googlesource.com/2218
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Preventing returning io.EOF on non-connection oriented sockets is
already applied to Unix variants. This CL applies it to Windows.
Update #4856.
Change-Id: I82071d40f617e2962d0540b9d1d6a10ea4cdb2ec
Reviewed-on: https://go-review.googlesource.com/2203
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
There is no reason to have the redundant test case TestDNSThreadLimt
because TestLookupIPDeadline does cover what we need to test with
-dnsflood flag and more.
Also this CL moves TestLookupIPDeadline into lookup_test.go to avoid
abusing to control the order of test case execution by using file name.
Change-Id: Ib417d7d3411c59d9352c03c996704d584368dc62
Reviewed-on: https://go-review.googlesource.com/2204
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes build on plan9 and windows.
Change-Id: Ic9b02c641ab84e4f6d8149de71b9eb495e3343b2
Reviewed-on: https://go-review.googlesource.com/2233
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
I missed this one in golang.org/cl/2232 and only tested the patch
on openbsd/amd64.
Change-Id: I4ff437ae0bfc61c989896c01904b6d33f9bdf0ec
Reviewed-on: https://go-review.googlesource.com/2234
Reviewed-by: Minux Ma <minux@golang.org>
This is a genuine bug exposed by our test for issue 9456: our wrapper
for pthread_create is not initialized until we initialize cgo itself,
but it is possible that a static constructor could call pthread_create,
and in that case, it will be calling a nil function pointer.
Fix that by also initializing the sys_pthread_create function pointer
inside our pthread_create wrapper function, and use a pthread_once to
make sure it is only initialized once.
Fix build for openbsd.
Change-Id: Ica4da2c21fcaec186fdd3379128ef46f0e767ed7
Reviewed-on: https://go-review.googlesource.com/2232
Reviewed-by: David Crawshaw <crawshaw@golang.org>
%lL will prepend the current directory to the filename, which is not
what we want here (as the file name is already absolute).
Fixes#9150.
Change-Id: I4c9386be6baf421393b92d9401a264b4692986d0
Reviewed-on: https://go-review.googlesource.com/2231
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some libraries, for example, OpenBLAS, create work threads in a global constructor.
If we're doing cpu profiling, it's possible that SIGPROF might come to some of the
worker threads before we make our first cgo call. Cgocallback used to terminate the
process when that happens, but it's better to miss a couple profiling signals than
to abort in this case.
Fixes#9456.
Change-Id: I112b8e1a6e10e6cc8ac695a4b518c0f577309b6b
Reviewed-on: https://go-review.googlesource.com/2141
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Avoid the decimal lookup in digits array and compute the decimal character value directly.
Reduce calls to 64bit division on 32bit plattforms by splitting conversion into smaller blocks.
Convert value to uintptr type when it can be represented by uintptr.
on darwin/386
benchmark old ns/op new ns/op delta
BenchmarkFormatInt 8352 7466 -10.61%
BenchmarkAppendInt 4281 3401 -20.56%
BenchmarkFormatUint 2785 2251 -19.17%
BenchmarkAppendUint 1770 1223 -30.90%
on darwin/amd64
benchmark old ns/op new ns/op delta
BenchmarkFormatInt 5531 5492 -0.71%
BenchmarkAppendInt 2435 2295 -5.75%
BenchmarkFormatUint 1628 1569 -3.62%
BenchmarkAppendUint 726 750 +3.31%
Change-Id: Ifca281cbdd62ab7d7bd4b077a96da99eb12cf209
Reviewed-on: https://go-review.googlesource.com/2105
Reviewed-by: Robert Griesemer <gri@golang.org>
We already had client support for trailers, but no way for a server to
set them short of hijacking the connection.
Fixes#7759
Change-Id: Ic83976437739ec6c1acad5f209ed45e501dbb93a
Reviewed-on: https://go-review.googlesource.com/2157
Reviewed-by: Andrew Gerrand <adg@golang.org>
Following change 2154, the goatoi function
was renamed atoi.
However, this definition conflicts with the
atoi function defined in the Plan 9 runtime,
which takes a []byte instead of a string.
This change fixes the build on Plan 9.
Change-Id: Ia0f7ca2f965bd5e3cce3177bba9c806f64db05eb
Reviewed-on: https://go-review.googlesource.com/2165
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
They are no longer needed now that C is gone.
goatoi -> atoi
gofuncname/funcname -> funcname/cfuncname
goroundupsize -> already existing roundupsize
Change-Id: I278bc33d279e1fdc5e8a2a04e961c4c1573b28c7
Reviewed-on: https://go-review.googlesource.com/2154
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Now that we've removed all the C code in runtime and the C compilers,
there is no need to have a separate stackguard field to check for C
code on Go stack.
Remove field g.stackguard1 and rename g.stackguard0 to g.stackguard.
Adjust liblink and cmd/ld as necessary.
Change-Id: I54e75db5a93d783e86af5ff1a6cd497d669d8d33
Reviewed-on: https://go-review.googlesource.com/2144
Reviewed-by: Keith Randall <khr@golang.org>
Use Fatalf for formatting directive rather than plain Fatal.
Change-Id: Iebd30cd6326890e9501746113a6d97480949e3d2
Reviewed-on: https://go-review.googlesource.com/2161
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The goalg function was a holdover from when we had algorithm
tables in both C and Go. It is no longer needed.
Change-Id: Ia0c1af35bef3497a899f22084a1a7b42daae72a0
Reviewed-on: https://go-review.googlesource.com/2099
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The error message for decoding a unquoted value into a struct field with
the ,string option specified has two arguments when one is needed.
Make the error message take one argument and add a test in order to cover
the case when a unquoted value is specified.
Also add error value as the missing argument for Fatalf call in test.
Fixes the following go vet reports:
decode.go:602: wrong number of args for format in Errorf call: 1 needed but 2 args
decode_test.go:1088: missing argument for Fatalf("%v"): format reads arg 1, have only 0 args
Change-Id: Id036e10c54c4a7c1ee9952f6910858ecc2b84134
Reviewed-on: https://go-review.googlesource.com/2109
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Use log.Fatalf for formatting directives instead of log.Fatal
Change-Id: Ia207b320f5795c63cdfa71f92c19ca6d05cc833f
Reviewed-on: https://go-review.googlesource.com/2160
Reviewed-by: Minux Ma <minux@golang.org>
Rename "gothrow" to "throw" now that the C version of "throw"
is no longer needed.
This change is purely mechanical except in panic.go where the
old version of "throw" has been deleted.
sed -i "" 's/[[:<:]]gothrow[[:>:]]/throw/g' runtime/*.go
Change-Id: Icf0752299c35958b92870a97111c67bcd9159dc3
Reviewed-on: https://go-review.googlesource.com/2150
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
The new test case produces the longest string representation possible and thereby uses
all of the 65 bytes in the buffer array used by the formatBits function.
Change-Id: I11320c4de56ced5ff098b7e37f1be08e456573e2
Reviewed-on: https://go-review.googlesource.com/2108
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Specify what will happen if len(dst) != len(src).
Change-Id: I66afa3730f637753b825189687418f14ddec3629
Reviewed-on: https://go-review.googlesource.com/1754
Reviewed-by: Adam Langley <agl@golang.org>
Currently we do very a complex rebalancing of runnable goroutines
between queues, which tries to preserve scheduling fairness.
Besides being complex and error-prone, it also destroys all locality
of scheduling.
This change uses simpler scheme: leave runnable goroutines where
they are, during starttheworld start all Ps with local work,
plus start one additional P in case we have excessive runnable
goroutines in local queues or in the global queue.
The schedler must be able to operate efficiently w/o the rebalancing,
because garbage collections do not have to happen frequently.
The immediate need is execution tracing support: handling of
garabage collection which does stoptheworld/starttheworld several
times becomes exceedingly complex if the current execution can
jump between Ps during starttheworld.
Change-Id: I4fdb7a6d80ca4bd08900d0c6a0a252a95b1a2c90
Reviewed-on: https://go-review.googlesource.com/1951
Reviewed-by: Rick Hudson <rlh@golang.org>
