Russ Cox [Fri, 14 Nov 2014 17:09:42 +0000 (12:09 -0500)]
[dev.garbage] all: merge dev.power64 (7667e41f3ced) into dev.garbage
Now the only difference between dev.cc and dev.garbage
is the runtime conversion on the one side and the
garbage collection on the other. They both have the
same set of changes from default and dev.power64.
Austin Clements [Thu, 13 Nov 2014 18:34:20 +0000 (13:34 -0500)]
[dev.power64] 6g,8g: remove unnecessary and incorrect reg use scanning
Previously, the 6g and 8g registerizers scanned for used
registers beyond the end of a region being considered for
registerization. This ancient artifact was copied from the C
compilers, where it was probably necessary to track implicitly
used registers. In the Go compilers it's harmless (because it
can only over-restrict the set of available registers), but no
longer necessary because the Go compilers correctly track
register use/set information. The consequences of this extra
scan were (at least) that 1) we would not consider allocating
the AX register if there was a deferproc call in the future
because deferproc uses AX as a return register, so we see the
use of AX, but don't track that AX is set by the CALL, and 2)
we could not consider allocating the DX register if there was
a MUL in the future because MUL implicitly sets DX and (thanks
to an abuse of copyu in this code) we would also consider DX
used.
This commit fixes these problems by nuking this code.
Adam Langley [Sun, 9 Nov 2014 01:12:23 +0000 (17:12 -0800)]
lib/codereview: fix with more recent hg revisions.
I've Mercurial version 3.2 and hg submit fails with:
File "/home/agl/devel/go/lib/codereview/codereview.py", line 3567, in get_hg_status
ret = hg_commands.status(fui, self.repo, *[], **{'rev': [rev], 'copies': True})
File "/usr/lib/python2.7/site-packages/mercurial/commands.py", line 5714, in status
fm = ui.formatter('status', opts)
File "/home/agl/devel/go/lib/codereview/codereview.py", line 3464, in formatter
return plainformatter(self, topic, opts)
File "/usr/lib/python2.7/site-packages/mercurial/formatter.py", line 57, in __init__
if ui.debugflag:
AttributeError: 'FakeMercurialUI' object has no attribute 'debugflag'
This change dumbly adds a boolean debugflag and that seems to work.
Austin Clements [Fri, 7 Nov 2014 15:43:55 +0000 (10:43 -0500)]
[dev.power64] 5g: fix mistaken bit-wise AND in regopt
Replace a bit-wise AND with a logical one. This happened to
work before because bany returns 0 or 1, but the intent here
is clearly logical (and this makes 5g match with 6g and 8g).
Russ Cox [Fri, 7 Nov 2014 00:56:55 +0000 (19:56 -0500)]
cmd/objdump, cmd/pprof: factor disassembly into cmd/internal/objfile
Moving so that new Go 1.4 pprof can use it.
The old 'GNU objdump workalike' mode for 'go tool objdump'
is now gone, as are the tests for that mode. It was used only
by pre-Go 1.4 pprof. You can still specify an address range on
the command line; you just get the same output format as
you do when dumping the entire binary (without an address
limitation).
Austin Clements [Thu, 6 Nov 2014 19:37:39 +0000 (14:37 -0500)]
[dev.power64] gc: fix etype of strings
The etype of references to strings was being incorrectly set
to TINT32 on all platforms. Change it to TSTRING. It seems
this doesn't matter for compilation, since x86 uses LEA
instructions to load string addresses and arm and power64
disassemble the string into its constituent pieces (with the
correct types), but it helps when debugging.
Keith Randall [Thu, 6 Nov 2014 17:30:41 +0000 (09:30 -0800)]
runtime: don't stop bitmap dump at BitsDead
Stack bitmaps need to be scanned past any BitsDead entries.
Object bitmaps will not have any BitsDead in them (bitmap extraction stops at
the first BitsDead entry in makeheapobjbv). data/bss bitmaps also have no BitsDead entries.
Keith Randall [Thu, 6 Nov 2014 04:25:20 +0000 (20:25 -0800)]
os/exec: tell lsof not to block
For some reason lsof is now hanging on my workstation
without the -b (avoid blocking in the kernel) option.
Adding -b makes the test pass and shouldn't hurt.
I don't know how recent the -b option is. If the builders
are ok with it, it's probably ok.
Russ Cox [Thu, 6 Nov 2014 04:01:48 +0000 (23:01 -0500)]
runtime: avoid gentraceback of self on user goroutine stack
Gentraceback may grow the stack.
One of the gentraceback wrappers may grow the stack.
One of the gentraceback callback calls may grow the stack.
Various stack pointers are stored in various stack locations
as type uintptr during the execution of these calls.
If the stack does grow, these stack pointers will not be
updated and will start trying to decode stack memory that
is no longer valid.
It may be possible to change the type of the stack pointer
variables to be unsafe.Pointer, but that's pretty subtle and
may still have problems, even if we catch every last one.
An easier, more obviously correct fix is to require that
gentraceback of the currently running goroutine must run
on the g0 stack, not on the goroutine's own stack.
Not doing this causes faults when you set
StackFromSystem = 1
StackFaultOnFree = 1
The new check in gentraceback will catch future lapses.
The more general problem is calling getcallersp but then
calling a function that might relocate the stack, which would
invalidate the result of getcallersp. Add note to stubs.go
declaration of getcallersp explaining the problem, and
check all existing calls to getcallersp. Most needed fixes.
This affects Callers, Stack, and nearly all the runtime
profiling routines. It does not affect stack copying directly
nor garbage collection.
LGTM=khr
R=khr, bradfitz
CC=golang-codereviews, r
https://golang.org/cl/167060043
Rob Pike [Wed, 5 Nov 2014 22:57:46 +0000 (09:57 +1100)]
bufio: don't loop generating empty tokens
The new rules for split functions mean that we are exposed
to the common bug of a function that loops forever at EOF.
Pick these off by shutting down the scanner if too many
consecutive empty tokens are delivered.
Austin Clements [Wed, 5 Nov 2014 20:36:47 +0000 (15:36 -0500)]
[dev.power64] 6g: don't create variables for indirect addresses
Previously, mkvar treated, for example, 0(AX) the same as AX.
As a result, a move to an indirect address would be marked as
*setting* the register, rather than just using it, resulting
in unnecessary register moves. Fix this by not producing
variables for indirect addresses.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/164610043
Austin Clements [Wed, 5 Nov 2014 20:14:47 +0000 (15:14 -0500)]
5g: don't generate reg variables for direct-called functions
The test intended to skip direct calls when creating
registerization variables was testing p->to.type instead of
p->to.name, so it always failed, causing regopt to create
unnecessary variables for these names.
Russ Cox [Wed, 5 Nov 2014 19:42:54 +0000 (14:42 -0500)]
[dev.garbage] cmd/gc, runtime: add locks around print statements
Now each C printf, Go print, or Go println is guaranteed
not to be interleaved with other calls of those functions.
This should help when debugging concurrent failures.
Austin Clements [Tue, 4 Nov 2014 21:34:56 +0000 (16:34 -0500)]
[dev.power64] gc: convert Bits to a uint64 array
So far all of our architectures have had at most 32 registers,
so we've been able to use entry 0 in the Bits uint32 array
directly as a register mask. Power64 has 64 registers, so
this converts Bits to a uint64 array so we can continue to use
entry 0 directly as a register mask on Power64.
Rick Hudson [Tue, 4 Nov 2014 18:31:34 +0000 (13:31 -0500)]
[dev.garbage] runtime: Add gc mark verification pass.
This adds an independent mark phase to the GC that can be used to
verify the the default concurrent mark phase has found all reachable
objects. It uses the upper 2 bits of the boundary nibble to encode
the mark leaving the lower bits to encode the boundary and the
normal mark bit.
Ian Lance Taylor [Tue, 4 Nov 2014 18:20:35 +0000 (10:20 -0800)]
test: comment out failing cases from sinit.go
One failing case this removes is:
var bytes = []byte("hello, world")
var copy_bytes = bytes
We could handle this in the compiler, but it requires special
case for a variable that is initialized to the value of a
variable that is initialized to a string literal converted to
[]byte. This seems an unlikely case--it never occurs in the
standrd library--and it seems unnecessary to write the code to
handle it.
If we do want to support this case, one approach is
https://golang.org/cl/171840043.
The other failing cases are of the form
var bx bool
var copy_bx = bx
The compiler used to initialize copy_bx to false. However,
that led to issue 7665, since bx may be initialized in non-Go
code. The compiler no longer assumes that bx must be false,
so copy_bx can not be statically initialized.
We can fix these with https://golang.org/cl/169040043
if we also pass -complete to the compiler as part of this
test. This is OK but it's too late in the release cycle.
Austin Clements [Tue, 4 Nov 2014 14:43:37 +0000 (09:43 -0500)]
gc: abort if given an unknown debug (-d) flag
The check for unknown command line debug flags in gc was
incorrect: the loop over debugtab terminates when it reaches a
nil entry, but it was only reporting an error if the parser
had passed the last entry of debugtab (which it never did).
Fix this by reporting the usage error if the loop reaches a
nil entry.
Austin Clements [Mon, 3 Nov 2014 22:25:36 +0000 (17:25 -0500)]
[dev.power64] test: "fix" live.go test on power64x
On power64x, this one line in live.go reports that t is live
because of missing optimization passes. This isn't what this
test is trying to test, so shuffle bad40 so that it still
accomplishes the intent of the test without also depending on
optimization.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/167110043
Austin Clements [Mon, 3 Nov 2014 22:24:13 +0000 (17:24 -0500)]
[dev.power64] liblink: fix printing of branch targets
Print PC stored in target Prog* of branch instructions when
available instead of the offset stored in the branch
instruction. The offset tends to be wrong after code
transformations, so previously this led to confusing listings.
Austin Clements [Mon, 3 Nov 2014 20:48:51 +0000 (15:48 -0500)]
[dev.power64] 9g: fix nilopt
Previously, nilopt was disabled on power64x because it threw
away "seemly random segments of code." Indeed, excise on
power64x failed to preserve the link field, so it excised not
only the requested instruction but all following instructions
in the function. Fix excise to retain the link field while
otherwise zeroing the instruction.
This makes nilopt safe on power64x. It still fails
nilptr3.go's tests for removal of repeated nil checks because
those depend on also optimizing away repeated loads, which
doesn't currently happen on power64x.
LGTM=dave, rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/168120043
Austin Clements [Mon, 3 Nov 2014 18:26:46 +0000 (13:26 -0500)]
runtime: make Go and C mallocgc signatures match
Previously, the flags argument to mallocgc was an int in Go,
but a uint32 in C. Change the Go type to use uint32 so these
agree. The largest flag value is 2 (and of course no flag
values are negative), so this won't change anything on little
endian architectures, but it matters on big endian.
Austin Clements [Fri, 31 Oct 2014 20:58:12 +0000 (16:58 -0400)]
[dev.power64] runtime: fix gcinfo_test on power64x
The GC info masks for slices and strings were changed in
commit caab29a25f68, but the reference masks used by
gcinfo_test for power64x hadn't caught up. Now they're
identical to amd64, so this CL fixes this test by combining
the reference masks for these platforms.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162620044
Austin Clements [Fri, 31 Oct 2014 19:29:03 +0000 (15:29 -0400)]
[dev.power64] reflect: fix asm on power64x
reflect/asm_power64x.s was missing changes made to other
platforms for stack maps. This CL ports those changes. With
this fix, the reflect test passes on power64x.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/170870043
Austin Clements [Fri, 31 Oct 2014 17:39:36 +0000 (13:39 -0400)]
[dev.power64] runtime: fix fastrand1 on power64x
fastrand1 depends on testing the high bit of its uint32 state.
For efficiency, all of the architectures implement this as a
sign bit test. However, on power64, fastrand1 was using a
64-bit sign test on the zero-extended 32-bit state. This
always failed, causing fastrand1 to have very short periods
and often decay to 0 and get stuck.
Fix this by using a 32-bit signed compare instead of a 64-bit
compare. This fixes various tests for the randomization of
select of map iteration.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/166990043
Austin Clements [Fri, 31 Oct 2014 15:08:27 +0000 (11:08 -0400)]
[dev.power64] 9g: fix under-zeroing in clearfat
All three cases of clearfat were wrong on power64x.
The cases that handle 1032 bytes and up and 32 bytes and up
both use MOVDU (one directly generated in a loop and the other
via duffzero), which leaves the pointer register pointing at
the *last written* address. The generated code was not
accounting for this, so the byte fill loop was re-zeroing the
last zeroed dword, rather than the bytes following the last
zeroed dword. Fix this by simply adding an additional 8 byte
offset to the byte zeroing loop.
The case that handled under 32 bytes was also wrong. It
didn't update the pointer register at all, so the byte zeroing
loop was simply re-zeroing the beginning of region. Again,
the fix is to add an offset to the byte zeroing loop to
account for this.
Austin Clements [Thu, 30 Oct 2014 14:45:41 +0000 (10:45 -0400)]
[dev.power64] runtime: match argument/return type signedness in power64x assembly
Previously, the power64x runtime assembly was sloppy about
using sign-extending versus zero-extending moves of arguments
and return values. I think all of the cases that actually
mattered have been fixed in recent CLs; this CL fixes up the
few remaining mismatches.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162480043
Russ Cox [Thu, 30 Oct 2014 14:16:03 +0000 (10:16 -0400)]
[dev.garbage] cmd/gc, runtime: implement write barriers in terms of writebarrierptr
This CL implements the many multiword write barriers by calling
writebarrierptr, so that only writebarrierptr needs the actual barrier.
In lieu of an actual barrier, writebarrierptr checks that the value
being copied is not a small non-zero integer. This is enough to
shake out bugs where the barrier is being called when it should not
(for non-pointer values). It also found a few tests in sync/atomic
that were being too clever.
This CL adds a write barrier for the memory moved during the
builtin copy function, which I forgot when inserting barriers for Go 1.4.
This CL re-enables some write barriers that were disabled for Go 1.4.
Those were disabled because it is possible to change the generated
code so that they are unnecessary most of the time, but we have not
changed the generated code yet. For safety they must be enabled.
None of this is terribly efficient. We are aiming for correct first.
Russ Cox [Thu, 30 Oct 2014 00:37:44 +0000 (20:37 -0400)]
runtime: change top-most return PC from goexit to goexit+PCQuantum
If you get a stack of PCs from Callers, it would be expected
that every PC is immediately after a call instruction, so to find
the line of the call, you look up the line for PC-1.
CL 163550043 now explicitly documents that.
The most common exception to this is the top-most return PC
on the stack, which is the entry address of the runtime.goexit
function. Subtracting 1 from that PC will end up in a different
function entirely.
To remove this special case, make the top-most return PC
goexit+PCQuantum and then implement goexit in assembly
so that the first instruction can be skipped.
Russ Cox [Wed, 29 Oct 2014 22:07:24 +0000 (18:07 -0400)]
cmd/objdump: use cmd/internal/objfile
This removes a bunch of ugly duplicate code.
The end goal is to factor the disassembly code
into cmd/internal/objfile too, so that pprof can use it,
but one step at a time.
Russ Cox [Wed, 29 Oct 2014 19:14:24 +0000 (15:14 -0400)]
runtime: fix line number in first stack frame in printed stack trace
Originally traceback was only used for printing the stack
when an unexpected signal came in. In that case, the
initial PC is taken from the signal and should be used
unaltered. For the callers, the PC is the return address,
which might be on the line after the call; we subtract 1
to get to the CALL instruction.
Traceback is now used for a variety of things, and for
almost all of those the initial PC is a return address,
whether from getcallerpc, or gp->sched.pc, or gp->syscallpc.
In those cases, we need to subtract 1 from this initial PC,
but the traceback code had a hard rule "never subtract 1
from the initial PC", left over from the signal handling days.
Change gentraceback to take a flag that specifies whether
we are tracing a trap.
Change traceback to default to "starting with a return PC",
which is the overwhelmingly common case.
Add tracebacktrap, like traceback but starting with a trap PC.
Use tracebacktrap in signal handlers.
Fixes #7690.
LGTM=iant, r
R=r, iant
CC=golang-codereviews
https://golang.org/cl/167810044