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

R=r, adg, bradfitz
CC=golang-dev
https://golang.org/cl/12312043

Includes deleting some unused items.

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/12305043

It's okay to preempt at ordinary function calls because
compilers arrange that there are no live registers to save
on entry to the function call.

The software floating point routines are function calls
masquerading as individual machine instructions. They are
expected to keep all the registers intact. In particular,
they are expected not to clobber all the floating point
registers.

The floating point registers are kept per-M, because they
are not live at non-preemptive goroutine scheduling events,
and so keeping them per-M reduces the number of 132-byte
register blocks we are keeping in memory.

Because they are per-M, allowing the goroutine to be
rescheduled during software floating point simulation
would mean some other goroutine could overwrite the registers
or perhaps the goroutine would continue running on a different
M entirely.

Disallow preemption during the software floating point
routines to make sure that a function full of floating point
instructions has the same floating point registers throughout
its execution.

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

Per suggestion from Russ in February. Then strings.IndexByte
can be implemented in terms of the shared code in pkg runtime.

Update #3751

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

Previously if a path was set manually without a leading /, String()
would not insert the slash when writing its output. This would lead
to situations where a URL that should be http://www.google.com/search
is output as http://www.google.comsearch

Fixes #5927.

R=golang-dev, bradfitz, rsc, 0xjnml
CC=golang-dev
https://golang.org/cl/11698045

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

Generated by addca.

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

I used just enough of the data provided by Matt in Issue 5915 to trigger
issue 5915. As luck would have it, using slightly less of it triggered
issue 5962.

Fixes #5915.
Fixes #5962.

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

Fixes #3033

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

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

I always forget which package has it.

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

Also move chatty recent additions to -v -v.

For what it's worth:

$ go build -o /dev/null -ldflags -v cmd/go
...
 0.87 pclntab=1110836 bytes, funcdata total 69700 bytes
...
$

This broke the ELF builds last time because I tried to dedup
the funcdata in case the same funcdata was pointed at by
multiple functions. That doesn't currently happen, so I've
removed that test.

If we start doing bitmap coalescing we'll need to figure out
how to measure the size more carefully, but I think at that
point the bitmaps will be an extra indirection away from the
funcdata anyway, so the dedup I used before wouldn't help.

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

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

This allows to at least determine goroutine "identity".
Now it looks like:
goroutine 12 [running]:
        goroutine running on other thread; stack unavailable
created by testing.RunTests
        src/pkg/testing/testing.go:440 +0x88e

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

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

We see timeouts in these tests on some platforms,
but not on the others.  The hypothesis is that
the problematic platforms are slow uniprocessors.
Stack traces do not suggest that the process
is completely hang, and it is able to schedule
the alarm goroutine. And if it actually hangs,
we still will be able to detect that.

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

It looks reasonable here and may be useful.

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

Currently fails with:
fatal error: runtime: stack split during syscall
goroutine 2 [stack split]:
_vasop(0x3ac4a0, 0x505f8f00, 0x7a5a8, 0x7, 0x1ed3797f, ...)
        src/pkg/runtime/vlrt_arm.c:513 fp=0x505f8ecc
runtime.semasleep(0xf8475800, 0xd)
        src/pkg/runtime/os_netbsd.c:97 +0x178 fp=0x505f8efc

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

Somehow missed these. Moved to go.tools/cmd/godoc/template.

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

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

With dup3, we can avoid an extra system call on some machines
while holding syscall.ForkLock. Currently we have to
syscall.Dup + syscall.CloseOnExec.

On machines with Linux and a new enough kernel, this can just
be dup3.

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

Fixes #5953

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12117043

More functions needs to be marked as no stack split.

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

(Replacement for CL 11884043.)

1) Explain a[i] and a[i:j] where a is of type *A as
   shortcut for (*a)[i] and (*a)[i:j], respectively.

2) Together with 1), because len() of nil slices is
   well defined, there's no need to special case nil
   operands anymore.

3) The result of indexing or slicing a constant string
   is always a non-constant byte or string value.

4) The result of slicing an untyped string is a value
   of type string.

5) If the operand of a valid slice a[i:j] is nil (i, j
   must be 0 for it to be valid - this already follows
   from the in-range rules), the result is a nil slice.

Fixes #4913.
Fixes #5951.

R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/12198043

These are moved to code.google.com/p/go.tools/cmd/godoc.

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

Mark the 386 one too for consistency,
although most of that code is no longer used.

TBR=dvyukov
CC=golang-dev
https://golang.org/cl/12227043

Preemption during the software floating point code
could cause m (R9) to change, so that when the
original registers were restored at the end of the
floating point handler, the changed and correct m
would be replaced by the old and incorrect m.

TBR=dvyukov
CC=golang-dev
https://golang.org/cl/11883045

R=golang-dev, dave, dsymonds
CC=golang-dev
https://golang.org/cl/12225043

See also https://golang.org/cl/12180043/

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

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

The godoc command now lives at code.google.com/p/go.tools/cmd/godoc.

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

Also suggest "go get" if godoc not found when running "go doc".

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

Fixes #5998.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/12149043

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12208043

Breaks all ELF builds.

««« original CL description
       cmd/ld: report pclntab, funcdata sizes in 6l -v output
       Also move chatty recent additions to -v -v.

       For what it's worth:

       $ go build -o /dev/null -ldflags -v cmd/godoc
       ...
        0.73 pclntab=1259976 bytes, funcdata total 79788 bytes
       ...
       $

R=ken2
CC=cshapiro, golang-dev
https://golang.org/cl/12193043
»»»

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

Operations on int64 are very stack consuming with 5c.
Fixes netbsd/arm build.

Before: TEXT    runtime.timediv+0(SB),7,$52-16
After:  TEXT    runtime.timediv+0(SB),7,$44-16

The stack usage is unchanged on 386:
        TEXT    runtime.timediv+0(SB),7,$8-16

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

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

1. They are FIFOs.
2. They are safe for concurrent access.

Fixes #5911.

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

Fixes #4940.

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