- 30 Aug, 2015 6 commits
-
-
Shenghou Ma authored
Fixes external linking of net/http tests (or anything that uses sendfile). Fixes #12390. Change-Id: Iee08998cf66e7b0ce851db138a00ebae6dc2395e Reviewed-on: https://go-review.googlesource.com/14072Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
Aram Hăvărneanu <aram@mgk.ro>
-
Austin Clements authored
Currently the stack barrier stub blindly unwinds the next stack barrier from the G's stack barrier array without checking that it's the right stack barrier. If through some bug the stack barrier array position gets out of sync with where we actually are on the stack, this could return to the wrong PC, which would lead to difficult to debug crashes. To address this, this commit adds a check to the amd64 stack barrier stub that it's unwinding the correct stack barrier. Updates #12238. Change-Id: If824d95191d07e2512dc5dba0d9978cfd9f54e02 Reviewed-on: https://go-review.googlesource.com/13948Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently enabling the debugging mode where stack barriers are installed at every frame requires recompiling the runtime. However, this is potentially useful for field debugging and for runtime tests, so make this mode a GODEBUG. Updates #12238. Change-Id: I6fb128f598b19568ae723a612e099c0ed96917f5 Reviewed-on: https://go-review.googlesource.com/13947Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently the runtime can install stack barriers in any frame. However, the frame of cgocallback_gofunc is special: it's the one function that switches from a regular G stack to the system stack on return. Hence, the return PC slot in its frame on the G stack is actually used to save getg().sched.pc (so tracebacks appear to unwind to the last Go function running on that G), and not as an actual return PC for cgocallback_gofunc. Because of this, if we install a stack barrier in cgocallback_gofunc's return PC slot, when cgocallback_gofunc does return, it will move the stack barrier stub PC in to getg().sched.pc and switch back to the system stack. The rest of the runtime doesn't know how to deal with a stack barrier stub in sched.pc: nothing knows how to match it up with the G's stack barrier array and, when the runtime removes stack barriers, it doesn't know to undo the one in sched.pc. Hence, if the C code later returns back in to Go code, it will attempt to return through the stack barrier saved in sched.pc, which may no longer have correct unwinding information. Fix this by blacklisting cgocallback_gofunc's frame so the runtime won't install a stack barrier in it's return PC slot. Fixes #12238. Change-Id: I46aa2155df2fd050dd50de3434b62987dc4947b8 Reviewed-on: https://go-review.googlesource.com/13944Reviewed-by:
Russ Cox <rsc@golang.org>
-
Adam Langley authored
(See referenced bug for details.) Fixes #11966. Change-Id: I91f9c95594cf4fd6d25d9a81f155a643c7a1f8e0 Reviewed-on: https://go-review.googlesource.com/13038Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Adam Langley authored
https://tools.ietf.org/html/rfc7301#section-3.1 specifies that a ProtocolName may not be empty. This change enforces this for ServerHello messages—it's already enforced for ClientHello messages. Change-Id: Ic5a5be6bebf07fba90a3cabd10b07ab7b4337f53 Reviewed-on: https://go-review.googlesource.com/12003Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 29 Aug, 2015 9 commits
-
-
aubble authored
In Go 1.5, Config.Certificates is no longer required if Config.GetCertificate has been set. This change updated four comments to reflect that. Change-Id: Id72cc22fc79e931b2d645a7c3960c3241042762c Reviewed-on: https://go-review.googlesource.com/13800Reviewed-by:
Adam Langley <agl@golang.org>
-
Vlad Krasnov authored
The existing implementation didn't use the CLMUL instructions for fast and constant time binary-field multiplication. With this change, amd64 CPUs that support both AES and CLMUL instructions will use an optimised asm implementation. benchmark old ns/op new ns/op delta BenchmarkAESGCMSeal8K 91723 3200 -96.51% BenchmarkAESGCMOpen8K 91487 3324 -96.37% BenchmarkAESGCMSeal1K 11873 546 -95.40% BenchmarkAESGCMOpen1K 11833 594 -94.98% benchmark old MB/s new MB/s speedup BenchmarkAESGCMSeal8K 89.31 2559.62 28.66x BenchmarkAESGCMOpen8K 89.54 2463.78 27.52x BenchmarkAESGCMSeal1K 86.24 1872.49 21.71x BenchmarkAESGCMOpen1K 86.53 1721.78 19.90x Change-Id: Idd63233098356d8b353d16624747b74d0c3f193e Reviewed-on: https://go-review.googlesource.com/10484 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Adam Langley <agl@golang.org>
-
aubble authored
Go 1.5 allowed TLS connections where Config.Certificates was nil as long as the GetCertificate callback was given. However, tls.Listen wasn't updated accordingly until this change. Change-Id: I5f67f323f63c988ff79642f3daf8a6b2a153e6b2 Reviewed-on: https://go-review.googlesource.com/13801Reviewed-by:
Adam Langley <agl@golang.org>
-
Håvard Haugen authored
Recursive types R containing slices of R's did not terminate despite the effort in CL 10821. For recursive types there was a competition between slice expansion by a factor 'complexSize', and termination with probability '1/complexSize' which lead to stack overflow as soon as a recursive struct had slices pointing to its own type. Fix this by shrinking the size hint as a function of recursion depth. This has the dual effect of reducing the number of elements generated per slice and also increasing the probability for termination. Fixes #11148. Change-Id: Ib61155b4f2e2de3873d508d63a1f4be759426d67 Reviewed-on: https://go-review.googlesource.com/13830Reviewed-by:
Adam Langley <agl@golang.org>
-
David Leon Gil authored
For primes which are 3 mod 4, using Tonelli-Shanks is slower and more complicated than using the identity a**((p+1)/4) mod p == sqrt(a) For 2^450-2^225-1 and 2^10860-2^5430-1, which are 3 mod 4: BenchmarkModSqrt225_TonelliTri 1000 1135375 ns/op BenchmarkModSqrt225_3Mod4 10000 156009 ns/op BenchmarkModSqrt5430_Tonelli 1 3448851386 ns/op BenchmarkModSqrt5430_3Mod4 2 914616710 ns/op ~2.6x to 7x faster. Fixes #11437 (which is a prime choice of issues to fix) Change-Id: I813fb29454160483ec29825469e0370d517850c2 Reviewed-on: https://go-review.googlesource.com/11522Reviewed-by:
Adam Langley <agl@golang.org>
-
Michal Bohuslávek authored
Fixes #11127. Change-Id: Ibcfc3a05e91fa4260d70b04bee2bbba2376bd313 Reviewed-on: https://go-review.googlesource.com/13923Reviewed-by:
Adam Langley <agl@golang.org>
-
Keith Randall authored
Should only matter on ppc64 and ppc64le. Fixes #11336 Change-Id: Id4b0ac28b573648e1aa98e87bf010f00d006b146 Reviewed-on: https://go-review.googlesource.com/13901Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Ian Lance Taylor authored
Change-Id: I33c2c222ea884d9ff57800ea5185644b5d8e591a Reviewed-on: https://go-review.googlesource.com/14034Reviewed-by:
Minux Ma <minux@golang.org>
-
Dave Cheney authored
Update testzip.proto to reflect vendoring of golang.org/x/arch. Change-Id: I532da1100f74d1e9887eb3cf26974660ae818d92 Reviewed-on: https://go-review.googlesource.com/14007Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 28 Aug, 2015 12 commits
-
-
Robert Griesemer authored
Change-Id: Ib79ab787fdc90a5a29b25474d91afa9bfaf51276 Reviewed-on: https://go-review.googlesource.com/13589Reviewed-by:
Minux Ma <minux@golang.org>
-
Robert Griesemer authored
Val.Ctype used to be struct field, it's now a method. Change-Id: I08f0b32b66dba15b2a392e84a557efb905b530cb Reviewed-on: https://go-review.googlesource.com/14031Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
Fixes #12361. Change-Id: Ifd62e8d93b2d733e67e0186c7185cd6291d3bbc1 Reviewed-on: https://go-review.googlesource.com/13939Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
The code is now in cmd/vendor/golang.org/x/arch. Change-Id: I518d48c21b0d7fed914552b89ee41411f088456b Reviewed-on: https://go-review.googlesource.com/14021Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Change-Id: I5348774ff01a5f0f706a1dba4aa9500661841f47 Reviewed-on: https://go-review.googlesource.com/14020Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
For use by cmd/objdump in place of the current cmd/internal/rsc.io/... tree. Change-Id: I7d765ddf43ab4118a3221fd755ff0a2a02daa5de Reviewed-on: https://go-review.googlesource.com/13979Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Right now we find out implicitly if stack barriers are in place, or defers. This change makes sure we find out about short unwinds always. Change-Id: Ibdde1ba9c79eb792660dcb7aa6f186e4e4d559b3 Reviewed-on: https://go-review.googlesource.com/13966Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Change-Id: I34eff138c61e5ad456a4918c402ca0e8333601a0 Reviewed-on: https://go-review.googlesource.com/13978Reviewed-by:
Russ Cox <rsc@golang.org>
-
Dave Cheney authored
Start go1.6.txt with a note that nacl ports are no longer restricted to pepper_41 and a record of the text/template change. Change-Id: I21dda64aec113c35caf1d565f29e3aac8171480a Reviewed-on: https://go-review.googlesource.com/14004Reviewed-by:
Rob Pike <r@golang.org>
-
Daniel Johansson authored
GetMUIStringValue tries as a convenience to resolve string values even for pathless resource DLLs by searching the system directory (one of several paths used by the system's standard DLL search order algorithm). This would not be needed if regLoadMUIString searched for pathless DLLs itself, but it doesn't, instead it needs an absolute path, otherwise it will fail. This approach works fine for solving issue #12015 (handle localized time zone names; for which GetMUIStringValue was created) since tzres.dll that is used to resolve localized time zone names has no path in the registry but is located under the system directory. However, this approach will fail if a pathless DLL is located somewhere else than the system directory. Because of this limitation GetMUIStringValue may have to be revised in the future to allow for custom paths, possibly through another version of the function. See also: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724890%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx Change-Id: Ida66a0ef1928e0461ce248c795827902d785e6cd Reviewed-on: https://go-review.googlesource.com/13929Reviewed-by:
Rob Pike <r@golang.org>
-
Dave Cheney authored
Fixes #11961 Minux removed the use of SRPC in 003dccfa, but the SRPC name service code was left in the tree. SRPC was removed in pepper_42 making the code, which ran on startup, fail, even though it was not used. Removing srpc_nacl.go for a total diff of -822 lines has got to count as one of the easiest nacl fixes we've had to date. Change-Id: Ic4e348146bfe47450bbb9cabb91699ba153e6bf0 Reviewed-on: https://go-review.googlesource.com/13958Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Minux Ma <minux@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alberto Donizetti authored
Issue 6754 reports that Go bzip2 Decode function is much slower (about 2.5x in go1.5) than the Python equivalent (which is actually just a wrapper around the usual C library) on random data. Profiling the code shows that half a dozen of CMP instructions in a tight loop are responsibile for most of the execution time. This patch reduces the number of branches of the loop, greatly improving performance on random data and speeding up decoding of real data. name old time/op new time/op delta DecodeDigits-4 9.28ms ± 1% 8.05ms ± 1% -13.18% (p=0.000 n=15+14) DecodeTwain-4 28.9ms ± 2% 26.4ms ± 1% -8.57% (p=0.000 n=15+14) DecodeRand-4 3.94ms ± 1% 3.06ms ± 1% -22.45% (p=0.000 n=15+14) name old speed new speed delta DecodeDigits-4 4.65MB/s ± 1% 5.36MB/s ± 1% +15.21% (p=0.000 n=13+14) DecodeTwain-4 4.32MB/s ± 2% 4.72MB/s ± 1% +9.36% (p=0.000 n=15+14) DecodeRand-4 4.27MB/s ± 1% 5.51MB/s ± 1% +28.86% (p=0.000 n=15+14) I've run some benchmark comparing Go bzip2 implementation with the usual Linux bzip2 command (which is written in C). On my machine this patch brings go1.5 from ~2.26x to ~1.50x of bzip2 time (on 64MB random data) from ~1.70x to ~1.50x of bzip2 time (on 100MB english text) from ~2.00x to ~1.88x of bzip2 time (on 64MB /dev/zero data) Fixes #6754 Change-Id: I3cb12d2c0c2243c1617edef1edc88f05f91d26d1 Reviewed-on: https://go-review.googlesource.com/13853Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
- 27 Aug, 2015 9 commits
-
-
Ian Lance Taylor authored
This changed in https://golang.org/cl/10761. Update #12203. Change-Id: Ia37ebb7ecba689ad3cb2559213d675f21cf03a95 Reviewed-on: https://go-review.googlesource.com/13799Reviewed-by:
Russ Cox <rsc@golang.org>
-
Russ Cox authored
If we're going to do this for Go 1.6 we might as well do it now and find out what breaks. Change-Id: I8306b7829d8d13b564a1466c902ec6ba1a5a58c1 Reviewed-on: https://go-review.googlesource.com/13967Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
This worked in Go 1.4 but was lost in the "pure Go" lookup routines substituted late in the Go 1.5 cycle. Fixes #12263. Change-Id: I77ec9d97cd8e67ace99d6ac965e5bc16c151ba83 Reviewed-on: https://go-review.googlesource.com/13915Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Alexander Morozov authored
Setgroups with zero-length groups is no-op for changing groups and supposed to be used only for determining curent groups length. Also because we deny setgroups by default if use GidMappings we have unnecessary error from that no-op syscall. Change-Id: I8f74fbca9190a3dcbbef1d886c518e01fa05eb62 Reviewed-on: https://go-review.googlesource.com/13938Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Vincent Vanackere authored
Fixes #12232. Change-Id: Ide3fb7f5fc5ae377ae8683fbb94fd0dc01480549 Reviewed-on: https://go-review.googlesource.com/13924Reviewed-by:
Russ Cox <rsc@golang.org>
-
Tim Cooijmans authored
Change-Id: I63bf6d2fdf41b49ff8783052d5d6c53b20e2f050 Reviewed-on: https://go-review.googlesource.com/13760Reviewed-by:
David Crawshaw <crawshaw@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Didier Spezia authored
For ARM machines, the assembler supports list of registers operands such as [R1,R2]. A list missing a ']' results in the parser issuing many errors and consuming all the tokens. At EOF (i.e. end of the line), it still loops. Normally, a counter is maintained to make sure the parser stops after 10 errors. However, multiple errors occuring on the same line are simply ignored. Only the first one is reported. At most one error per line is accounted. Missing ']' in a register list therefore results in an infinite loop. Fixed the parser by explicitly checking for ']' to interrupt this loops In the operand tests, also fixed a wrong entry which I think was not set on purpose (but still led to a successful result). Fixes #11764 Change-Id: Ie87773388ee0d21b3a2a4cb941d4d911d0230ba4 Reviewed-on: https://go-review.googlesource.com/13920Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
Useful to discriminate evaluation errors from write errors. Fixes #11898. Change-Id: I907d339a3820e887872d78e0e2d8fd011451fd19 Reviewed-on: https://go-review.googlesource.com/13957Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Michael Hudson-Doyle authored
I noticed that they were unimplemented on arm64 but then that they were in fact not used at all. Change-Id: Iee579feda2a5e374fa571bcc8c89e4ef607d50f6 Reviewed-on: https://go-review.googlesource.com/13951 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 26 Aug, 2015 4 commits
-
-
Robert Griesemer authored
Fixes #11947. Change-Id: I6225f96b8dea0cecb097f9c7452a1aa80ae4476d Reviewed-on: https://go-review.googlesource.com/12939Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Brad Fitzpatrick authored
Accepting a request with a nil body was never explicitly supported but happened to work in the past. This doesn't happen in most cases because usually people pass a Server's incoming Request to the ReverseProxy's ServeHTTP method, and incoming server requests are guaranteed to have non-nil bodies. Still, it's a regression, so fix. Fixes #12344 Change-Id: Id9a5a47aea3f2875d195b66c9a5f8581c4ca2aed Reviewed-on: https://go-review.googlesource.com/13935Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Fixes #11578. Change-Id: I29a542be247127f470ba6c39aac0d0f6a18de553 Reviewed-on: https://go-review.googlesource.com/13285Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
Not needed anymore since go/types is always built against the current standard library. Fixes #11538. Change-Id: I2f07d73703f4e5661c4b5df5d487939dcf530b43 Reviewed-on: https://go-review.googlesource.com/13897Reviewed-by:
Alan Donovan <adonovan@google.com>
-