David Crawshaw [Wed, 10 Dec 2014 14:29:24 +0000 (09:29 -0500)]
runtime: send android stderr to /dev/log/main
I tried to submit this in Go 1.4 as cl/107540044 but tripped over the
changes for getting C off the G stack. This is a rewritten version that
avoids cgo and works directly with the underlying log device.
Change-Id: I14c227dbb4202690c2c67c5a613d6c6689a6662a
Reviewed-on: https://go-review.googlesource.com/1285 Reviewed-by: Keith Randall <khr@golang.org>
Austin Clements [Tue, 9 Dec 2014 17:31:11 +0000 (12:31 -0500)]
runtime: restore error message on early needm
needm used to print an error before exiting when it was called too
early, but this error was lost in the transition to Go. Bring back
the error so we don't silently exit(1) when this happens.
Shenghou Ma [Tue, 9 Dec 2014 05:13:10 +0000 (00:13 -0500)]
test/fixedbugs/bug302: fix test on windows.
Change-Id: I74c2578d1620b37a6486eca00a774b9a736a8899
Reviewed-on: https://go-review.googlesource.com/1222 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Mon, 8 Dec 2014 19:20:41 +0000 (11:20 -0800)]
test/fibo: a stand-alone bignum/allocation benchmark and test
Usage:
fibo <n> compute fibonacci(n), n must be >= 0
fibo -bench benchmark fibonacci computation (takes about 1 min)
Additional flags:
-half add values using two half-digit additions
-opt optimize memory allocation through reuse
-short only print the first 10 digits of very large fibonacci numbers
This change was reviewed in detail as https://codereview.appspot.com/168480043 .
Austin Clements [Mon, 8 Dec 2014 16:12:33 +0000 (11:12 -0500)]
runtime: fix missing newline when dumping bad symbol table
If the symbol table isn't sorted, we print it and abort. However, we
were missing the line break after each symbol, resulting in one
gigantic line instead of a nicely formatted table.
Russ Cox [Sat, 6 Dec 2014 01:34:45 +0000 (20:34 -0500)]
all: merge dev.garbage (d1238958d4ae) into default branch
When we start work on Gerrit, ppc64 and garbage collection
work will continue in the master branch, not the dev branches.
(We may still use dev branches for other things later, but
these are ready to be merged, and doing it now, before moving
to Git means we don't have to have dev branches working
in the Gerrit workflow on day one.)
With this change, default now contains Go 1.5 work.
Any future bug fixes for Go 1.4 in the compilers or
the runtime will have to be made directly to the
release branch.
Austin Clements [Fri, 5 Dec 2014 14:24:01 +0000 (09:24 -0500)]
[dev.cc] liblink: don't patch jumps to jumps to symbols
When liblink sees something like
JMP x
...
x: JMP y
it rewrites the first jump to jump directly to y. This is
fine if y is a resolved label. However, it *also* does this
if y is a function symbol, but fails to carry over the
relocation that would later patch in that symbol's value. As
a result, the original jump becomes either a self-jump (if
relative) or a jump to PC 0 (if absolute).
Fix this by disabling this optimization if the jump being
patched in is a jump to a symbol.
Shenghou Ma [Fri, 5 Dec 2014 07:22:20 +0000 (02:22 -0500)]
[dev.cc] cmd/ld: finalize linkmode before determining whether to import runtime/cgo
Frankly, I don't understand how the current code could possibly work except
when every android program is using cgo. Discovered this while working on
the iOS port.
Rob Pike [Fri, 5 Dec 2014 00:15:38 +0000 (09:15 +0900)]
cmd/go: avoid use of bufio.Scanner in generate
Scanner can't handle stupid long lines and there are
reports of stupid long lines in production.
Note the issue isn't long "//go:generate" lines, but
any long line in any Go source file.
To be fair, if you're going to have a stupid long line
it's not a bad bet you'll want to run it through go
generate, because it's some embeddable asset that
has been machine generated. (One could ask why
that generation process didn't add a newline or two,
but we should cope anyway.)
Rewrite the file scanner in "go generate" so it can
handle arbitrarily long lines, and only stores in memory
those lines that start "//go:generate".
Also: Adjust the documentation to make clear that it
does not parse the file.
Russ Cox [Mon, 1 Dec 2014 21:32:06 +0000 (16:32 -0500)]
runtime: fix hang in GC due to shrinkstack vs netpoll race
During garbage collection, after scanning a stack, we think about
shrinking it to reclaim some memory. The shrinking code (called
while the world is stopped) checked that the status was Gwaiting
or Grunnable and then changed the state to Gcopystack, to essentially
lock the stack so that no other GC thread is scanning it.
The same locking happens for stack growth (and is more necessary there).
oldstatus = runtime·readgstatus(gp);
oldstatus &= ~Gscan;
if(oldstatus == Gwaiting || oldstatus == Grunnable)
runtime·casgstatus(gp, oldstatus, Gcopystack); // oldstatus is Gwaiting or Grunnable
else
runtime·throw("copystack: bad status, not Gwaiting or Grunnable");
Unfortunately, "stop the world" doesn't stop everything. It stops all
normal goroutine execution, but the network polling thread is still
blocked in epoll and may wake up. If it does, and it chooses a goroutine
to mark runnable, and that goroutine is the one whose stack is shrinking,
then it can happen that between readgstatus and casgstatus, the status
changes from Gwaiting to Grunnable.
casgstatus assumes that if the status is not what is expected, it is a
transient change (like from Gwaiting to Gscanwaiting and back, or like
from Gwaiting to Gcopystack and back), and it loops until the status
has been restored to the expected value. In this case, the status has
changed semi-permanently from Gwaiting to Grunnable - it won't
change again until the GC is done and the world can continue, but the
GC is waiting for the status to change back. This wedges the program.
To fix, call a special variant of casgstatus that accepts either Gwaiting
or Grunnable as valid statuses.
Without the fix bug with the extra check+throw in casgstatus, the
program below dies in a few seconds (2-10) with GOMAXPROCS=8
on a 2012 Retina MacBook Pro. With the fix, it runs for minutes
and minutes.
package main
import (
"io"
"log"
"net"
"runtime"
)
func main() {
const N = 100
for i := 0; i < N; i++ {
l, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
log.Fatal(err)
}
ch := make(chan net.Conn, 1)
go func() {
var err error
c1, err := net.Dial("tcp", l.Addr().String())
if err != nil {
log.Fatal(err)
}
ch <- c1
}()
c2, err := l.Accept()
if err != nil {
log.Fatal(err)
}
c1 := <-ch
l.Close()
go netguy(c1, c2)
go netguy(c2, c1)
c1.Write(make([]byte, 100))
}
for {
runtime.GC()
}
}
func netguy(r, w net.Conn) {
buf := make([]byte, 100)
for {
bigstack(1000)
_, err := io.ReadFull(r, buf)
if err != nil {
log.Fatal(err)
}
w.Write(buf)
}
}
var g int
func bigstack(n int) {
var buf [100]byte
if n > 0 {
bigstack(n - 1)
}
g = int(buf[0]) + int(buf[99])
}
Fixes #9186.
LGTM=rlh
R=austin, rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/179680043
Austin Clements [Tue, 25 Nov 2014 21:00:25 +0000 (16:00 -0500)]
[dev.cc] 9l: make R_CALLPOWER like ELF's R_PPC64_REL24
These accomplished the same thing, but R_CALLPOWER expected
the whole instruction to be in the addend (and completely
overwrote what was in the text section), while R_PPC64_REL24
overwrites only bits 6 through 24 of whatever was in the text
section. Make R_CALLPOWER work like R_PPC64_REL24 to ease the
implementation of dynamic linking.
David du Colombier [Tue, 25 Nov 2014 07:42:00 +0000 (08:42 +0100)]
[dev.cc] cmd/5g,cmd/6g,cmd/9g: fix warnings on Plan 9
warning: src/cmd/5g/reg.c:461 format mismatch d VLONG, arg 5
warning: src/cmd/6g/reg.c:396 format mismatch d VLONG, arg 5
warning: src/cmd/9g/reg.c:440 format mismatch d VLONG, arg 5
Austin Clements [Mon, 24 Nov 2014 16:40:36 +0000 (11:40 -0500)]
[dev.cc] 9g: fill progtable for CC, V, and VCC instruction variants
This adds some utilities for converting between the CC, V, and
VCC variants of operations and uses these to derive the
ProgInfo entries for these variants (which are identical to
the ProgInfo for the base operations).
The 9g peephole optimizer will also use these conversion
utilities.
David du Colombier [Fri, 21 Nov 2014 19:56:33 +0000 (20:56 +0100)]
[dev.cc] liblink: fix warnings on Plan 9
warning: src/liblink/list6.c:94 set and not used: s
warning: src/liblink/list6.c:157 format mismatch ld VLONG, arg 3
warning: src/liblink/list6.c:157 format mismatch E UINT, arg 4
warning: src/liblink/list6.c:157 format mismatch d VLONG, arg 5
warning: src/liblink/list6.c:163 set and not used: s
warning: src/liblink/list9.c:105 set and not used: s
warning: src/liblink/list9.c:185 format mismatch ld VLONG, arg 3
warning: src/liblink/list9.c:185 format mismatch E UINT, arg 4
warning: src/liblink/list9.c:185 format mismatch d VLONG, arg 5
warning: src/liblink/list9.c:193 set and not used: s
Dmitriy Vyukov [Thu, 20 Nov 2014 14:51:02 +0000 (09:51 -0500)]
runtime: fix atomic operations on non-heap addresses
Race detector runtime does not tolerate operations on addresses
that was not previously declared with __tsan_map_shadow
(namely, data, bss and heap). The corresponding address
checks for atomic operations were removed in
https://golang.org/cl/111310044
Restore these checks.
It's tricker than just not calling into race runtime,
because it is the race runtime that makes the atomic
operations themselves (if we do not call into race runtime
we skip the atomic operation itself as well). So instead we call
__tsan_go_ignore_sync_start/end around the atomic operation.
This forces race runtime to skip all other processing
except than doing the atomic operation itself.
Fixes #9136.
Russ Cox [Wed, 19 Nov 2014 20:25:33 +0000 (15:25 -0500)]
runtime: remove assumption that noptrdata data bss noptrbss are ordered and contiguous
The assumption can be violated by external linkers reordering them or
inserting non-Go sections in between them. I looked briefly at trying
to write out the _go_.o in external linking mode in a way that forced
the ordering, but no matter what there's no way to force Go's data
and Go's bss to be next to each other. If there is any data or bss from
non-Go objects, it's very likely to get stuck in between them.
Instead, rewrite the two places we know about that make the assumption.
I grepped for noptrdata to look for more and didn't find any.
The added race test (os/exec in external linking mode) fails without
the changes in the runtime. It crashes with an invalid pointer dereference.
Austin Clements [Wed, 19 Nov 2014 19:56:49 +0000 (14:56 -0500)]
[dev.cc] runtime: add explicit siginfo.si_addr field
struct siginfo_t's si_addr field is part of a union.
Previously, we represented this union in Go using an opaque
byte array and accessed the si_addr field using unsafe (and
wrong on 386 and arm!) pointer arithmetic. Since si_addr is
the only field we use from this union, this replaces the
opaque byte array with an explicit declaration of the si_addr
field and accesses it directly.
Austin Clements [Wed, 19 Nov 2014 19:24:41 +0000 (14:24 -0500)]
[dev.cc] runtime: decode power64 branch instructions the way the CPU does
Previously, this used the top 8 bits of an instruction as a
sort-of opcode and ignored the top two bits of the relative
PC. This worked because these jumps are always negative and
never big enough for the top two bits of the relative PC (also
the bottom 2 bits of the sort-of opcode) to be anything other
than 0b11, but the code is confusing because it doesn't match
the actual structure of the instruction.
Instead, use the real 6 bit opcode and use all 24 bits of
relative PC.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/179960043
In go1.3, I type enter at the prompt and the program exits.
With the CL being rolled back, the program wedges at the
prompt.
««« original CL description
syscall: SysProcAttr job control changes
Making the child's process group the foreground process group and
placing the child in a specific process group involves co-ordination
between the parent and child that must be done post-fork but pre-exec.
Austin Clements [Wed, 19 Nov 2014 16:30:58 +0000 (11:30 -0500)]
[dev.cc] runtime: allow more address bits in lfstack on Power64
Previously, lfstack assumed Linux limited user space addresses
to 43 bits on Power64 based on a paper from 2001. It turns
out the limit is now 46 bits, so lfstack was truncating
pointers.
Raise the limit to 48 bits (for some future proofing and to
make it match amd64) and add a self-test that will fail in a
useful way if ever unpack(pack(x)) != x.
With this change, dev.cc passes all.bash on power64le.