Skip to content

G
go
Switch branch/tag
  1. 01 Nov, 2019 2 commits
  3. 31 Oct, 2019 7 commits
  5. 25 Oct, 2019 12 commits
    • Cherry Zhang's avatar
      [dev.link] all: merge branch 'master' into dev.link · d77b809d
      Cherry Zhang authored 
      The only conflict is in cmd/internal/obj/link.go and the
resolution is trivial.

Change-Id: Ic79b760865a972a0ab68291d06386531d012de86
      d77b809d
    • Than McIntosh's avatar
      [dev.link] cmd/link/internal/loader: add PkgNone resolver cache · 2e2ef666
      Than McIntosh authored 
      Add a cache for the loader.Loader.resolve() method to use when
looking mapping local PkgNone symbols to global symbol indices.
This helps avoid repeated map lookups during deadcode and other
early phases of the linker when we haven't fully read in all
of object file symbols. Benchstat numbers:

name                      old time/op       new time/op       delta
LinkCompiler                    1.97s ±13%        1.67s ± 8%  -15.34%  (p=0.000 n=20+20)
LinkWithoutDebugCompiler        1.48s ±12%        1.21s ±11%  -18.14%  (p=0.000 n=20+20)

name                      old user-time/op  new user-time/op  delta
LinkCompiler                    2.19s ± 9%        2.04s ±17%   -6.98%  (p=0.002 n=19+20)
LinkWithoutDebugCompiler        1.29s ±13%        1.20s ±13%   -7.70%  (p=0.000 n=20+20)

Change-Id: I4b0b05c8208ee44ee9405b24774b84443e486831
Reviewed-on: https://go-review.googlesource.com/c/go/+/203197
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      2e2ef666
    • Austin Clements's avatar
      runtime: ensure _Grunning Gs have a valid g.m and g.m.p · fc8eb264
      Austin Clements authored 
      We already claim on the documentation for _Grunning that this is case,
but execute transitions to _Grunning before assigning g.m. Fix this
and make the documentation even more explicit.

For #10958, #24543, but also a good cleanup.

Change-Id: I1eb0108e7762f55cfb0282aca624af1c0a15fe56
Reviewed-on: https://go-review.googlesource.com/c/go/+/201440
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      fc8eb264
    • Austin Clements's avatar
      runtime: make m.libcallsp check in shrinkstack panic · f82956b8
      Austin Clements authored 
      Currently, shrinkstack will not shrink a stack on Windows if
gp.m.libcallsp != 0. In general, we can't shrink stacks in syscalls
because the syscall may hold pointers into the stack, and in principle
this is supposed to be preventing that for libcall-based syscalls
(which are direct syscalls from the runtime). But this test is
actually broken and has been for a long time. That turns out to be
okay because it also appears it's not necessary.

This test is racy. g.m points to whatever M the G was last running on,
even if the G is in a blocked state, and that M could be doing
anything, including making libcalls. Hence, observing that libcallsp
== 0 at one moment in shrinkstack is no guarantee that it won't become
non-zero while we're shrinking the stack, and vice-versa.

It's also weird that this check is only performed on Windows, given
that we now use libcalls on macOS, Solaris, and AIX.

This check was added when stack shrinking was first implemented in CL
69580044. The history of that CL (though not the final version)
suggests this was necessary for libcalls that happened on Go user
stacks, which we never do now because of the limited stack space.

It could also be defending against user stack pointers passed to
libcall system calls from blocked Gs. But the runtime isn't allowed to
keep pointers into the user stack for blocked Gs on any OS, so it's
not clear this would be of any value.

Hence, this checks seems to be simply unnecessary.

Rather than simply remove it, this CL makes it defensive. We can't do
anything about blocked Gs, since it doesn't even make sense to look at
their M, but if a G tries to shrink its own stack while in a libcall,
that indicates a bug in the libcall code. This CL makes shrinkstack
panic in this case.

For #10958, #24543, since those are going to rearrange how we decide
that it's safe to shrink a stack.

Change-Id: Ia865e1f6340cff26637f8d513970f9ebb4735c6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/173724
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      f82956b8
    • Than McIntosh's avatar
      [dev.link] cmd/link: rework relocation handling in new deadcode · 376ef734
      Than McIntosh authored 
      Do a better job of reading relocations in the new deadcode pass.
Specifically, during method type processing, read relocations for the
symbol we're working on into a slice, and then pass the slice to
helper functions, as opposed to rereading relocs at each stage.

Change-Id: I95e3737ae91bb09b4da8e6ee68112ec255ceb0fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/201722
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      376ef734
    • Austin Clements's avatar
      cmd/internal/obj/x86: correct pcsp for ADJSP · 9d032026
      Austin Clements authored 
      The x86 assembler supports an "ADJSP" pseudo-op that compiles to an
ADD/SUB from SP. Unfortunately, while this seems perfect for an
instruction that would allow obj to continue to track the SP/FP delta,
obj currently doesn't do that. As a result, FP-relative references
won't work and, perhaps worse, the pcsp table will have the wrong
frame size.

We don't currently use this instruction in any assembly or generate it
in the compiler, but this is a perfect instruction for solving a
problem in #24543.

This CL makes ADJSP useful by incorporating it into the SP delta
logic.

One subtlety is that we do generate ADJSP in obj itself to open a
function's stack frame. Currently, when preprocess enters the loop to
compute the SP delta, it may or may not start at this ADJSP
instruction depending on various factors. We clean this up by instead
always starting the SP delta at 0 and always starting this loop at the
entry to the function.

Why not just recognize ADD/SUB of SP? The danger is that could change
the meaning of existing code. For example, walltime1 in
sys_linux_amd64.s saves SP, SUBs from it, and aligns it. Later, it
restores the saved copy and then does a few FP-relative references.
Currently obj doesn't know any of this is happening, but that's fine
once it gets to the FP-relative references. If we taught obj to
recognize the SUB, it would start to miscompile this code. An
alternative would be to recognize unknown instructions that write to
SP and refuse subsequent FP-relative references, but that's kind of
annoying.

This passes toolstash -cmp for std on both amd64 and 386.

Change-Id: Ic6c6a7cbf980bca904576676c07b44c0aaa9c82d
Reviewed-on: https://go-review.googlesource.com/c/go/+/200877
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarDavid Chase <drchase@google.com>
      9d032026
    • ZYunH's avatar
      internal/singleflight: format someErr · 00d6b28d
      ZYunH authored 
      Error string should not be capitalized.

Change-Id: I8e1d148c6b999450bcd702f420c2a240f82aadc7
GitHub-Last-Rev: 6ca1b3edb4a61723fa6472a0f54cc6329898edbc
GitHub-Pull-Request: golang/go#35147
Reviewed-on: https://go-review.googlesource.com/c/go/+/203339Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      00d6b28d
    • Meng Zhuo's avatar
      cmd/dist: fix wrong goarch on mips64le · dad512f6
      Meng Zhuo authored 
      Change-Id: I625f0bc533a7d14010c0344f36e8f157a19c13f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/203437
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
Reviewed-by: default avatarTobias Klauser <tobias.klauser@gmail.com>
      dad512f6
    • Meng Zhuo's avatar
      runtime: fix typo of MADV_NOHUGEPAGE · 9a701017
      Meng Zhuo authored 
      Change-Id: I60a1ca606fe7492c05697c4d58afc7f19fcc63fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/203340Reviewed-by: default avatarTobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      9a701017
    • Jason A. Donenfeld's avatar
      internal/syscall/windows/registry: allow for non-null terminated strings · 3c25e5ec
      Jason A. Donenfeld authored 
      According to MSDN, "If the data has the REG_SZ, REG_MULTI_SZ or
REG_EXPAND_SZ type, this size includes any terminating null character or
characters unless the data was stored without them. [...] If the data
has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, the string may not
have been stored with the proper terminating null characters. Therefore,
even if the function returns ERROR_SUCCESS, the application should
ensure that the string is properly terminated before using it;
otherwise, it may overwrite a buffer."

It's therefore dangerous to pass it off unbounded as we do, and in fact
this led to crashes on real systems.

Change-Id: I6d786211814656f036b87fd78631466634cd764a
Reviewed-on: https://go-review.googlesource.com/c/go/+/202937
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAlex Brainman <alex.brainman@gmail.com>
      3c25e5ec
    • Rob Pike's avatar
      fmt: fix handling of %% verb in Scanf · 4f70c151
      Rob Pike authored 
      There were a couple of bugs, including not requiring a percent and
returning the wrong error for a bad format containing %%.

Both are addressed by fixing the first.

Fixes #34180.

Change-Id: If96c0c0258bcb95eec49871437d719cb9d399d9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/202879
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      4f70c151
    • Rémy Oudompheng's avatar
      math/big: use nat pool to reduce allocations in mul and sqr · 8f30d251
      Rémy Oudompheng authored 
      This notably allows to reuse temporaries across
the karatsubaSqr recursion.

benchmark                    old ns/op     new ns/op     delta
BenchmarkNatMul/10-4         227           228           +0.44%
BenchmarkNatMul/100-4        8339          8589          +3.00%
BenchmarkNatMul/1000-4       313796        312272        -0.49%
BenchmarkNatMul/10000-4      11924720      11873589      -0.43%
BenchmarkNatMul/100000-4     503813354     503839058     +0.01%
BenchmarkNatSqr/20-4         549           513           -6.56%
BenchmarkNatSqr/30-4         945           874           -7.51%
BenchmarkNatSqr/50-4         1993          1832          -8.08%
BenchmarkNatSqr/80-4         4096          3874          -5.42%
BenchmarkNatSqr/100-4        6192          5712          -7.75%
BenchmarkNatSqr/200-4        20388         19543         -4.14%
BenchmarkNatSqr/300-4        38735         36715         -5.21%
BenchmarkNatSqr/500-4        99562         93542         -6.05%
BenchmarkNatSqr/800-4        195554        184907        -5.44%
BenchmarkNatSqr/1000-4       286302        275053        -3.93%
BenchmarkNatSqr/10000-4      9817057       9441641       -3.82%
BenchmarkNatSqr/100000-4     390713416     379696789     -2.82%

benchmark                    old allocs     new allocs     delta
BenchmarkNatMul/10-4         1              1              +0.00%
BenchmarkNatMul/100-4        1              1              +0.00%
BenchmarkNatMul/1000-4       2              1              -50.00%
BenchmarkNatMul/10000-4      2              1              -50.00%
BenchmarkNatMul/100000-4     9              11             +22.22%
BenchmarkNatSqr/20-4         2              1              -50.00%
BenchmarkNatSqr/30-4         2              1              -50.00%
BenchmarkNatSqr/50-4         2              1              -50.00%
BenchmarkNatSqr/80-4         2              1              -50.00%
BenchmarkNatSqr/100-4        2              1              -50.00%
BenchmarkNatSqr/200-4        2              1              -50.00%
BenchmarkNatSqr/300-4        4              1              -75.00%
BenchmarkNatSqr/500-4        4              1              -75.00%
BenchmarkNatSqr/800-4        10             1              -90.00%
BenchmarkNatSqr/1000-4       10             1              -90.00%
BenchmarkNatSqr/10000-4      731            1              -99.86%
BenchmarkNatSqr/100000-4     19687          6              -99.97%

benchmark                    old bytes     new bytes     delta
BenchmarkNatMul/10-4         192           192           +0.00%
BenchmarkNatMul/100-4        4864          4864          +0.00%
BenchmarkNatMul/1000-4       57344         49224         -14.16%
BenchmarkNatMul/10000-4      565248        498772        -11.76%
BenchmarkNatMul/100000-4     5749504       7263720       +26.34%
BenchmarkNatSqr/20-4         672           352           -47.62%
BenchmarkNatSqr/30-4         992           512           -48.39%
BenchmarkNatSqr/50-4         1792          896           -50.00%
BenchmarkNatSqr/80-4         2688          1408          -47.62%
BenchmarkNatSqr/100-4        3584          1792          -50.00%
BenchmarkNatSqr/200-4        6656          3456          -48.08%
BenchmarkNatSqr/300-4        24448         16387         -32.97%
BenchmarkNatSqr/500-4        36864         24591         -33.29%
BenchmarkNatSqr/800-4        69760         40981         -41.25%
BenchmarkNatSqr/1000-4       86016         49180         -42.82%
BenchmarkNatSqr/10000-4      2524800       487368        -80.70%
BenchmarkNatSqr/100000-4     68599808      5876581       -91.43%

Change-Id: I8e6e409ae1cb48be9d5aa9b5f428d6cbe487673a
Reviewed-on: https://go-review.googlesource.com/c/go/+/172017
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      8f30d251
  7. 24 Oct, 2019 18 commits
  9. 23 Oct, 2019 1 commit
    • Cherry Zhang's avatar
      runtime: save/fetch g register during VDSO on ARM and ARM64 · 758eb020
      Cherry Zhang authored 
      On ARM and ARM64, during a VDSO call, the g register may be
temporarily clobbered by the VDSO code. If a signal is received
during the execution of VDSO code, we may not find a valid g
reading the g register. In CL 192937, we conservatively assume
g is nil. But this approach has a problem: we cannot handle
the signal in this case. Further, if the signal is not a
profiling signal, we'll call badsignal, which calls needm, which
wants to get an extra m, but we don't have one in a non-cgo
binary, which cuases the program to hang.

This is even more of a problem with async preemption, where we
will receive more signals than before. I ran into this problem
while working on async preemption support on ARM64.

In this CL, before making a VDSO call, we save the g on the
gsignal stack. When we receive a signal, we will be running on
the gsignal stack, so we can fetch the g from there and move on.

We probably want to do the same for PPC64. Currently we rely on
that the VDSO code doesn't actually clobber the g register, but
this is not guaranteed and we don't have control with.

Idea from discussion with Dan Cross and Austin.

Should fix #34391.

Change-Id: Idbefc5e4c2f4373192c2be797be0140ae08b26e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/202759
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      758eb020
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7