- 15 Apr, 2014 7 commits
-
-
Russ Cox authored
Fixes #7719. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/87760050
-
Russ Cox authored
When I did the original 386 ports on Linux and OS X, I chose to define GS-relative expressions like 4(GS) as relative to the actual thread-local storage base, which was usually GS but might not be (it might be FS, or it might be a different constant offset from GS or FS). The original scope was limited but since then the rewrites have gotten out of control. Sometimes GS is rewritten, sometimes FS. Some ports do other rewrites to enable shared libraries and other linking. At no point in the code is it clear whether you are looking at the real GS/FS or some synthesized thing that will be rewritten. The code manipulating all these is duplicated in many places. The first step to fixing issue 7719 is to make the code intelligible again. This CL adds an explicit TLS pseudo-register to the 386 and amd64. As a register, TLS refers to the thread-local storage base, and it can only be loaded into another register: MOVQ TLS, AX An offset from the thread-local storage base is written off(reg)(TLS*1). Semantically it is off(reg), but the (TLS*1) annotation marks this as indexing from the loaded TLS base. This emits a relocation so that if the linker needs to adjust the offset, it can. For example: MOVQ TLS, AX MOVQ 8(AX)(TLS*1), CX // load m into CX On systems that support direct access to the TLS memory, this pair of instructions can be reduced to a direct TLS memory reference: MOVQ 8(TLS), CX // load m into CX The 2-instruction and 1-instruction forms correspond roughly to ELF TLS initial exec mode and ELF TLS local exec mode, respectively. Liblink applies this rewrite on systems that support the 1-instruction form. The decision is made using only the operating system (and probably the -shared flag, eventually), not the link mode. If some link modes on a particular operating system require the 2-instruction form, then all builds for that operating system will use the 2-instruction form, so that the link mode decision can be delayed to link time. Obviously it is late to be making changes like this, but I despair of correcting issue 7719 and issue 7164 without it. To make sure I am not changing existing behavior, I built a "hello world" program for every GOOS/GOARCH combination we have and then worked to make sure that the rewrite generates exactly the same binaries, byte for byte. There are a handful of TODOs in the code marking kludges to get the byte-for-byte property, but at least now I can explain exactly how each binary is handled. The targets I tested this way are: darwin-386 darwin-amd64 dragonfly-386 dragonfly-amd64 freebsd-386 freebsd-amd64 freebsd-arm linux-386 linux-amd64 linux-arm nacl-386 nacl-amd64p32 netbsd-386 netbsd-amd64 openbsd-386 openbsd-amd64 plan9-386 plan9-amd64 solaris-amd64 windows-386 windows-amd64 There were four exceptions to the byte-for-byte goal: windows-386 and windows-amd64 have a time stamp at bytes 137 and 138 of the header. darwin-386 and plan9-386 have five or six modified bytes in the middle of the Go symbol table, caused by editing comments in runtime/sys_{darwin,plan9}_386.s. Fixes #7164. LGTM=iant R=iant, aram, minux.ma, dave CC=golang-codereviews https://golang.org/cl/87920043
-
Rob Pike authored
It was said already but apparently not enough times. Fixes #6985. LGTM=crawshaw R=golang-codereviews, crawshaw CC=golang-codereviews https://golang.org/cl/86300043
-
Dmitriy Vyukov authored
Do not consider idle finalizer/bgsweep/timer goroutines as doing something useful. We can't simply set isbackground for the whole lifetime of the goroutines, because when finalizer goroutine calls user function, we do want to consider it as doing something useful. This is borken due to timers for quite some time. With background sweep is become even more broken. Fixes #7784. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/87960044
-
Jan Ziak authored
Fixes #6559 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/81330045
-
Brad Fitzpatrick authored
TLS handshake failures didn't use to log, but do in Go 1.3. Shut it up so the actual failure can be seen in e.g. http://build.golang.org/log/ede7e12362a941d93bf1fe21db9208a3e298029e LGTM=adg R=adg CC=golang-codereviews https://golang.org/cl/87870043
-
Andrew Gerrand authored
This breaks "go get -d repo/path/...". ««« original CL description cmd/go: do not miss an error if import path contains "cmd/something" Fixes #7638 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/87300043 »»» LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/87890043
-
- 14 Apr, 2014 20 commits
-
-
Brad Fitzpatrick authored
Per TODO email in my inbox. LGTM=rsc R=golang-codereviews, rsc CC=adg, dsymonds, golang-codereviews, r https://golang.org/cl/87550045
-
Brad Fitzpatrick authored
LGTM=r R=rsc, r CC=golang-codereviews https://golang.org/cl/87750043
-
Adam Langley authored
Windows is building a chain to the AddTrust root which is different from the native Go code and causing a build failure. This change alters the test so that both should build to the AddTrust root. R=bradfitz LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/87570044
-
Andrew Szeto authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/87460043
-
Jan Ziak authored
Fixes #7638 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/87300043
-
Brad Fitzpatrick authored
Generated by addca. R=gobot CC=golang-codereviews https://golang.org/cl/86960046
-
Russ Cox authored
The relocation and automatic variable types were using arch-specific numbers. Introduce portable enumerations instead. To the best of my knowledge, these are the only arch-specific bits left in the new object file format. Remove now, before Go 1.3, because file formats are forever. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/87670044
-
Adam Langley authored
Comodo are now using a SHA-384 signed intermediate. The crypto/x509 package seeks to import hash functions needed for typical operation without needing to import every hash function possible. Since a SHA-384 certificate is being used by Comodo, crypto/sha512 now appears to fall into the scope of "typical operation". R=bradfitz LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/87670045
-
Brad Fitzpatrick authored
Update #7264 Races: http://build.golang.org/log/a2e401fdcd4903a61a3375bff5da702a20ddafad http://build.golang.org/log/ec4c69e92076a747ac6d5df7eb7b382b31ab3d43 I think this is the first time I've actually seen a manifestation of Issue 7264, and one that I can reproduce. I don't know why it triggers on this test and not any others just like it, or why I can't reproduce Issue 7264 independently, even when Dmitry gives me minimal repros. Work around it for now with some synchronization to make the race detector happy. The proper fix will probably be in net/http/httptest itself, not in all hundred some tests. LGTM=rsc R=rsc CC=dvyukov, golang-codereviews https://golang.org/cl/87640043
-
Ian Lance Taylor authored
Generated by addca. R=gobot CC=golang-codereviews https://golang.org/cl/87650044
-
Russ Cox authored
There are changes we know we want to make, but not before Go 1.3 Add a version number so that we can make them more easily later. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/87670043
-
Brad Fitzpatrick authored
LGTM=rsc R=rsc, r CC=golang-codereviews https://golang.org/cl/87620043
-
Dmitriy Vyukov authored
Currently Pool can cache up to 15 elements per P, and these elements are not accesible to other Ps. If a Pool caches large objects, say 2MB, and GOMAXPROCS is set to a large value, say 32, then the Pool can waste up to 960MB. The new caching policy caches at most 1 per-P element, the rest is shared between Ps. Get/Put performance is unchanged. Nested Get/Put performance is 57% worse. However, overall scalability of nested Get/Put is significantly improved, so the new policy starts winning under contention. benchmark old ns/op new ns/op delta BenchmarkPool 27.4 26.7 -2.55% BenchmarkPool-4 6.63 6.59 -0.60% BenchmarkPool-16 1.98 1.87 -5.56% BenchmarkPool-64 1.93 1.86 -3.63% BenchmarkPoolOverlflow 3970 6235 +57.05% BenchmarkPoolOverlflow-4 10935 1668 -84.75% BenchmarkPoolOverlflow-16 13419 520 -96.12% BenchmarkPoolOverlflow-64 10295 380 -96.31% LGTM=rsc R=rsc CC=golang-codereviews, khr https://golang.org/cl/86020043
-
Ian Lance Taylor authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/87140044
-
Russ Cox authored
These are not ready and will not be in Go 1.3. Fixes #6932. LGTM=bradfitz R=golang-codereviews, bradfitz, minux.ma CC=golang-codereviews, iant, r https://golang.org/cl/87630043
-
Russ Cox authored
We have never released cmd/prof and don't plan to. Now that nm, addr2line, and objdump have been rewritten in Go, cmd/prof is the only thing keeping us from deleting libmach. Delete cmd/prof, and then since nothing is using libmach, delete libmach. 13,000 lines of C deleted. LGTM=minux.ma R=golang-codereviews, minux.ma CC=golang-codereviews, iant, r https://golang.org/cl/87020044
-
Brad Fitzpatrick authored
Fixes #6981 LGTM=rsc R=golang-codereviews, nightlyone CC=adg, dsymonds, golang-codereviews, rsc https://golang.org/cl/85560045
-
Russ Cox authored
Update cmd/dist not to build the C version. Update cmd/go to install the Go version to the tool directory. Update #7452 This is the basic logic needed for objdump, and it works well enough to support the pprof list and weblist commands. A real disassembler needs to be added in order to support the pprof disasm command and the per-line assembly displays in weblist. That's still to come. Probably objdump will move to go.tools when the disassembler is added, but it can stay here for now. LGTM=minux.ma R=golang-codereviews, minux.ma CC=golang-codereviews, iant, r https://golang.org/cl/87580043
-
Russ Cox authored
Broke other things - see issue 7522. Fixes #7522. Reopens issue 7363. ««« original CL description cmd/gc: make embedded, unexported fields read-only. Fixes #7363. LGTM=gri R=gri, rsc, bradfitz CC=golang-codereviews https://golang.org/cl/66510044 »»» LGTM=r, mpvl R=golang-codereviews, r CC=golang-codereviews, iant, mpvl https://golang.org/cl/85580046
-
Russ Cox authored
It looks like maybe on slower builders 4 seconds is not enough. Trying to get rid of the flaky failures. TBR=iant CC=golang-codereviews https://golang.org/cl/86870044
-
- 12 Apr, 2014 1 commit
-
-
Rob Pike authored
LGTM=alex.brainman R=alex.brainman CC=golang-codereviews https://golang.org/cl/87250043
-
- 11 Apr, 2014 12 commits
-
-
Adam Langley authored
R=adg LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/86930043
-
Brad Fitzpatrick authored
What was happening on Issue 7010 was handler intentionally took 30 milliseconds and the proxy's client timeout was 35 milliseconds. Then it slammed the proxy with a bunch of requests. Sometimes the server would be too slow to respond in its 5 millisecond window and the client code would cancel the request, force-closing the persistConn. If this came at the right time, the server's reply was already in flight, and one of the goroutines would report: Unsolicited response received on idle HTTP channel starting with "H"; err=<nil> ... rightfully scaring the user. But the error was already handled and returned to the user, and this connection knows it's been shut down. So look at the closed flag after acquiring the same mutex guarding another field we were checking, and don't complain if it's a known shutdown. Also move closed down below the mutex which guards it. Fixes #7010 LGTM=dsymonds R=golang-codereviews, dsymonds CC=adg, golang-codereviews, rsc https://golang.org/cl/86740044
-
Jan Ziak authored
Fixes #7129 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/86470044
-
Jan Ziak authored
Fixes #7742 LGTM=dave, rsc R=rsc, bradfitz, dave CC=golang-codereviews https://golang.org/cl/85580047
-
Dmitriy Vyukov authored
The test fails now with -race, so it's disabled. The intention is that the fix for issue 7264 will also modify this test the same way and enable it. Reporduce with 'go test -race -issue7264 -cpu=4'. Update #7264 LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/86770043
-
Alex Brainman authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/84650047
-
Matthew Cottingham authored
Add test for multipart form requests with an invalid content-type to ensure ErrNotMultipart is returned. Change ParseMultipartForm to return ErrNotMultipart when it is returned by multipartReader. Modify test for empty multipart request handling to use POST so that the body is checked. Fixes #6334. This is the first changeset working on multipart request handling. Further changesets could add more tests and clean up the TODO. LGTM=bradfitz R=golang-codereviews, gobot, bradfitz, rsc CC=golang-codereviews https://golang.org/cl/44040043
-
Brad Fitzpatrick authored
I was implementing rules from RFC 2616. The rules are apparently useless, ambiguous, and too strict for common software on the Internet. (e.g. curl) Add more tests, including a test of a chunked request. Fixes #7625 LGTM=dsymonds R=golang-codereviews, dsymonds CC=adg, golang-codereviews, rsc https://golang.org/cl/84480045
-
Rui Ueyama authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/86420046
-
Robert Griesemer authored
Also: Simplify ReadSlice implementation and ensure that it doesn't call fill() with a full buffer (this caused a failure in net/textproto TestLargeReadMIMEHeader because fill() wasn't able to read more data). Fixes #7745. LGTM=bradfitz R=r, bradfitz CC=golang-codereviews https://golang.org/cl/86590043
-
Robert Griesemer authored
LGTM=bradfitz R=bradfitz CC=golang-codereviews https://golang.org/cl/86060044
-
Rui Ueyama authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/86600045
-