Separate instance information into an instance struct, to reduce memory
footprint for non-instance Named types. This may induce a sense of
deja-vu: we had a similar construct in the past that was removed as
unnecessary. With additional new fields being added that only apply to
instances, having a separate struct makes sense again.
Updates #52728
Change-Id: I0bb5982d71c27e6b574bfb4f7b886a6aeb9c5390
Reviewed-on: https://go-review.googlesource.com/c/go/+/404884
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In order to clean up context after fully expanding a type (in subsequent
CLs), we must use a common mutex. Eliminate the lazy methodList type,
which keeps a sync.Once per method, in favor of Named.mu.
Updates #52728
Change-Id: I2d13319276df1330ee53046ef1823b0167a258d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/404883
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Introduce a monotonic state variable to track the lifecycle of a named
type, replacing the existing sync.Once. Having a single guard for the
state of underlying and methods will allow for cleaning-up when the type
is fully expanded. In the future, this state may also be used for
detecting access to information such as underlying or methods before the
type is fully set-up, though that will require rethinking our
type-checking of invalid cyclic types.
Also remove support for type-type inference. If we ever support this
feature in the future (inference of missing type arguments for named
type instances), it will likely involve additional machinery that does
not yet exist. Remove the current partial support to simplify our
internal APIs. In particular, this means that Named.resolver is only
used for lazy loading. As a result, we can revert the lazy loader
signature to its previous form.
A lot of exposition is added for how Named types work. Along the way,
the terminology we use to describe them is refined.
Some microbenchmarks are added that were useful in evaluating the
tradeoffs between synchronization mechanisms.
Updates #52728
Change-Id: I4e147360bc6e5d8cd4f37e32e86fece0530a6480
Reviewed-on: https://go-review.googlesource.com/c/go/+/404875
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This resolves legacy go binaries crashing the buildid tool when the -w flag is specified.
Fixes#50809
Change-Id: I55a866f285a3c2cebcf2cdbb9cc30e5078e1d18f
GitHub-Last-Rev: 7169a58fd7
GitHub-Pull-Request: golang/go#53163
Reviewed-on: https://go-review.googlesource.com/c/go/+/409535
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The documentation for strconv.ParseFloat mentions that it "accepts
decimal and hexadecimal floating-point number syntax", but it doesn't
specify what those formats entail. For example, "0x10" is not allowed;
you need an explicit exponent, as in "0x10p0".
This clarifies that ParseFloat accepts the Go syntax for floating-point
literals, and links to that spec section. I've also linked to the
relevant spec section for ParseInt's doc comment, which already said
"as defined by the Go syntax for integer literals".
Change-Id: Ib5d2b408bdd01ea0b9f69381a9dbe858f6d1d424
Reviewed-on: https://go-review.googlesource.com/c/go/+/410335
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
statment -> statement
Change-Id: Ia93a466fdc20157a7d6048903e359fe8717ecb8f
GitHub-Last-Rev: 0a9bc5cab0
GitHub-Pull-Request: golang/go#53231
Reviewed-on: https://go-review.googlesource.com/c/go/+/410374
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Following discussion on #47141, make the following changes:
- Document Go's overall approach.
- Document that multiword races can cause crashes.
- Document happens-before for runtime.SetFinalizer.
- Document (or link to) happens-before for more sync types.
- Document happens-before for sync/atomic.
- Document disallowed compiler optimizations.
See also https://research.swtch.com/gomm for background.
Fixes#50859.
Change-Id: I17d837756a77f4d8569f263489c2c45de20a8778
Reviewed-on: https://go-review.googlesource.com/c/go/+/381315
Reviewed-by: Ian Lance Taylor <iant@google.com>
Rolled back in CL 410133.
For #51115.
Change-Id: I009c557acf98a98a9e5648fa82d998d41974ae60
Reviewed-on: https://go-review.googlesource.com/c/go/+/410357
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
We are having a hard time deciding the exact semantics
of the Err field, and we need to ship the beta.
So revert the Err field change; it can wait for Go 1.20.
For #51115.
This reverts CL 396215.
Change-Id: I7719386567d3da10a614058a11f19dbccf304b4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/410133
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
As of this CL, release notes for all packages owned by @golang/runtime
on https://dev.golang.org/owners are either complete or have explicit
TODOs.
For #51400
Change-Id: I5b6affd43883991a3b8a065b4aa211efce7427f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/410118
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
This documents most of the changes in runtime packages, which the major
exception of GC changes, which will be documented in a future CL.
For #51400
Change-Id: Ibcf501e1b4f7caa3397db6b9136daec07aac5a65
Reviewed-on: https://go-review.googlesource.com/c/go/+/410117
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently the GC CPU limiter only tracks idle GC work time. However, in
very undersubscribed situations, it's possible that all this extra idle
time prevents the enabling of the limiter, since it all gets account for
as mutator time. Fix this by tracking all idle time via pidleget and
pidleput. To support this, pidleget and pidleput also accept and return
"now" parameters like the timer code.
While we're here, let's clean up some incorrect assumptions that some of
the scheduling code makes about "now."
Fixes#52890.
Change-Id: I4a97893d2e5ad1e8c821f8773c2a1d449267c951
Reviewed-on: https://go-review.googlesource.com/c/go/+/410122
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Either due to a new nowritebarrierrec annotation or a change in escape
analysis, printDebuglog can't be called from sighandler anymore.
Fix this by avoiding a string allocation that's the primary culprit.
Change-Id: Ic84873a453f45852b0443a46597ed3ab8c9443fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/410121
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently the GC CPU limiter consumes CPU time from a few pools, but
because the events that flush to those pools may overlap, rather than be
strictly contained within, the update window for the GC CPU limiter, the
limiter's accounting is ultimately sloppy.
This sloppiness complicates accounting for idle time more completely,
and makes reasoning about the transient behavior of the GC CPU limiter
much more difficult.
To remedy this, this CL adds a field to the P struct that tracks the
start time of any in-flight event the limiter might care about, along
with information about the nature of that event. This timestamp is
managed atomically so that the GC CPU limiter can come in and perform a
read of the partial CPU time consumed by a given event. The limiter also
updates the timestamp so that only what's left over is flushed by the
event itself when it completes.
The end result of this change is that, since the GC CPU limiter is aware
of all past completed events, and all in-flight events, it can much more
accurately collect the CPU time of events since the last update. There's
still the possibility for skew, but any leftover time will be captured
in the following update, and the magnitude of this leftover time is
effectively bounded by the update period of the GC CPU limiter, which is
much easier to consider.
One caveat of managing this timestamp-type combo atomically is that they
need to be packed in 64 bits. So, this CL gives up the top 3 bits of the
timestamp and places the type information there. What this means is we
effectively have only a 61-bit resolution timestamp. This is fine when
the top 3 bits are the same between calls to nanotime, but becomes a
problem on boundaries when those 3 bits change. These cases may cause
hiccups in the GC CPU limiter by not accounting for some source of CPU
time correctly, but with 61 bits of resolution this should be extremely
rare. The rate of update is on the order of milliseconds, so at worst
the runtime will be off of any given measurement by only a few
CPU-milliseconds (and this is directly bounded by the rate of update).
We're probably more inaccurate from the fact that we don't measure real
CPU time but only approximate it.
For #52890.
Change-Id: I347f30ac9e2ba6061806c21dfe0193ef2ab3bbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/410120
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
After CL 381317 there exist values that may have an alignment greater
than the pointer size for that platform. Specifically, atomic.{Ui|I}nt64
may be aligned to 8 bytes on a 32-bit platform. If such a value, or
a container for the value, gets stack-allocated, it's possible that it
won't be aligned correctly, because the maximum alignment we enforce on
stacks is governed by the pointer size. Changing that would be a
significant undertaking, so just escape these values to the heap
instead, where we're sure they'll actually be aligned correctly.
Change is by rsc@, I'm just shepherding it through code review.
For #50860.
Change-Id: I51669561c0a13ecb84f821020e144c58cb528418
Reviewed-on: https://go-review.googlesource.com/c/go/+/410131
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL makes the changes to actually use the module index when loading
packages and instead of scanning their directories to see if they
contain go files or to extract imports.
Change-Id: I70106181cf64d6fd5a416644ba518b6b90030e0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/403778
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
The data read is used for three primary functions: ImportPackage,
IsDirWithGoFiles and ScanDir. Functions are also provided to get this
information from the intermediate package representation to cache
the information from reads for non-indexed packages.
Change-Id: I5eed629bb0d6ee5b88ab706d06b074475004c081
Reviewed-on: https://go-review.googlesource.com/c/go/+/403975
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
For #51400
Change-Id: If5fc131df254d47a989ff61c8e584cb8149cbd09
Reviewed-on: https://go-review.googlesource.com/c/go/+/410116
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Do not need to add single quotes '' when passing the parameter value of
the -ldflags option, otherwise the following error will be reported:
invalid value "'-linkmode=external'" for flag -ldflags: parameter may
not start with quote character.
Change-Id: I322fa7079ac24c8a68d9cb0872b0a20dbc4893d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/410074
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
A clean up for CL 408734, suggested by Joe Tsai.
Change-Id: Ida9db0b8d31785d5640938c286c9c6c82c27f457
Reviewed-on: https://go-review.googlesource.com/c/go/+/410154
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Fix a build failure when bootstrapping the Go compiler with go-bootstrap 1.4
while the environment contains GOARCH=riscv64.
Building Go toolchain1 using go-1.4-bootstrap-20171003.
src/cmd/compile/internal/ssa/rewriteRISCV64.go:4814
invalid operation: y << x (shift count type int64, must be unsigned integer)
This is because:
- buildtool.go:198: calls bootstrapRewriteFile(src)
- bootstrapRewriteFile: buildtool.go:283 calls:
- isUnneededSSARewriteFile: checks os.Getenv("GOARCH")
- isUnneededSSARewriteFile: returns "", false
- bootstrapRewriteFile: calls bootstrapFixImports
- boostrapFixImports: generates code go1.4 cannot compile
Instead of checking "GOARCH" in the environment, use the gohostarch variable.
Change-Id: Ie9c190498555c4068461fead6278a62e924062c6
GitHub-Last-Rev: 300d7a7fea
GitHub-Pull-Request: golang/go#52362
Reviewed-on: https://go-review.googlesource.com/c/go/+/400376
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
This permits us to read files that earlier Go releases could read.
It is also compatible with other zip programs.
Change-Id: I7e2999f1073c4db5ba3f51f92681e0b149d55b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/408734
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I71c9d9ef9d21a7ae9466d8c7b283fdfbba01f5a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/390734
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change functions to scan modules and packages into an intermediate
RawPackage struct and also functions to write them out to and index.
Change-Id: Ia1a3b58b992e9be52c5d1397e85c642f902011cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/398415
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
We have noticed a pattern of connection timeouts connecting to
github.com on the builders. Adding tracing may shed some light on the
underlying cause.
For #52545.
Change-Id: Ic73b494be9a3ea8ce3c7631ee8f62bd3d0d8e7bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/409575
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For instantiated generic functions, all implicit dot operations are
resolved. Thus unsafe.Offsetof may calculating the offset against the
wrong base selector.
To fix it, we must remove any implicit dot operations to find the first
non-implicit one, which is the right base selector for calculating the
offset.
Fixes#53137
Change-Id: I38504067ce0f274615b306edc8f7d7933bdb631a
Reviewed-on: https://go-review.googlesource.com/c/go/+/409355
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
In the windows version of OutBuf.munmap, call syscall.FlushFileBuffers
after the call to syscall.FlushViewOfFile, on the theory that this
will help flush all associated meta-data for the file the linker is
writing.
Updates #44817.
Change-Id: Ibff7d05008a91eeed7634d2760153851e15e1c18
Reviewed-on: https://go-review.googlesource.com/c/go/+/406814
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Version 2022a was released on 2022-03-15 and we can start using it for
Go 1.19. Its release announcement was:
https://mm.icann.org/pipermail/tz-announce/2022-March/000070.html
For #22487.
Change-Id: Ie89b90927a251413e4f67c9e0ed3a67d4161529b
Reviewed-on: https://go-review.googlesource.com/c/go/+/409374
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
This reverts commit CL 401754 (440c9312c8) which reverted CL 400654,
thus reapplying CL 400654, re-adding the func init() { netGo = true }
to cgo_stub.go CL 400654 had originally removed (mistakenly during
development?) that had broken the darwin nocgo builder.
Fixes#33097
Change-Id: I90f59746d2ceb6b5d2bd832c9fc90068f8ff7417
Reviewed-on: https://go-review.googlesource.com/c/go/+/409234
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
This seems to be a common registry misconfiguration on Windows.
Fixes#32350
Change-Id: I68c617c42a6e72948e2acdf335ff8e7df569432d
Reviewed-on: https://go-review.googlesource.com/c/go/+/406894
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
As far as I can tell, this test suffers from #52433. For some reason,
this seems to become more of a problem on the windows/386 than anywhere
else. This CL is an attempt at a mitigation by slowing down the
allocation rate by inserting runtime.Gosched call in the inner loop. It
also cuts the iteration count which should help too (as less memory is
allocated in total), but the main motivation is to make sure the test
doesn't take too long to run.
Fixes#49564.
Change-Id: I8cc622b06a69cdfa66f680a30e1ccf334eea2164
Reviewed-on: https://go-review.googlesource.com/c/go/+/408825
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change forces mark and scavenge assists to be cancelled early if
the limiter is enabled. This avoids goroutines getting stuck in really
long assists if the limiter happens to be disabled when they first come
into the assist. This can get especially bad for mark assists, which, in
dire situations, can end up "owing" the GC a really significant debt.
For #52890.
Change-Id: I4bfaa76b8de3e167d49d2ffd8bc2127b87ea566a
Reviewed-on: https://go-review.googlesource.com/c/go/+/408816
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This fix is analogous to the one in CL 407888.
'go vet' catches the error, but it is not run on this file because the
file is (only) compiled when running testsanitizers/TestTSAN.
Fixes#53113.
Change-Id: I74f7b7390a9775ff00a06214c1019ba28846dd11
Reviewed-on: https://go-review.googlesource.com/c/go/+/409094
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
It's already mentioned under runtime/race, we don't need it
also mentioned under runtime.
Change-Id: I538322b32d75b9642f3ead03539fccb95988ef8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/408875
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Rhys Hiltner <rhys@justin.tv>
CL 392134 appears to have been marked for the release notes by accident.
Remove mention of this package.
Change-Id: I62ae30512512ef8e20e9040b71e613be5ee5ee26
Reviewed-on: https://go-review.googlesource.com/c/go/+/408819
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Auto-Submit: Alex Rakoczy <alex@golang.org>
For #51400.
Change-Id: I122b3a58e5fbaaa8ceb5b013e8e392f4bcbbd2e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/408495
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Cgo TSAN (not the Go race detector) intercepts signals and calls
the signal handler at a later time. When the signal handler is
called, the memory may have changed, but the signal context
remains old. As the signal context and the memory don't match, it
is unsafe to unwind the stack from the signal PC and SP. We have
to ignore the signal.
It is probably also not safe to do async preemption, which relies
on the signal PC, and inspects and even writes to the stack (for
call injection).
We also inspect the stack for fatal signals (e.g. SIGSEGV), but I
think they are not delayed. For other signals we don't inspect
the stack, so they are probably fine.
Fixes#27540.
Change-Id: I5c80a7512265b8ea4a91422954dbff32c6c3a0d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/408218
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
We choose 64 because the L1 Dcache of Loongson 3A5000 CPU is
4-way 256-line 64-byte-per-line.
Change-Id: Ifb9a9f993dd6f75b5adb4ff6e4d93e945b1b2a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/408854
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
