mips64 strace doesn't support sendfile64 and will error out if we
specify that with `-e trace='. So we use sendfile for mips64 here.

Change-Id: If5e2bb39866ca3a77dcc40e4db338ba486921d89
Reviewed-on: https://go-review.googlesource.com/14455Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I77c6768fff6f0163b36800307c4d573bb6521fe5
Reviewed-on: https://go-review.googlesource.com/14454Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I05352749a852095baae2f67fd71ffcf5f727538d
Reviewed-on: https://go-review.googlesource.com/14453Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I84ced3734410d3d05f195901f44d33f4ae6036b1
Reviewed-on: https://go-review.googlesource.com/14452Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I5129a5b9dbbc57d97da723c2fc247bd28f951817
Reviewed-on: https://go-review.googlesource.com/14451Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: Ibe6c345afd4cbae7e2542a350043fbb6b81d5678
Reviewed-on: https://go-review.googlesource.com/14450Reviewed-by: Minux Ma <minux@golang.org>

Syscall getdents64 is relatively new in linux/mips64, only since kernel
version 3.10. To support older kernel, syscall getdents is used for
mips64.

Change-Id: I892b05dff7d93e7ddb0d700abd6a5e6d4084ab4c
Reviewed-on: https://go-review.googlesource.com/14449Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I574a2b702bb3db596f890ae7b18fb4bc1fd358d5
Reviewed-on: https://go-review.googlesource.com/14448Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Linux/mips64 uses a different signal table. To avoid code copying,
signal table is factored out from signal_linux.go to
sigtab_linux_generic.go. And a mips64-specific version is added.

Change-Id: I842d7a7467c330bf772855fde01aecc77a42316b
Reviewed-on: https://go-review.googlesource.com/14993Reviewed-by: Ian Lance Taylor <iant@golang.org>

Linux/mips64 has a different sigset type and some different constants.
os2_linux.go is renamed to os2_linux_generic.go, and not used in mips64.
The corresponding file os2_linux_mips64x.go is added.

Change-Id: Ief83845a2779f7fe048d236d3c7da52b627ab533
Reviewed-on: https://go-review.googlesource.com/14992Reviewed-by: Minux Ma <minux@golang.org>

Linux/mips64 uses a different type of sigset. To deal with it, related
functions in os1_linux.go is refactored to os1_linux_generic.go
(used for non-mips64 architectures), and os1_linux_mips64x.go (only used
in mips64{,le}), to avoid code copying.

Change-Id: I5cadfccd86bfc4b30bf97e12607c3c614903ea4c
Reviewed-on: https://go-review.googlesource.com/14991Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I381c03d957a0dccae5f655f02e92760e5c0e9629
Reviewed-on: https://go-review.googlesource.com/14929Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

files for unsupported architectures are deleted, as it would require
changing cmd/dist to recognize their names as build tags (probably
need a separated CL).

Change-Id: Ifd164b014867d39b4924d1b859fb84317dce4ab0
Reviewed-on: https://go-review.googlesource.com/14928Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I14b537922b97d4bce9e0523d98a822da906348f1
Reviewed-on: https://go-review.googlesource.com/14447Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: Ia496470e48b3c5d39fb9fef99fac356dfb73a949
Reviewed-on: https://go-review.googlesource.com/14927Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I2eaf0658771a0ff788429e2f503d116531166315
Reviewed-on: https://go-review.googlesource.com/16834Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I9e94027ef66c88007107de2b2b75c3d7cf1352af
Reviewed-on: https://go-review.googlesource.com/14467Reviewed-by: Minux Ma <minux@golang.org>

The actual cgo is not supported for now. This is just the cgo command.

Change-Id: I25625100ee552971f47e681b7d613cba16a2132f
Reviewed-on: https://go-review.googlesource.com/14446Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

It is based on ppc64 compiler.

Change-Id: I15a101df05f2919ba5292136957ba0009227d067
Reviewed-on: https://go-review.googlesource.com/14445Reviewed-by: Minux Ma <minux@golang.org>

Only internal linking without cgo is supported for now.

Change-Id: Ie6074a8ff3ec13605b72028f2d60758034f87185
Reviewed-on: https://go-review.googlesource.com/14444Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I951387f88993715e86b6ab9f18d38ed5c691ee0f
Reviewed-on: https://go-review.googlesource.com/14443Reviewed-by: Minux Ma <minux@golang.org>

MIPS64 has 32 general purpose 64-bit integer registers (R0-R31), 32
64-bit floating point registers (F0-F31). Instructions are fixed-width,
and are 32-bit wide. Instructions are all in standard 1-, 2-, 3-operand
forms.

MIPS64-specific relocations are added. For this reason, test data of
cmd/newlink are regenerated.

No other changes are made to portable structures.

Branch delay slots are current filled with NOP instructions. The function
for instruction scheduling (try to fill the delay slot with a useful
instruction) is implemented but disabled for now.

Change-Id: Ic364999c7a33245260c1381fc26a2fa8972d38b3
Reviewed-on: https://go-review.googlesource.com/14442Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: Ie5f70af7e673bb2c691a45c28db2c017e6cddd4f
Reviewed-on: https://go-review.googlesource.com/16833Reviewed-by: Minux Ma <minux@golang.org>

Applies to types fixAlloc, mCache, mCentral, mHeap, mSpan, and
mSpanList.

Two special cases:

1. mHeap_Scavenge() previously didn't take an *mheap parameter, so it
was specially handled in this CL.

2. mHeap_Free() would have collided with mheap's "free" field, so it's
been renamed to (*mheap).freeSpan to parallel its underlying
(*mheap).freeSpanLocked method.

Change-Id: I325938554cca432c166fe9d9d689af2bbd68de4b
Reviewed-on: https://go-review.googlesource.com/16221Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

It was disabled because of the lack of external linking.

Change-Id: Iccb4a4ef8c57d048d53deabe4e0f4e6b9dccce33
Reviewed-on: https://go-review.googlesource.com/16797Reviewed-by: Ian Lance Taylor <iant@golang.org>

If you say "go install -buildmode=shared a b" and package a depends on another
package c, package c is implicitly included in the resulting shared library (as
specified by "Go Execution Modes"). But if c depends on b, linking against this
shared library hangs, because the go tool doesn't know when computing c's
dependencies that c is part of the same shared library as c.

Fix this by tracking the shared library a package *is* in separately from the
shared library a package has been explicitly linked into.

Fixes #13044

Change-Id: Iacfedab24ae9731ed53d225678b447a2a888823c
Reviewed-on: https://go-review.googlesource.com/16338
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

I want to use CX as a scratch register in position independent code and these
uses are easy to remove.

Change-Id: I9e3cb470d7f0000d85786c30bd769d9ec86d532a
Reviewed-on: https://go-review.googlesource.com/16382Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The linker writes the number of file symbols (Nhistfile) to the filetab slice
and then Nhistfile offsets -- which means the slice contains Nhistfile+1
entries, not just Nhistfile.

I think this bug has been around since at least 1.4 but it's easier to trigger
with shared libraries and a tiny binary that only has a couple of functions in
it -- try go install -buildmode=shared std && go run -linkshared test/fixedbugs/issue4388.go.

Change-Id: I6c0f01f1e607b9b2b96872e37ffce81281911504
Reviewed-on: https://go-review.googlesource.com/16342
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Update golang/go#9327.

Change-Id: I27ef973190d9ae652411caf3739414b5d46ca7d2
Reviewed-on: https://go-review.googlesource.com/16679Reviewed-by: David Crawshaw <crawshaw@golang.org>

Same ugly hack as https://go-review.googlesource.com/15991.

Update golang/go#9327.

Change-Id: I58284e83268a15de95eabc833c3e01bf1e3faa2e
Reviewed-on: https://go-review.googlesource.com/16678Reviewed-by: David Crawshaw <crawshaw@golang.org>

The GC now handles the root marking jobs as part of general marking,
so work.markfor is no longer used.

Change-Id: I6c3b23fed27e4e7ea6430d6ca7ba25ae4d04ed14
Reviewed-on: https://go-review.googlesource.com/16811
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When we're jumping time forward, it means everyone is asleep, so there
should always be an M available. Furthermore, this causes both
allocation and write barriers in contexts that may be running without
a P (such as in sysmon).

Hence, replace this allocation with a throw.

Updates #10600.

Change-Id: I2cee70d5db828d0044082878995949edb25dda5f
Reviewed-on: https://go-review.googlesource.com/16815Reviewed-by: Russ Cox <rsc@golang.org>

Currently traceBuf keeps track of where it is in the trace buffer by
also maintaining a slice that points in to this buffer with an initial
length of 0 and a cap of the length of the array. All writes to this
buffer are done by appending to the slice (as long as the bounds
checks are right, it will never overflow and the append won't allocate
a new slice).

Each of these appends generates a write barrier. As long as we never
overflow the buffer, this write barrier won't fire, but this wreaks
havoc with eliminating write barriers from the tracing code. If we
were to overflow the buffer, this would both allocate and invoke a
write barrier, both things that are dicey at best to do in many of the
contexts tracing happens. It also wastes space in the traceBuf and
leads to more complex code and more complex generated code.

Replace this slice trick with keeping track of a simple array
position.

Updates #10600.

Change-Id: I0a63eecec1992e195449f414ed47653f66318d0e
Reviewed-on: https://go-review.googlesource.com/16814
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

This replaces *traceStack with traceStackPtr, much like the preceding
commit.

Updates #10600.

Change-Id: Ifadc35eb37a405ae877f9740151fb31a0ca1d08f
Reviewed-on: https://go-review.googlesource.com/16813
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

The tracing code is currently called from contexts such as sysmon and
the scheduler where write barriers are not allowed. Unfortunately,
while the common paths through the tracing code do not have write
barriers, many of the less common paths dealing with buffer overflow
and recycling do.

This change replaces all *traceBufs with traceBufPtrs. In the style of
guintptr, etc., the GC does not trace traceBufPtrs and write barriers
do not apply when these pointers are written. Since traceBufs are
allocated from non-GC'd memory and manually managed, this is always
safe.

Updates #10600.

Change-Id: I52b992d36d1b634ebd855c8cde27947ec14f59ba
Reviewed-on: https://go-review.googlesource.com/16812
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Mention shallow clones.

Fixes #13204

Change-Id: I0ed9d4e829d388425beba0d64e6889d16d4bb173
Reviewed-on: https://go-review.googlesource.com/16822Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Commit 7407d8e5 was rebased over the switch to runtime/internal/atomic
and introduced a call to xadd64, which no longer exists. Fix that
call.

Change-Id: I99c93469794c16504ae4a8ffe3066ac382c66a3a
Reviewed-on: https://go-review.googlesource.com/16816Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently, sweeping is performed before allocating a span by charging
for the entire size of the span requested, rather than the number of
bytes actually available for allocation from the returned span. That
is, if the returned span is 8K, but already has 6K in use, the mutator
is charged for 8K of heap allocation even though it can only allocate
2K more from the span. As a result, proportional sweep is
over-aggressive and tends to finish much earlier than it needs to.
This effect is more amplified by fragmented heaps.

Fix this by reimbursing the mutator for the used space in a span once
it has allocated that span. We still have to charge up-front for the
worst-case because we don't know which span the mutator will get, but
at least we can correct the over-charge once it has a span, which will
go toward later span allocations.

This has negligible effect on the throughput of the go1 benchmarks and
the garbage benchmark.

Fixes #12040.

Change-Id: I0e23e7a4ccf126cca000fed5067b20017028dd6b
Reviewed-on: https://go-review.googlesource.com/16515Reviewed-by: Rick Hudson <rlh@golang.org>

Currently go get will clone the full history of git repos.
We can improve the download waiting time/size by passing depth argument.

The docs about shallow clones and the --depth argument are here:
https://git-scm.com/docs/git-clone
https://git-scm.com/docs/git-pull

Fixes #13078

Change-Id: Ie891d905d9c77f6ecadf7dcd5b44b477f4e079e0
Reviewed-on: https://go-review.googlesource.com/16360Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The runtime is not instrumented, but the calls to msanread in the
runtime can sometimes refer to the system stack.  An example is the call
to copy in stkbucket in mprof.go.  Depending on what C code has done,
the system stack may appear uninitialized to msan.

Change-Id: Ic21705b9ac504ae5cf7601a59189302f072e7db1
Reviewed-on: https://go-review.googlesource.com/16660Reviewed-by: David Crawshaw <crawshaw@golang.org>