Skip to content

G
go
Switch branch/tag
  1. 01 May, 2018 26 commits
  3. 30 Apr, 2018 14 commits
    • Brian Kessler's avatar
      math/big: return nil for nonexistent ModInverse · 4d44a872
      Brian Kessler authored 
      Currently, the behavior of z.ModInverse(g, n) is undefined
when g and n are not relatively prime.  In that case, no
ModInverse exists which can be easily checked during the
computation of the ModInverse.  Because the ModInverse does
not indicate whether the inverse exists, there are reimplementations
of a "checked" ModInverse in crypto/rsa.  This change removes the
undefined behavior.  If the ModInverse does not exist, the receiver z
is unchanged and the return value is nil. This matches the behavior of
ModSqrt for the case where the square root does not exist.

name          old time/op    new time/op    delta
ModInverse-4    2.40µs ± 4%    2.22µs ± 0%   -7.74%  (p=0.016 n=5+4)

name          old alloc/op   new alloc/op   delta
ModInverse-4    1.36kB ± 0%    1.17kB ± 0%  -14.12%  (p=0.008 n=5+5)

name          old allocs/op  new allocs/op  delta
ModInverse-4      10.0 ± 0%       9.0 ± 0%  -10.00%  (p=0.008 n=5+5)

Fixes #24922

Change-Id: If7f9d491858450bdb00f1e317152f02493c9c8a8
Reviewed-on: https://go-review.googlesource.com/108996
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      4d44a872
    • Elias Naur's avatar
      runtime: perform crashes outside systemstack · b1d1ec91
      Elias Naur authored 
      CL 93658 moved stack trace printing inside a systemstack call to
sidestep complexity in case the runtime is in a inconsistent state.

Unfortunately, debuggers generating backtraces for a Go panic
will be confused and come up with a technical correct but useless
stack. This CL moves just the crash performing - typically a SIGABRT
signal - outside the systemstack call to improve backtraces.

Unfortunately, the crash function now needs to be marked nosplit and
that triggers the no split stackoverflow check. To work around that,
split fatalpanic in two: fatalthrow for runtime.throw and fatalpanic for
runtime.gopanic. Only Go panics really needs crashes on the right stack
and there is enough stack for gopanic.

Example program:

package main

import "runtime/debug"

func main() {
	debug.SetTraceback("crash")
	crash()
}

func crash() {
	panic("panic!")
}

Before:
(lldb) bt
* thread #1, name = 'simple', stop reason = signal SIGABRT
  * frame #0: 0x000000000044ffe4 simple`runtime.raise at <autogenerated>:1
    frame #1: 0x0000000000438cfb simple`runtime.dieFromSignal(sig=<unavailable>) at signal_unix.go:424
    frame #2: 0x0000000000438ec9 simple`runtime.crash at signal_unix.go:525
    frame #3: 0x00000000004268f5 simple`runtime.dopanic_m(gp=<unavailable>, pc=<unavailable>, sp=<unavailable>) at panic.go:758
    frame #4: 0x000000000044bead simple`runtime.fatalpanic.func1 at panic.go:657
    frame #5: 0x000000000044d066 simple`runtime.systemstack at <autogenerated>:1
    frame #6: 0x000000000042a980 simple at proc.go:1094
    frame #7: 0x0000000000438ec9 simple`runtime.crash at signal_unix.go:525
    frame #8: 0x00000000004268f5 simple`runtime.dopanic_m(gp=<unavailable>, pc=<unavailable>, sp=<unavailable>) at panic.go:758
    frame #9: 0x000000000044bead simple`runtime.fatalpanic.func1 at panic.go:657
    frame #10: 0x000000000044d066 simple`runtime.systemstack at <autogenerated>:1
    frame #11: 0x000000000042a980 simple at proc.go:1094
    frame #12: 0x00000000004268f5 simple`runtime.dopanic_m(gp=<unavailable>, pc=<unavailable>, sp=<unavailable>) at panic.go:758
    frame #13: 0x000000000044bead simple`runtime.fatalpanic.func1 at panic.go:657
    frame #14: 0x000000000044d066 simple`runtime.systemstack at <autogenerated>:1
    frame #15: 0x000000000042a980 simple at proc.go:1094
    frame #16: 0x000000000044bead simple`runtime.fatalpanic.func1 at panic.go:657
    frame #17: 0x000000000044d066 simple`runtime.systemstack at <autogenerated>:1

After:
(lldb) bt
* thread #7, stop reason = signal SIGABRT
  * frame #0: 0x0000000000450024 simple`runtime.raise at <autogenerated>:1
    frame #1: 0x0000000000438d1b simple`runtime.dieFromSignal(sig=<unavailable>) at signal_unix.go:424
    frame #2: 0x0000000000438ee9 simple`runtime.crash at signal_unix.go:525
    frame #3: 0x00000000004264e3 simple`runtime.fatalpanic(msgs=<unavailable>) at panic.go:664
    frame #4: 0x0000000000425f1b simple`runtime.gopanic(e=<unavailable>) at panic.go:537
    frame #5: 0x0000000000470c62 simple`main.crash at simple.go:11
    frame #6: 0x0000000000470c00 simple`main.main at simple.go:6
    frame #7: 0x0000000000427be7 simple`runtime.main at proc.go:198
    frame #8: 0x000000000044ef91 simple`runtime.goexit at <autogenerated>:1

Updates #22716

Change-Id: Ib5fa35c13662c1dac2f1eac8b59c4a5824b98d92
Reviewed-on: https://go-review.googlesource.com/110065
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      b1d1ec91
    • Balaram Makam's avatar
      cmd/asm: add vector instructions for ChaCha20Poly1305 on ARM64 · c789ce3f
      Balaram Makam authored 
      This change provides VZIP1, VZIP2, VTBL instruction for supporting
ChaCha20Poly1305 implementation later.

Change-Id: Ife7c87b8ab1a6495a444478eeb9d906ae4c5ffa9
Reviewed-on: https://go-review.googlesource.com/110015Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      c789ce3f
    • Richard Musiol's avatar
      all: skip unsupported tests for js/wasm · e3c68477
      Richard Musiol authored 
      The general policy for the current state of js/wasm is that it only
has to support tests that are also supported by nacl.

The test nilptr3.go makes assumptions about which nil checks can be
removed. Since WebAssembly does not signal on reading a null pointer,
all nil checks have to be explicit.

Updates #18892

Change-Id: I06a687860b8d22ae26b1c391499c0f5183e4c485
Reviewed-on: https://go-review.googlesource.com/110096Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      e3c68477
    • Austin Clements's avatar
      cmd/internal/obj/arm: fix/rationalize checkpool distance check · 1b44167d
      Austin Clements authored 
      When deciding whether to flush the constant pool, the distance check
in checkpool can fail to account for padding inserted before the next
instruction by nacl.

For example, see this failure:
https://go-review.googlesource.com/c/go/+/109350/2#message-07085b591227824bb1d646a7192cbfa7e0b97066
Here, the pool should be flushed before a CALL instruction, but
checkpool only considers the CALL instruction to be 4 bytes and
doesn't account for the 8 extra bytes of alignment padding added
before it by asmoutnacl. As a result, it flushes the pool after the
CALL instruction, which is 4 bytes too late.

Furthermore, there's no explanation for the rather convoluted
expression used to decide if we need to emit the constant pool.

This CL modifies checkpool to take the PC following the tentative
instruction as an argument. The caller knows this already and this way
checkpool doesn't have to guess (and get it wrong in the presence of
padding). In the process, it rewrites the test to be structured and
commented.

Change-Id: I32a3d50ffb5a94d42be943e9bcd49036c7e9b95c
Reviewed-on: https://go-review.googlesource.com/110017
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      1b44167d
    • Richard Musiol's avatar
      syscall: enable some nacl code to be shared with js/wasm · 3bdbb5df
      Richard Musiol authored 
      This commit only moves code in preparation for the following commit
which adds the js/wasm architecture to the os package. There are no
semantic changes in this commit.

Updates #18892

Change-Id: Ia44484216f905c25395c565c34cfe6996c305ed6
Reviewed-on: https://go-review.googlesource.com/109976Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      3bdbb5df
    • Brad Fitzpatrick's avatar
      os: find Hostname using Uname to fix Android · 3c7456c1
      Brad Fitzpatrick authored 
      It's also fewer system calls. Fall back to longer read
only if it seems like the Uname result is truncated.

Fixes #24701

Change-Id: Ib6550acede8dddaf184e8fa9de36377e17bbddab
Reviewed-on: https://go-review.googlesource.com/110295Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      3c7456c1
    • Andrew Bonventre's avatar
      doc: document Go 1.10.2 · 4bced5e9
      Andrew Bonventre authored 
      Change-Id: I84334dfd02ad9a27b3fb6d46a6b1c015a3f03511
Reviewed-on: https://go-review.googlesource.com/110335Reviewed-by: default avatarFilippo Valsorda <filippo@golang.org>
      4bced5e9
    • Andrew Bonventre's avatar
      doc: document Go 1.9.6 · 587416c1
      Andrew Bonventre authored 
      Change-Id: I9699b22d3a308cda685aa684b32dcde99333df46
Reviewed-on: https://go-review.googlesource.com/110315Reviewed-by: default avatarFilippo Valsorda <filippo@golang.org>
      587416c1
    • Kevin Burke's avatar
      crypto/tls: add examples for [Load]X509KeyPair · 4154727e
      Kevin Burke authored 
      I was confused about how to start an HTTP server if the server
cert/key are in memory, not on disk. I thought it would be good to
show an example of how to use these two functions to accomplish that.

example-cert.pem and example-key.pem were generated using
crypto/tls/generate_cert.go.

Change-Id: I850e1282fb1c38aff8bd9aeb51988d21fe307584
Reviewed-on: https://go-review.googlesource.com/72252Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      4154727e
    • Tobias Klauser's avatar
      cmd/cgo: add support for GOARCH=riscv64 · 3334eee4
      Tobias Klauser authored 
      Even though GOARCH=riscv64 is not supported by gc yet, it is easy
to make cmd/cgo already support it.

Together with the changes in debug/elf in CL 107339 this e.g. allows
to generate Go type definitions for linux/riscv64 in the
golang.org/x/sys/unix package without using gccgo.

Change-Id: I6b849df2ddac56c8c483eb03d56009669ca36973
Reviewed-on: https://go-review.googlesource.com/110066
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      3334eee4
    • Elias Naur's avatar
      misc/ios: script lldb directly with Python · 78219ab3
      Elias Naur authored 
      The iOS exec wrapper uses ios-deploy to set up a device, install
the wrapped app, and start a lldb session to run it. ios-deploy is
not built to be scripted, as can be seen from the brittle way it is
driven by the Go wrapper. There are many timeouts and comments such
as

"
// lldb tries to be clever with terminals.
// So we wrap it in script(1) and be clever
// right back at it.
"

This CL replaces the use of ios-deploy with a lldb driver script in
Python. lldb is designed to be scripted, so apart from getting rid
of the ios-deploy dependency, we gain:

- No timouts and scripting ios-deploy through stdin and parsing
stdout for responses.
- Accurate exit codes.
- Prompt exits when the wrapped binary fails for some reason. Before,
the go test timeout would kick in to fail the test.
- Support for environment variables.
- No noise in the test output. Only the test binary output is output
from the wrapper.

We have to do more work with the lldb driver: mounting the developer
image on the device, running idevicedebugserverproxy and installing
the app. Even so, the CL removes almost as many lines as it adds.
Furthermore, having the steps split up helps to tell setup errors
from runtime errors.

Change-Id: I48cccc32f475d17987283b2c93aacc3da18fe339
Reviewed-on: https://go-review.googlesource.com/107337
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      78219ab3
    • Keith Randall's avatar
      runtime: fix newosproc darwin+arm/arm64 · eef27a8f
      Keith Randall authored 
      Missed conversion of newosproc for the parts of darwin that
weren't affected by my previous change.

Update #25181

Change-Id: I81a2935e192b6d0df358c59b7e785eb03c504c23
Reviewed-on: https://go-review.googlesource.com/110123Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      eef27a8f
    • Alberto Donizetti's avatar
      doc: update FAQ on binary sizes · 0cdf2ec8
      Alberto Donizetti authored 
      In the binary sizes FAQ, the approximate size of a Go hello world
binary was said to be 1.5MB (it was about 1.6MB on go1.7 on
linux/amd64). Sadly, this is no longer true. A Go1.10 hello world is
2.0MB, and in 1.11 it'll be about 2.5MB.

Just say "a couple megabytes" to stop this dance.

Change-Id: Ib4dc13a47ccd51327c1a9d90d4116f79597513a4
Reviewed-on: https://go-review.googlesource.com/110069Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      0cdf2ec8
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7