Commits · 97c19f0f721b1db634dcae6a766712533a8f1bd5 · go / golang

27 Jun, 2013 14 commits

Russ Cox authored Jun 27, 2013

The new -coverpkg flag allows computing coverage in
one set of packages while running the tests of a different set.

Also clean up some of the previous CL's recompileForTest,
using packageList to avoid the clumsy recursion.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10705043

97c19f0f

runtime: use gp->sched.sp for stack overflow check · f0d73fbc

Russ Cox authored Jun 27, 2013

On x86 it is a few words lower on the stack than m->morebuf.sp
so it is a more precise check. Enabling the check requires recording
a valid gp->sched in reflect.call too. This is a good thing in general,
since it will make stack traces during reflect.call work better, and it
may be useful for preemption too.

R=dvyukov
CC=golang-dev
https://golang.org/cl/10709043

f0d73fbc

runtime: fix goroutine status corruption · 4eb17ecd

Dmitriy Vyukov authored Jun 27, 2013

runtime.entersyscall() sets g->status = Gsyscall,
then calls runtime.lock() which causes stack split.
runtime.newstack() resets g->status to Grunning.
This will lead to crash during GC (world is not stopped) or GC will scan stack incorrectly.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10696043

4eb17ecd

crypto/tls: Change TLS version to 1.1 in the package comment. · b92b0930

Frithjof Schulze authored Jun 27, 2013

Also use 2048-bit RSA keys as default in generate_cert.go,
as recommended by the NIST.

R=golang-dev, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/10676043

b92b0930

A+C: Frithjof Schulze (individual CLA) other email · a93fbb53

Brad Fitzpatrick authored Jun 27, 2013

Generated by addca, but then manually merged
the two lines onto one.

R=gobot
CC=golang-dev
https://golang.org/cl/10701043

a93fbb53

crypto/elliptic: add constant-time, P-256 implementation. · d2a19e9f

Adam Langley authored Jun 27, 2013

On my 64-bit machine, despite being 32-bit code, fixed-base
multiplications are 7.1x faster and arbitary multiplications are 2.6x
faster.

It is difficult to review this change. However, the code is essentially
the same as code that has been open-sourced in Chromium. There it has
been successfully performing P-256 operations for several months on
many machines so the arithmetic of the code should be sound.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10551044

d2a19e9f

undo CL 9776044 / 1e280889f997 · 7ebb187e

Dmitriy Vyukov authored Jun 27, 2013

Failure on bot:
http://build.golang.org/log/f4c648906e1289ec2237c1d0880fb1a8b1852a08

««« original CL description
runtime: fix CPU underutilization
runtime.newproc/ready are deliberately sloppy about waking new M's,
they only ensure that there is at least 1 spinning M.
Currently to compensate for that, schedule() checks if the current P
has local work and there are no spinning M's, it wakes up another one.
It does not work if goroutines do not call schedule.
With this change a spinning M wakes up another M when it finds work to do.
It's also not ideal, but it fixes the underutilization.
A proper check would require to know the exact number of runnable G's,
but it's too expensive to maintain.
Fixes #5586.

R=rsc
TBR=rsc
CC=gobot, golang-dev
https://golang.org/cl/9776044
»»»

R=golang-dev
CC=golang-dev
https://golang.org/cl/10692043

7ebb187e

runtime: fix CPU underutilization · 15a1c3d1

Dmitriy Vyukov authored Jun 27, 2013

runtime.newproc/ready are deliberately sloppy about waking new M's,
they only ensure that there is at least 1 spinning M.
Currently to compensate for that, schedule() checks if the current P
has local work and there are no spinning M's, it wakes up another one.
It does not work if goroutines do not call schedule.
With this change a spinning M wakes up another M when it finds work to do.
It's also not ideal, but it fixes the underutilization.
A proper check would require to know the exact number of runnable G's,
but it's too expensive to maintain.
Fixes #5586.

R=rsc
CC=gobot, golang-dev
https://golang.org/cl/9776044

15a1c3d1

runtime: fix argument printing during traceback · eac6bee7

Dmitriy Vyukov authored Jun 27, 2013

Current code can print more arguments than necessary
and also incorrectly prints "...".
Update #5723.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10689043

eac6bee7

doc/go1.2.txt: cmd/go and coverage; simple hash Sum functions · 4f2278d4
Rob Pike authored Jun 27, 2013
```
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/10631043
```
4f2278d4

runtime: record proper goroutine state during stack split · 6fa3c89b

Russ Cox authored Jun 27, 2013

Until now, the goroutine state has been scattered during the
execution of newstack and oldstack. It's all there, and those routines
know how to get back to a working goroutine, but other pieces of
the system, like stack traces, do not. If something does interrupt
the newstack or oldstack execution, the rest of the system can't
understand the goroutine. For example, if newstack decides there
is an overflow and calls throw, the stack tracer wouldn't dump the
goroutine correctly.

For newstack to save a useful state snapshot, it needs to be able
to rewind the PC in the function that triggered the split back to
the beginning of the function. (The PC is a few instructions in, just
after the call to morestack.) To make that possible, we change the
prologues to insert a jmp back to the beginning of the function
after the call to morestack. That is, the prologue used to be roughly:

        TEXT myfunc
                check for split
                jmpcond nosplit
                call morestack
        nosplit:
                sub $xxx, sp

Now an extra instruction is inserted after the call:

        TEXT myfunc
        start:
                check for split
                jmpcond nosplit
                call morestack
                jmp start
        nosplit:
                sub $xxx, sp

The jmp is not executed directly. It is decoded and simulated by
runtime.rewindmorestack to discover the beginning of the function,
and then the call to morestack returns directly to the start label
instead of to the jump instruction. So logically the jmp is still
executed, just not by the cpu.

The prologue thus repeats in the case of a function that needs a
stack split, but against the cost of the split itself, the extra few
instructions are noise. The repeated prologue has the nice effect of
making a stack split double-check that the new stack is big enough:
if morestack happens to return on a too-small stack, we'll now notice
before corruption happens.

The ability for newstack to rewind to the beginning of the function
should help preemption too. If newstack decides that it was called
for preemption instead of a stack split, it now has the goroutine state
correctly paused if rescheduling is needed, and when the goroutine
can run again, it can return to the start label on its original stack
and re-execute the split check.

Here is an example of a split stack overflow showing the full
trace, without any special cases in the stack printer.
(This one was triggered by making the split check incorrect.)

runtime: newstack framesize=0x0 argsize=0x18 sp=0x6aebd0 stack=[0x6b0000, 0x6b0fa0]
        morebuf={pc:0x69f5b sp:0x6aebd8 lr:0x0}
        sched={pc:0x68880 sp:0x6aebd0 lr:0x0 ctxt:0x34e700}
runtime: split stack overflow: 0x6aebd0 < 0x6b0000
fatal error: runtime: split stack overflow

goroutine 1 [stack split]:
runtime.mallocgc(0x290, 0x100000000, 0x1)
        /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:21 fp=0x6aebd8
runtime.new()
        /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:682 +0x5b fp=0x6aec08
go/build.(*Context).Import(0x5ae340, 0xc210030c71, 0xa, 0xc2100b4380, 0x1b, ...)
        /Users/rsc/g/go/src/pkg/go/build/build.go:424 +0x3a fp=0x6b00a0
main.loadImport(0xc210030c71, 0xa, 0xc2100b4380, 0x1b, 0xc2100b42c0, ...)
        /Users/rsc/g/go/src/cmd/go/pkg.go:249 +0x371 fp=0x6b01a8
main.(*Package).load(0xc21017c800, 0xc2100b42c0, 0xc2101828c0, 0x0, 0x0, ...)
        /Users/rsc/g/go/src/cmd/go/pkg.go:431 +0x2801 fp=0x6b0c98
main.loadPackage(0x369040, 0x7, 0xc2100b42c0, 0x0)
        /Users/rsc/g/go/src/cmd/go/pkg.go:709 +0x857 fp=0x6b0f80
----- stack segment boundary -----
main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc2100e6c00, 0xc2100e5750, ...)
        /Users/rsc/g/go/src/cmd/go/build.go:539 +0x437 fp=0x6b14a0
main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc21015b400, 0x2, ...)
        /Users/rsc/g/go/src/cmd/go/build.go:528 +0x1d2 fp=0x6b1658
main.(*builder).test(0xc2100902a0, 0xc210092000, 0x0, 0x0, 0xc21008ff60, ...)
        /Users/rsc/g/go/src/cmd/go/test.go:622 +0x1b53 fp=0x6b1f68
----- stack segment boundary -----
main.runTest(0x5a6b20, 0xc21000a020, 0x2, 0x2)
        /Users/rsc/g/go/src/cmd/go/test.go:366 +0xd09 fp=0x6a5cf0
main.main()
        /Users/rsc/g/go/src/cmd/go/main.go:161 +0x4f9 fp=0x6a5f78
runtime.main()
        /Users/rsc/g/go/src/pkg/runtime/proc.c:183 +0x92 fp=0x6a5fa0
runtime.goexit()
        /Users/rsc/g/go/src/pkg/runtime/proc.c:1266 fp=0x6a5fa8

And here is a seg fault during oldstack:

SIGSEGV: segmentation violation
PC=0x1b2a6

runtime.oldstack()
        /Users/rsc/g/go/src/pkg/runtime/stack.c:159 +0x76
runtime.lessstack()
        /Users/rsc/g/go/src/pkg/runtime/asm_amd64.s:270 +0x22

goroutine 1 [stack unsplit]:
fmt.(*pp).printArg(0x2102e64e0, 0xe5c80, 0x2102c9220, 0x73, 0x0, ...)
        /Users/rsc/g/go/src/pkg/fmt/print.go:818 +0x3d3 fp=0x221031e6f8
fmt.(*pp).doPrintf(0x2102e64e0, 0x12fb20, 0x2, 0x221031eb98, 0x1, ...)
        /Users/rsc/g/go/src/pkg/fmt/print.go:1183 +0x15cb fp=0x221031eaf0
fmt.Sprintf(0x12fb20, 0x2, 0x221031eb98, 0x1, 0x1, ...)
        /Users/rsc/g/go/src/pkg/fmt/print.go:234 +0x67 fp=0x221031eb40
flag.(*stringValue).String(0x2102c9210, 0x1, 0x0)
        /Users/rsc/g/go/src/pkg/flag/flag.go:180 +0xb3 fp=0x221031ebb0
flag.(*FlagSet).Var(0x2102f6000, 0x293d38, 0x2102c9210, 0x143490, 0xa, ...)
        /Users/rsc/g/go/src/pkg/flag/flag.go:633 +0x40 fp=0x221031eca0
flag.(*FlagSet).StringVar(0x2102f6000, 0x2102c9210, 0x143490, 0xa, 0x12fa60, ...)
        /Users/rsc/g/go/src/pkg/flag/flag.go:550 +0x91 fp=0x221031ece8
flag.(*FlagSet).String(0x2102f6000, 0x143490, 0xa, 0x12fa60, 0x0, ...)
        /Users/rsc/g/go/src/pkg/flag/flag.go:563 +0x87 fp=0x221031ed38
flag.String(0x143490, 0xa, 0x12fa60, 0x0, 0x161950, ...)
        /Users/rsc/g/go/src/pkg/flag/flag.go:570 +0x6b fp=0x221031ed80
testing.init()
        /Users/rsc/g/go/src/pkg/testing/testing.go:-531 +0xbb fp=0x221031edc0
strings_test.init()
        /Users/rsc/g/go/src/pkg/strings/strings_test.go:1115 +0x62 fp=0x221031ef70
main.init()
        strings/_test/_testmain.go:90 +0x3d fp=0x221031ef78
runtime.main()
        /Users/rsc/g/go/src/pkg/runtime/proc.c:180 +0x8a fp=0x221031efa0
runtime.goexit()
        /Users/rsc/g/go/src/pkg/runtime/proc.c:1269 fp=0x221031efa8

goroutine 2 [runnable]:
runtime.MHeap_Scavenger()
        /Users/rsc/g/go/src/pkg/runtime/mheap.c:438
runtime.goexit()
        /Users/rsc/g/go/src/pkg/runtime/proc.c:1269
created by runtime.main
        /Users/rsc/g/go/src/pkg/runtime/proc.c:166

rax     0x23ccc0
rbx     0x23ccc0
rcx     0x0
rdx     0x38
rdi     0x2102c0170
rsi     0x221032cfe0
rbp     0x221032cfa0
rsp     0x7fff5fbff5b0
r8      0x2102c0120
r9      0x221032cfa0
r10     0x221032c000
r11     0x104ce8
r12     0xe5c80
r13     0x1be82baac718
r14     0x13091135f7d69200
r15     0x0
rip     0x1b2a6
rflags  0x10246
cs      0x2b
fs      0x0
gs      0x0

Fixes #5723.

R=r, dvyukov, go.peter.90, dave, iant
CC=golang-dev
https://golang.org/cl/10360048

6fa3c89b

crypto/sha512: update comment for the Sum512 function. · 2546a541
Robin Eklind authored Jun 27, 2013
```
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10660043
```
2546a541
runtime: remove unused typedef · 8cd0689a
Ian Lance Taylor authored Jun 27, 2013
```
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/10660044
```
8cd0689a

syscall: handle empty environment variable values properly on windows · 04b405c7

Alex Brainman authored Jun 27, 2013

Setenv("AN_ENV_VAR", "") deletes AN_ENV_VAR instead of setting it
to "" at this moment. Also Getenv("AN_ENV_VAR") returns "not found",
if AN_ENV_VAR is "". Change it, so they behave like unix.

Fixes #5610

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10594043

04b405c7

26 Jun, 2013 11 commits

misc/emacs: fix godef-jump on Windows. · d9f5c64f

Charles Lee authored Jun 26, 2013

Fixes #5555.

R=adonovan, dominik.honnef, iant
CC=gobot, golang-dev
https://golang.org/cl/9762045

d9f5c64f

A+C: Charles Lee (individual CLA) · 3ea6c695
Ian Lance Taylor authored Jun 26, 2013
```
Generated by addca.

R=gobot
CC=golang-dev
https://golang.org/cl/10639043
```
3ea6c695

crypto/sha512: provide top-level Sum512 and Sum384 functions · fa7e46c8

Rob Pike authored Jun 26, 2013

Makes it easy to ask the simple question, what is the hash of this data?
Also fix the commentary and prints in Sum256.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10630043

fa7e46c8

crypto/sha256: provide top-level Sum and Sum224 functions · 5cd5d889

Rob Pike authored Jun 26, 2013

Makes it easy to ask the simple question, what is the hash of this data?

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10629043

5cd5d889

cmd/go: proper rebuild of affected packages during go test · 8b9c1a22

Russ Cox authored Jun 26, 2013

With this CL, go test -short -cover std successfully builds and
runs all the standard package tests. The tests that look a file
line numbers (log and runtime/debug) fail, because cover is
not inserting //line directives. Everything else passes.

ok  	cmd/api	0.038s	coverage: 66.6% of statements
?   	cmd/cgo	[no test files]
ok  	cmd/fix	0.043s	coverage: 27.2% of statements
ok  	cmd/go	0.063s	coverage: 2.4% of statements
?   	cmd/godoc	[no test files]
ok  	cmd/gofmt	0.085s	coverage: 61.3% of statements
?   	cmd/yacc	[no test files]
ok  	archive/tar	0.023s	coverage: 74.2% of statements
ok  	archive/zip	0.075s	coverage: 71.8% of statements
ok  	bufio	0.149s	coverage: 88.2% of statements
ok  	bytes	0.135s	coverage: 90.4% of statements
ok  	compress/bzip2	0.087s	coverage: 85.1% of statements
ok  	compress/flate	0.632s	coverage: 79.3% of statements
ok  	compress/gzip	0.027s	coverage: 76.7% of statements
ok  	compress/lzw	0.141s	coverage: 71.2% of statements
ok  	compress/zlib	1.123s	coverage: 77.2% of statements
ok  	container/heap	0.020s	coverage: 85.8% of statements
ok  	container/list	0.021s	coverage: 92.5% of statements
ok  	container/ring	0.030s	coverage: 86.5% of statements
?   	crypto	[no test files]
ok  	crypto/aes	0.054s	coverage: 54.3% of statements
ok  	crypto/cipher	0.027s	coverage: 68.8% of statements
ok  	crypto/des	0.041s	coverage: 83.8% of statements
ok  	crypto/dsa	0.027s	coverage: 33.1% of statements
ok  	crypto/ecdsa	0.048s	coverage: 48.7% of statements
ok  	crypto/elliptic	0.030s	coverage: 91.6% of statements
ok  	crypto/hmac	0.019s	coverage: 83.3% of statements
ok  	crypto/md5	0.020s	coverage: 78.7% of statements
ok  	crypto/rand	0.057s	coverage: 20.8% of statements
ok  	crypto/rc4	0.092s	coverage: 70.8% of statements
ok  	crypto/rsa	0.261s	coverage: 80.8% of statements
ok  	crypto/sha1	0.019s	coverage: 83.9% of statements
ok  	crypto/sha256	0.021s	coverage: 89.0% of statements
ok  	crypto/sha512	0.023s	coverage: 88.7% of statements
ok  	crypto/subtle	0.027s	coverage: 83.9% of statements
ok  	crypto/tls	0.833s	coverage: 79.7% of statements
ok  	crypto/x509	0.961s	coverage: 74.9% of statements
?   	crypto/x509/pkix	[no test files]
ok  	database/sql	0.033s	coverage: 75.0% of statements
ok  	database/sql/driver	0.020s	coverage: 46.2% of statements
ok  	debug/dwarf	0.023s	coverage: 71.5% of statements
ok  	debug/elf	0.035s	coverage: 58.2% of statements
ok  	debug/gosym	0.022s	coverage: 1.8% of statements
ok  	debug/macho	0.023s	coverage: 63.7% of statements
ok  	debug/pe	0.024s	coverage: 50.5% of statements
ok  	encoding/ascii85	0.021s	coverage: 89.7% of statements
ok  	encoding/asn1	0.022s	coverage: 77.9% of statements
ok  	encoding/base32	0.022s	coverage: 91.4% of statements
ok  	encoding/base64	0.020s	coverage: 90.7% of statements
ok  	encoding/binary	0.022s	coverage: 66.2% of statements
ok  	encoding/csv	0.022s	coverage: 88.5% of statements
ok  	encoding/gob	0.064s	coverage: 82.2% of statements
ok  	encoding/hex	0.019s	coverage: 86.3% of statements
ok  	encoding/json	0.047s	coverage: 77.3% of statements
ok  	encoding/pem	0.026s	coverage: 80.5% of statements
ok  	encoding/xml	0.039s	coverage: 85.0% of statements
ok  	errors	0.022s	coverage: 100.0% of statements
ok  	expvar	0.048s	coverage: 72.0% of statements
ok  	flag	0.019s	coverage: 86.9% of statements
ok  	fmt	0.062s	coverage: 91.2% of statements
ok  	go/ast	0.028s	coverage: 46.3% of statements
ok  	go/build	0.190s	coverage: 75.4% of statements
ok  	go/doc	0.095s	coverage: 76.7% of statements
ok  	go/format	0.036s	coverage: 79.8% of statements
ok  	go/parser	0.075s	coverage: 82.0% of statements
ok  	go/printer	0.733s	coverage: 88.6% of statements
ok  	go/scanner	0.031s	coverage: 86.5% of statements
ok  	go/token	0.062s	coverage: 79.7% of statements
?   	hash	[no test files]
ok  	hash/adler32	0.029s	coverage: 49.0% of statements
ok  	hash/crc32	0.020s	coverage: 64.2% of statements
ok  	hash/crc64	0.021s	coverage: 53.5% of statements
ok  	hash/fnv	0.018s	coverage: 75.5% of statements
ok  	html	0.022s	coverage: 4.5% of statements
ok  	html/template	0.087s	coverage: 83.9% of statements
ok  	image	0.108s	coverage: 67.1% of statements
ok  	image/color	0.026s	coverage: 20.1% of statements
ok  	image/draw	0.049s	coverage: 69.6% of statements
ok  	image/gif	0.019s	coverage: 65.2% of statements
ok  	image/jpeg	0.197s	coverage: 78.6% of statements
ok  	image/png	0.055s	coverage: 56.5% of statements
ok  	index/suffixarray	0.027s	coverage: 82.4% of statements
ok  	io	0.037s	coverage: 83.4% of statements
ok  	io/ioutil	0.022s	coverage: 70.1% of statements
FAIL	log	0.020s
ok  	log/syslog	2.063s	coverage: 71.1% of statements
ok  	math	0.023s	coverage: 76.5% of statements
ok  	math/big	0.235s	coverage: 79.2% of statements
ok  	math/cmplx	0.020s	coverage: 66.5% of statements
ok  	math/rand	0.031s	coverage: 69.9% of statements
ok  	mime	0.022s	coverage: 83.0% of statements
ok  	mime/multipart	0.389s	coverage: 76.1% of statements
ok  	net	2.219s	coverage: 58.0% of statements
ok  	net/http	4.744s	coverage: 82.9% of statements
ok  	net/http/cgi	0.593s	coverage: 68.5% of statements
ok  	net/http/cookiejar	0.038s	coverage: 90.3% of statements
ok  	net/http/fcgi	0.047s	coverage: 37.6% of statements
ok  	net/http/httptest	0.068s	coverage: 68.9% of statements
ok  	net/http/httputil	0.058s	coverage: 52.8% of statements
?   	net/http/pprof	[no test files]
ok  	net/mail	0.025s	coverage: 80.3% of statements
ok  	net/rpc	0.063s	coverage: 71.5% of statements
ok  	net/rpc/jsonrpc	0.047s	coverage: 81.3% of statements
ok  	net/smtp	0.032s	coverage: 74.1% of statements
ok  	net/textproto	0.023s	coverage: 66.0% of statements
ok  	net/url	0.020s	coverage: 78.2% of statements
ok  	os	4.729s	coverage: 73.3% of statements
ok  	os/exec	39.620s	coverage: 65.1% of statements
ok  	os/signal	0.541s	coverage: 89.9% of statements
ok  	os/user	0.022s	coverage: 62.2% of statements
ok  	path	0.018s	coverage: 90.8% of statements
ok  	path/filepath	10.834s	coverage: 88.4% of statements
ok  	reflect	0.055s	coverage: 83.2% of statements
ok  	regexp	0.084s	coverage: 75.5% of statements
ok  	regexp/syntax	0.547s	coverage: 85.2% of statements
ok  	runtime	4.755s	coverage: 75.9% of statements
?   	runtime/cgo	[no test files]
FAIL	runtime/debug	0.018s
ok  	runtime/pprof	0.368s	coverage: 8.5% of statements
?   	runtime/race	[no test files]
ok  	sort	0.059s	coverage: 97.7% of statements
ok  	strconv	0.315s	coverage: 95.6% of statements
ok  	strings	0.147s	coverage: 96.1% of statements
ok  	sync	0.083s	coverage: 56.7% of statements
ok  	sync/atomic	0.035s	coverage: 0.0% of statements
ok  	syscall	0.043s	coverage: 24.0% of statements
ok  	testing	0.018s	coverage: 24.0% of statements
?   	testing/iotest	[no test files]
ok  	testing/quick	0.062s	coverage: 83.2% of statements
ok  	text/scanner	0.020s	coverage: 91.5% of statements
ok  	text/tabwriter	0.021s	coverage: 90.4% of statements
ok  	text/template	0.052s	coverage: 81.1% of statements
ok  	text/template/parse	0.024s	coverage: 86.1% of statements
ok  	time	2.431s	coverage: 88.8% of statements
ok  	unicode	0.024s	coverage: 92.1% of statements
ok  	unicode/utf16	0.017s	coverage: 97.3% of statements
ok  	unicode/utf8	0.019s	coverage: 97.4% of statements
?   	unsafe	[no test files]

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10586043

8b9c1a22

crypto/md5: provide a top-level Sum function · 4850f5d5

Rob Pike authored Jun 26, 2013

Makes it easy to ask the simple question, what is the hash of this data?
Also mark block as non-escaping.

R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/10624044

4850f5d5

cmd/go: log compilation errors when scanning directories and packages · 53a00e28

Rob Pike authored Jun 26, 2013

Before, some packages disappear silently if the package cannot be imported,
such as if the import statement is unparseable.
Before:
        % ls src
        foo   issue
        % go list ./...
        _/home/r/bug/src/foo
        %
After:
        % go list ./...
        src/issue/issue.go:3:5: expected 'STRING', found newline
        _/home/r/bug/src/foo
        %

R=rsc
CC=golang-dev
https://golang.org/cl/10568043

53a00e28

misc/dashboard: show all race builders as "race" · 15790204

Dmitriy Vyukov authored Jun 26, 2013

race is more important than arch (moreover race implies x64)
don't know how to test it

R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/10484046

15790204

test: match gccgo error strings. · be6556f7
Rémy Oudompheng authored Jun 26, 2013
```
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10468043
```
be6556f7
test/shift1.go: recognize gccgo errors · 1761e250
Ian Lance Taylor authored Jun 26, 2013
```
R=golang-dev, remyoudompheng, iant
CC=golang-dev
https://golang.org/cl/10524045
```
1761e250

crypto/sha1: provide a top-level Sum function · 4cf73890

Rob Pike authored Jun 26, 2013

Makes it easy to ask the simple question, what is the hash of this data?

R=golang-dev, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/10571043

4cf73890

25 Jun, 2013 12 commits

cmd/gc: fix escape analysis ordering · 148fac79

Russ Cox authored Jun 25, 2013

Functions without bodies were excluded from the ordering logic,
because when I wrote the ordering logic there was no reason to
analyze them.

But then we added //go:noescape tags that need analysis, and we
didn't update the ordering logic.

So in the absence of good ordering, //go:noescape only worked
if it appeared before the use in the source code.

Fixes #5773.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10570043

148fac79

cmd/ld: fix line numbers when using fieldtrack · a14e143c

Russ Cox authored Jun 25, 2013

USEFIELD is a special kind of NOP, so treat it like a NOP
when generating the pc-ln table.

There are more invasive fixes that could be applied here.
I am going for minimum number of lines changed.

The smallest test case we know of is five distinct Go files
in four packages, and the bug only happens with
GOEXPERIMENT=fieldtrack enabled, which we don't
normally build with, so the test would never run
meaningfully anyway.

Fixes #5762.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10495044

a14e143c

codereview: force hg update after hg pull -u during hg sync · 75aab137

Russ Cox authored Jun 25, 2013

If you hg update your client to an earlier CL, then
hg sync will move you back to tip if it pulls anything in,
but it will leave you where you are if it doesn't pull anything in.
That's confusing: make hg sync always update to tip.

R=golang-dev, bradfitz, r, dsymonds
CC=golang-dev
https://golang.org/cl/10456044

75aab137

lib9: avoid all -Wconversion warnings · 7590e28d

Ian Lance Taylor authored Jun 25, 2013

Built after adding -Wconversion to the list of compiler
arguments used when building.  I believe these are all OK
assuming we will not change the API.  There is no effort to
detect overflow due to very long strings.

R=golang-dev, dave, rsc, r
CC=golang-dev
https://golang.org/cl/10195044

7590e28d

sync: fix race instrumentation of WaitGroup · 07cb48c3

Dmitriy Vyukov authored Jun 25, 2013

Currently more than 1 gorutine can execute raceWrite() in Wait()
in the following scenario:
1. goroutine 1 executes first check of wg.counter, sees that it's == 0
2. goroutine 2 executes first check of wg.counter, sees that it's == 0
3. goroutine 2 locks the mutex, sees that he is the first waiter and executes raceWrite()
4. goroutine 2 block on the semaphore
5. goroutine 3 executes Done() and unblocks goroutine 2
6. goroutine 1 lock the mutex, sees that he is the first waiter and executes raceWrite()

It produces the following false report:
WARNING: DATA RACE
Write by goroutine 35:
  sync.raceWrite()
      src/pkg/sync/race.go:41 +0x33
  sync.(*WaitGroup).Wait()
      src/pkg/sync/waitgroup.go:103 +0xae
  command-line-arguments_test.TestNoRaceWaitGroupMultipleWait2()
      src/pkg/runtime/race/testdata/waitgroup_test.go:156 +0x19a
  testing.tRunner()
      src/pkg/testing/testing.go:361 +0x108

Previous write by goroutine 36:
  sync.raceWrite()
      src/pkg/sync/race.go:41 +0x33
  sync.(*WaitGroup).Wait()
      src/pkg/sync/waitgroup.go:103 +0xae
  command-line-arguments_test.func·012()
      src/pkg/runtime/race/testdata/waitgroup_test.go:148 +0x4d

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10424043

07cb48c3

runtime: do not mark os memory as executable on windows · 3d513faa

Alex Brainman authored Jun 25, 2013

Resubmit 3c2cddfbdaec now that windows callbacks
are not generated during runtime.

Fixes #5494

R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/10487043

3d513faa

test: add shift expression incorrectly rejected by gccgo. · 05cf6fe0
Rémy Oudompheng authored Jun 25, 2013
```
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/10483045
```
05cf6fe0

libmach: trivial: resolve unused parameter warnings · 3a3b53da

Dave Cheney authored Jun 25, 2013

Fix a bunch of warnings detected by https://golang.org/cl/8090044.

Same as CL 10483044, but for FreeBSD.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10498044

3a3b53da

runtime: change netpoll in preparation for windows implementation · 8486d96a

Alex Brainman authored Jun 25, 2013

- change runtime_pollWait so it does not return
  closed or timeout if IO is ready - windows must
  know if IO has completed or not even after
  interruption;
- add (*pollDesc).Prepare(mode int) that can be
  used for both read and write, same for Wait;
- introduce runtime_pollWaitCanceled and expose
  it in net as (*pollDesc).WaitCanceled(mode int);

Full windows netpoll changes are
here https://golang.org/cl/8670044/.

R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/10485043

8486d96a

libmach: trivial: resolve unused parameter warnings · 02991bb9

Dave Cheney authored Jun 25, 2013

Fix a bunch of warnings detected by https://golang.org/cl/8090044

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10483044

02991bb9

crypto/sha1: mark block as non-escaping · 793bb6cc

Rob Pike authored Jun 25, 2013

The compiler still gets the escape analysis wrong, but the annotation here is correct.

R=golang-dev, dave, bradfitz
CC=golang-dev
https://golang.org/cl/10514046

793bb6cc

syscall: reduce duplication between *bsd and linux · 3b76d70e
Dave Cheney authored Jun 25, 2013
```
Part 2 of several.

R=rsc, mikioh.mikioh, r
CC=golang-dev
https://golang.org/cl/10462043
```
3b76d70e

24 Jun, 2013 3 commits

hash: tweak the package docs · feab3f49

Rob Pike authored Jun 24, 2013

No semantic change.
I found the wording distracting in a couple of instances and was moved to improve it.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10478048

feab3f49

net/http: Transport should return an error when response body ends early · a0540284

Brad Fitzpatrick authored Jun 24, 2013

If a server response contains a Content-Length and the body is short,
the Transport should end in io.ErrUnexpectedEOF, not io.EOF.

Fixes #5738

R=golang-dev, kevlar, r
CC=golang-dev
https://golang.org/cl/10237050

a0540284

net/rpc: fix RegisterName rejects "." character. · 3eaaed50
ChaiShushan authored Jun 24, 2013
```
Fixes #5617.

R=r, rsc
CC=gobot, golang-dev
https://golang.org/cl/10370043
```
3eaaed50