Skip to content

G
go
Switch branch/tag
  1. 14 Jan, 2016 7 commits
    • Shenghou Ma's avatar
      build: use consistent shebang line · b73d8fbe
      Shenghou Ma authored 
      Fixes #13948.

Change-Id: I37d734c1241f3d72d8fe33dfdf79b573e5476b1f
Reviewed-on: https://go-review.googlesource.com/18643Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      b73d8fbe
    • Andrew Gerrand's avatar
      doc: revise help page with categories and more links · 4a8c15e0
      Andrew Gerrand authored 
      Fixes #12489

Change-Id: I25dd3f76e4cfe9a71b987c3b31445724568391e9
Reviewed-on: https://go-review.googlesource.com/18625Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      4a8c15e0
    • Russ Cox's avatar
      doc: document archive/tar changes · 353ee32f
      Russ Cox authored 
      Fixes #13647.

Change-Id: I28df7ade9b5abd79ce6b9c3d14ceaa988e86fc01
Reviewed-on: https://go-review.googlesource.com/18642
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAndrew Gerrand <adg@golang.org>
      353ee32f
    • Austin Clements's avatar
      debug/dwarf: fix nil pointer dereference in cyclic type structures · 535741a6
      Austin Clements authored 
      Currently readType simultaneously constructs a type graph and resolves
the sizes of the types. However, these two operations are
fundamentally at odds: the order we parse a cyclic structure in may be
different than the order we need to resolve type sizes in. As a
result, it's possible that when readType attempts to resolve the size
of a typedef, it may dereference a nil Type field of another typedef
retrieved from the type cache that's only partially constructed.

To fix this, we delay resolving typedef sizes until the end of the
readType recursion, when the full type graph is constructed.

Fixes #13039.

Change-Id: I9889af37fb3be5437995030fdd61e45871319d07
Reviewed-on: https://go-review.googlesource.com/18459Reviewed-by: default avatarRuss Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      535741a6
    • Russ Cox's avatar
      cmd/compile: add AVARLIVE to peep for arm, arm64, mips64, ppc64 · 5f23bc89
      Russ Cox authored 
      Fixes build on those systems.

Also fix printing of AVARLIVE.

Change-Id: I1b38cca0125689bc08e4e1bdd0d0c140b1ea079a
Reviewed-on: https://go-review.googlesource.com/18641Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      5f23bc89
    • Russ Cox's avatar
      cmd/internal/obj: separate code layout from object writing · ed03dab8
      Russ Cox authored 
      This will allow the compiler to crunch Prog lists down to code as each
function is compiled, instead of waiting until the end, which should
reduce the working set of the compiler. But not until Go 1.7.

This also makes it easier to write some machine code output tests
for the assembler, which is why it's being done now.

For #13822.

Change-Id: I0811123bc6e5717cebb8948f9cea18e1b9baf6f7
Reviewed-on: https://go-review.googlesource.com/18311Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      ed03dab8
    • Russ Cox's avatar
      cmd/compile: recognize Syscall-like functions for liveness analysis · 1ac637c7
      Russ Cox authored 
      Consider this code:

	func f(*int)

	func g() {
		p := new(int)
		f(p)
	}

where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).

Now consider this code:

	func h1() {
		p := new(int)
		syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
	}

Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.

We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.

The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:

	func h2() {
		p := new(int)
		syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
		use(unsafe.Pointer(p))
	}

Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.

Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).

This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.

Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.

For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).

The rule has no effect on escape analysis, only on liveness analysis.

Fixes #13372.

Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      1ac637c7
  3. 13 Jan, 2016 27 commits
  5. 12 Jan, 2016 6 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7