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.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/179030043
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.
Fixes#9133.
LGTM=dneil
R=dneil
CC=dvyukov, golang-codereviews, iant
https://golang.org/cl/179980043
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.
LGTM=minux, rsc
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/179970044
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
Breaks reading from stdin in parent after exec with SysProcAttr{Setpgid: true}.
package main
import (
"fmt"
"os"
"os/exec"
"syscall"
)
func main() {
cmd := exec.Command("true")
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}
cmd.Run()
fmt.Printf("Hit enter:")
os.Stdin.Read(make([]byte, 100))
fmt.Printf("Bye\n")
}
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.
LGTM=iant
R=golang-codereviews, gobot, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/131750044
»»»
LGTM=minux, dneil
R=dneil, minux
CC=golang-codereviews, iant, michael.p.macinnis
https://golang.org/cl/174450043
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.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174430043
This is the power64 component of CL 174950043.
With this, dev.cc compiles on power64 and power64le and passes
most tests if GOGC=off (but crashes in go_bootstrap if GC is
on).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/175290043
Fix a constant conversion error. Add set_{sec,nsec} for
timespec and set_usec for timeval. Fix type of
sigaltstackt.ss_size.
LGTM=rsc
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/180840043
Previously, 9a was the only assembler that had a different
name for RET, causing unnecessary friction in simple files
that otherwise assembled on all architectures. Add RET so
these work on 9a.
This also renames "R30" to "g" to avoid unintentionally
clobbering g in assembly code. This parallels a change made
to 5a.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/178030043
Eventually I'd like almost everything cmd/dist generates
to be done with 'go generate' and checked in, to simplify
the bootstrap process. The only thing cmd/dist really needs
to do is write things like the current experiment info and
the current version.
This is a first step toward that. It replaces the _NaCl etc
constants with generated ones goos_nacl, goos_darwin,
goarch_386, and so on.
LGTM=dave, austin
R=austin, dave, bradfitz
CC=golang-codereviews, iant, r
https://golang.org/cl/174290043
getFunctionSource gathers five lines of "margin" around every
requested sample line. However, if this margin went past the
end of the source file, getFunctionSource would encounter an
io.EOF error and abort with this error, resulting in listings
like
(pprof) list main.main
ROUTINE ======================== main.main in ...
0 8.33s (flat, cum) 99.17% of Total
Error: EOF
(pprof)
Modify the error handling in getFunctionSource so io.EOF is
always considered non-fatal. If it reaches EOF, it simply
returns the lines it has.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/172600043
Turns out it *is* needed because the cmd/link tests expect to find their own files.
««« original CL description
misc/nacl: exclude cmd/link from the test zip.
It does not appear to be necessary, and cmd/link does not appear in release branches.
LGTM=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/176900044
»»»
TBR=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/175870045
It does not appear to be necessary, and cmd/link does not appear in release branches.
LGTM=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/176900044
debug/goobj is not ready to be published but it is
needed for the various binary-reading commands.
Move to cmd/internal/goobj.
(The Go 1.3 release branch deleted it, but that's not
an option anymore due to the command dependencies.
The API is still not vetted nor terribly well designed.)
LGTM=adg, dsymonds
R=adg, dsymonds
CC=golang-codereviews
https://golang.org/cl/174250043
This change works around the "out of fixed registers"
issue with the Plan 9 C compiler on 386, introduced by
the Bits change to uint64 in CL 169060043.
The purpose of this CL is to be able to properly
follow the conversion of the Plan 9 runtime to Go
on the Plan 9 builders.
This CL could be reverted once the Go compilers will
be converted to Go.
Thanks to Nick Owens for investigating this issue.
LGTM=rsc
R=rsc
CC=austin, golang-codereviews, mischief
https://golang.org/cl/177860043
The SudoG used to sit on the stack, so it was cheap to allocated
and didn't need to be cleaned up when finished.
For the conversion to Go, we had to move sudog off the stack
for a few reasons, so we added a cache of recently used sudogs
to keep allocation cheap. But we didn't add any of the necessary
cleanup before adding a SudoG to the new cache, and so the cached
SudoGs had stale pointers inside them that have caused all sorts
of awful, hard to debug problems.
CL 155760043 made sure SudoG.elem is cleaned up.
CL 150520043 made sure SudoG.selectdone is cleaned up.
This CL makes sure SudoG.next, SudoG.prev, and SudoG.waitlink
are cleaned up. I should have done this when I did the other two
fields; instead I wasted a week tracking down a leak they caused.
A dangling SudoG.waitlink can point into a sudogcache list that
has been "forgotten" in order to let the GC collect it, but that
dangling .waitlink keeps the list from being collected.
And then the list holding the SudoG with the dangling waitlink
can find itself in the same situation, and so on. We end up
with lists of lists of unusable SudoGs that are still linked into
the object graph and never collected (given the right mix of
non-trivial selects and non-channel synchronization).
More details in golang.org/issue/9110.
Fixes#9110.
LGTM=r
R=r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/177870043
I just created that redirect, so we can change
it once the wiki moves.
LGTM=bradfitz, khr
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/177780043
The garbage collector is now written in Go.
There is plenty to clean up (just like on dev.cc).
all.bash passes on darwin/amd64, darwin/386, linux/amd64, linux/386.
TBR=rlh
R=austin, rlh, bradfitz
CC=golang-codereviews
https://golang.org/cl/173250043
* _sfloat dispatches to runtime._sfloat2 with the Go calling convention, so the seecond argument is a [15]uint32, not a *[15]uint32.
* adjust _sfloat2 to return the new pc in 68(R13) as expected.
LGTM=rsc
R=minux, austin, rsc
CC=golang-codereviews
https://golang.org/cl/174160043
It's rather unsporting of the kernel to give us a pointer to unaligned memory.
This fixes one crash, the next crash occurs in the soft float emulation.
LGTM=minux, rsc, austin
R=minux, rsc, austin
CC=golang-codereviews
https://golang.org/cl/177730043
warning: src/liblink/asm9.c:501 set and not used: bflag
warning: src/liblink/list9.c:259 format mismatch .5lux INT, arg 4
warning: src/liblink/list9.c:261 format mismatch .5lux INT, arg 3
warning: src/liblink/list9.c:319 more arguments than format VLONG
warning: src/liblink/obj9.c:222 set and not used: autoffset
LGTM=bradfitz, austin
R=rsc, bradfitz
CC=austin, golang-codereviews
https://golang.org/cl/175070043
The pretty printers for these make it hard to understand
what's actually in the fields of these structures. These
"ugly printers" show exactly what's in each field, which can
be useful for understanding and debugging code.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/175780043
This is to reduce the delta between dev.cc and dev.garbage to just garbage collector changes.
These are the files that had merge conflicts and have been edited by hand:
malloc.go
mem_linux.go
mgc.go
os1_linux.go
proc1.go
panic1.go
runtime1.go
LGTM=austin
R=austin
CC=golang-codereviews
https://golang.org/cl/174180043
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.
LGTM=austin
R=austin
CC=golang-codereviews
https://golang.org/cl/172570043
