Skip to content

G
go
Switch branch/tag
  1. 06 Jul, 2019 1 commit
  3. 05 Jul, 2019 5 commits
    • Austin Clements's avatar
      cmd/cgo: accept weak dynamic imports · a2fb5cd8
      Austin Clements authored 
      cgo produces dynamic imports for Go binaries by scanning the dynamic
imports table of a binary produced by the system C compiler and
linker. Currently, since it uses elf.File.ImportedSymbols, it only
reads global symbols. Unfortunately, recent versions of lld emit weak
symbol imports for several pthread symbols, which means the cgo tool
doesn't emit dynamic imports for them, which ultimately causes linking
of cgo binaries to fail.

Fix this by using elf.File.DynamicSymbols instead and filtering down
to both global and weak symbols.

Fixes #31912.

Change-Id: If346a7eca6733e3bfa2cccf74a9cda02a3e81d38
Reviewed-on: https://go-review.googlesource.com/c/go/+/184100
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      a2fb5cd8
    • Austin Clements's avatar
      debug/elf: add version information to all dynamic symbols · 7aac3436
      Austin Clements authored 
      Currently, File.ImportedSymbols is the only API that exposes the GNU
symbol version information for dynamic symbols. Unfortunately, it also
filters to specific types of symbols, and only returns symbol names.

The cgo tool is going to need symbol version information for more
symbols. In order to support this and make the API more orthogonal,
this CL adds version information to the Symbol type and updates
File.DynamicSymbols to fill this in. This has the downside of
increasing the size of Symbol, but seems to be the most natural API
for exposing this. I also explored 1) adding a method to get the
version information for the i'th dynamic symbol, but we don't use
symbol indexes anywhere else in the API, and it's not clear if this
index would be 0-based or 1-based, and 2) adding a
DynamicSymbolVersions method that returns a slice of version
information that parallels the DynamicSymbols slice, but that's less
efficient to implement and harder to use.

For #31912.

Change-Id: I69052ac3894f7af2aa9561f7085275130e0cf717
Reviewed-on: https://go-review.googlesource.com/c/go/+/184099
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      7aac3436
    • Keith Randall's avatar
      test: add another test for issue 32680 · 9a00e646
      Keith Randall authored 
      Update #32680

Change-Id: I0318c22c22c5cd6ab6441d1aa2d1a40d20d71242
Reviewed-on: https://go-review.googlesource.com/c/go/+/185137
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: default avatarDavid Chase <drchase@google.com>
      9a00e646
    • Mohit Agarwal's avatar
      doc/go1.13: fix links and a closing tag · e94472a3
      Mohit Agarwal authored 
      - fix link for `Time.Format`
- fix closing tag for `go get`
- add links for `runtime.Caller`, `runtime.Callers`
- remove link for `TypedArrayOf` since it has been removed (CL 177537)

Change-Id: I1dc38226e6d91c68fbd2f02c1acfad5327f4ebe8
Reviewed-on: https://go-review.googlesource.com/c/go/+/185038Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
      e94472a3
    • Patrik Lundin's avatar
      net/http: stop ExampleServer_Shutdown from hanging on error · 04e2e81e
      Patrik Lundin authored 
      Running the example code when not having permissions
to bind to port 80 will cause the program to hang after
printing the error message.

Change-Id: I2433ba2629b362fc8f1731e40cab5eea72ec354f
GitHub-Last-Rev: 0bb3dc08b6f646470fc6ff208ea12bca901a2299
GitHub-Pull-Request: golang/go#32947
Reviewed-on: https://go-review.googlesource.com/c/go/+/185157Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      04e2e81e
  5. 03 Jul, 2019 6 commits
  7. 02 Jul, 2019 3 commits
  9. 01 Jul, 2019 2 commits
  11. 30 Jun, 2019 1 commit
    • Ian Lance Taylor's avatar
      runtime: use a pipe to wake up signal_recv on Darwin · c485e8b5
      Ian Lance Taylor authored 
      The implementation of semaphores, and therefore notes, used on Darwin
is not async-signal-safe. The runtime has one case where a note needs
to be woken up from a signal handler: the call to notewakeup in sigsend.
That notewakeup call is only called on a single note, and it doesn't
need the full functionality of notes: nothing ever does a timed wait on it.
So change that one note to use a different implementation on Darwin,
based on a pipe. This lets the wakeup code use the write call, which is
async-signal-safe.

Fixes #31264

Change-Id: If705072d7a961dd908ea9d639c8d12b222c64806
Reviewed-on: https://go-review.googlesource.com/c/go/+/184169
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      c485e8b5
  13. 29 Jun, 2019 1 commit
    • Russ Cox's avatar
      crypto/tls: deflake localPipe in tests · 623d653d
      Russ Cox authored 
      The localPipe implementation assumes that every successful net.Dial
results in exactly one successful listener.Accept. I don't believe this
is guaranteed by essentially any operating system. For this test, we're
seeing flakes on dragonfly (#29583).

But see also #19519, flakes due to the same assumption on FreeBSD
and macOS in package net's own tests.

This CL rewrites localPipe to try a few times to get a matching pair
of connections on the dial and accept side.

Fixes #29583.

Change-Id: Idb045b18c404eae457f091df20456c5ae879a291
Reviewed-on: https://go-review.googlesource.com/c/go/+/184157
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      623d653d
  15. 28 Jun, 2019 3 commits
    • Russ Cox's avatar
      net: deflake TestVariousDeadlines · 2e0cd2ae
      Russ Cox authored 
      TestVariousDeadlines starts a client and server.
The client dials the server, sets a timeout on the connection,
reads from it, gets a timeout error, closes the connection.
The server writes an infinite stream of a's to each connection
it accepts.

The test was trying to run these in lockstep:
run a client dial+read+timeout+close,
wait for server to accept+write+error out on write to closed connection,
repeat.

On FreeBSD 11.2 and less frequently on macOS we see
the test timeout waiting for the server to do its half of
the lockstep dance.

I believe the problem is that the client can do its step
of the dance with such a short timeout that the read,
timeout, and close happens before the server ever returns
from the accept(2) system call. For the purposes of testing
the client-side read timeout, this is fine. But I suspect
that under some circumstances, the "TCP-accepted"
connection does not translate into a "socket-layer-accepted"
connection that triggers a return from accept(2).
That is, the Go server never sees the connection at all.
And the test sits there waiting for it to acknowledge
being done with a connection it never started with.

Fix the problem by not trying to lockstep with the server.

This definitely fixes the flake, since the specific line that
was calling t.Fatal is now deleted.

This exposes a different flake, seen on a trybot run for an
early version of this CL, in which the client's io.Copy does
not stop within the time allotted. The problem now is that
there is no guarantee that a read beyond the deadline with
available data returns an error instead of the available data,
yet the test assumes this guarantee, and in fact the opposite
is usually true - we don't bother checking the deadline unless
the read needs to block. That is, deadlines don't cut off a
flood of available data, yet this test thinks they do.

This CL therefore also changes the server not to send an
infinite flood of data - don't send any data at all - so that
the read deadline is guaranteed to be exercised.

Fixes #19519.

Change-Id: I58057c3ed94ac2aebab140ea597f317abae6e65e
Reviewed-on: https://go-review.googlesource.com/c/go/+/184137
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      2e0cd2ae
    • Russ Cox's avatar
      runtime: fix pprof cpu profile corruption on arm/mips/mipsle · 91c385b3
      Russ Cox authored 
      CL 42652 changed the profile handler for mips/mipsle to
avoid recording a profile when in atomic functions, for fear
of interrupting the 32-bit simulation of a 64-bit atomic with
a lock. The profile logger itself uses 64-bit atomics and might
deadlock (#20146).

The change was to accumulate a count of dropped profile events
and then send the count when the next ordinary event was sent:

	if prof.hz != 0 {
	+	if (GOARCH == "mips" || GOARCH == "mipsle") && lostAtomic64Count > 0 {
	+		cpuprof.addLostAtomic64(lostAtomic64Count)
	+		lostAtomic64Count = 0
	+	}
 		cpuprof.add(gp, stk[:n])
 	}

CL 117057 extended this behavior to include GOARCH == "arm".

Unfortunately, the inserted cpuprof.addLostAtomic64 differs from
the original cpuprof.add in that it neglects to acquire the lock
protecting the profile buffer.

This has caused a steady stream of flakes on the arm builders
for the past 12 months, ever since CL 117057 landed.

This CL moves the lostAtomic count into the profile buffer and
then lets the existing addExtra calls take care of it, instead of
duplicating the locking logic.

Fixes #24991.

Change-Id: Ia386c40034fcf46b31f080ce18f2420df4bb8004
Reviewed-on: https://go-review.googlesource.com/c/go/+/184164
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      91c385b3
    • Dmitri Shuralyov's avatar
      cmd/doc: provide working directory to build.Import calls · 3b040b7e
      Dmitri Shuralyov authored 
      The current cmd/doc implementation uses go/build.Import in a few
places to check whether a package is findable and importable.
go/build has limited support for finding packages in modules,
but to do so, build.Import requires knowing the source directory
to use when performing the lookup (so it can find the go.mod file).
Otherwise, it only looks inside the GOPATH workspace.

Start passing the current working directory to build.Import calls,
so that it can correctly look for packages in modules when in cmd/doc
is executed in module mode.

Before this change, cmd/doc in module mode could mistakenly find and
use a package in the GOPATH workspace, instead of the current module.

Since the result of os.Getwd is needed in even more places, assign it
to a local variable in parseArgs now.

Fixes #28992
Updates #26504

Change-Id: I7571618e18420d2d3b3890cc69ade2d97b1962bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/183991
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      3b040b7e
  17. 27 Jun, 2019 7 commits
  19. 26 Jun, 2019 11 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7