In its final phase, the typechecker walks the types it produces to
ensure that no unexpanded type instances leak through the API. However,
this also walks shared types (such as those in the universe scope),
resulting in a potential data race during concurrent typechecking
passes.
Fix this by being careful not to write if nothing needs to be changed.
Since any shared types should already be sanitized, this should
eliminate data races.
For #44434
Change-Id: Iadb2e78863efe0e974e69a00e255f26cfaf9386a
Reviewed-on: https://go-review.googlesource.com/c/go/+/294411
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Minor adjustment to match go/types more closely.
Change-Id: Id79c51f0ecd8cda0f5b68f6e961500f7f22f7115
Reviewed-on: https://go-review.googlesource.com/c/go/+/294270
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
By default, when typechecking a closure, tcClosure() creates a new
closure function. This should really be done separate from typechecking.
For now, we explicitly avoid creating a new closure function when
typechecking an inline body (in ImportedBody). However, the heuristic
for determining when we are typechecking an inline body was not correct
for double nested closures in an inline body, since CurFunc will then be
the inner closure, which has a body.
So, use a simple global variable to indicate when we typechecking an
inline body. The global variable is fine (just like ir.CurFunc), since
the front-end runs serially.
Fixes#44325
Change-Id: If2829fe1ebb195a7b1a240192b57fe6f04d1a36b
Reviewed-on: https://go-review.googlesource.com/c/go/+/294211
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
The codereview sync-branch command wants all involved
branches to have codereview.cfg, and this will help us when
we transition from master to main later this year.
Change-Id: Ia8e4c8b8c86864ed9d730e5d96be1ff386e2e1cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/294291
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
netbsd/amd64's Syscall9 changes SP using ADD and SUB,
which are treated as SPWRITEs (they are not accounted for
in the sp-adjust tracking, and there are too many functions that
would report mismatched stack adjustments at RET if they were).
A traceback starting in Syscall9 as saved by entersyscall complains
about the SPWRITE-ness unnecessarily, since the PC/SP are saved
at the start of the function. Ignore SPWRITE in that case.
netbsd/arm's Syscall6 also changes SP (R13), using a direct write.
So even if we could handle the ADD/SUB in the amd64 case or
rewrote that assembly, we'd still be stuck with a more difficult
problem in this case. Ignoring the SPWRITE fixes it.
Example crashes:
https://build.golang.org/log/160fc7b051a2cf90782b75a99984fff129329e66https://build.golang.org/log/7879e2fecdb400eee616294285e1f952e5b17301
Change-Id: I0c8e9696066e90dafed6d4a93d11697da23f0080
Reviewed-on: https://go-review.googlesource.com/c/go/+/294072
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This is failing but only under the race detector.
It doesn't really seem fair to expect pprof to find
specific profile events with the race detector slowing
everything down anyway.
Change-Id: I4b353d3d63944c87884d117e07d119b2c7bf4684
Reviewed-on: https://go-review.googlesource.com/c/go/+/294071
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We want to print hex exit codes for the large values,
but on 32-bit Windows the large values are negative.
Change-Id: I0e350b128414a9468c93eddc62d660f552c1ee05
Reviewed-on: https://go-review.googlesource.com/c/go/+/294070
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The regabi builders are unhappy about badctxt calling throw
calling systemstack calling gosave_systemstack_switch calling
badctxt, all nosplit, repeating. This wouldn't actually happen
since after one systemstack we'd end up on the system stack
and the next one wouldn't call gosave_systemstack_switch at all.
The badctxt call itself is in a very unlikely assertion failure
inside gosave_systemstack_switch.
Keep the assertion check but call runtime.abort instead on failure,
breaking the detected (but not real) cycle.
Change-Id: Iaf5c0fc065783b8c1c6d0f62d848f023a0714b96
Reviewed-on: https://go-review.googlesource.com/c/go/+/294069
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When generating DWARF inlined info records, it's possible to have a
local function whose only callsites are inlined away, meaning that we
emit an abstract function DIE but no regular subprogram DIE. When
emitting DWARF scope info we need to handle this case (specifically
when scoping PCs, check for the case that the func in question has
been entirely deleted).
Fixes#44344.
Change-Id: I9f5bc692f225aa4c5c23f7bd2e50bcf7fe4fc5f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/293309
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
An embedded struct field is embedded by mentioning its type.
The fact that the field name may be different and derived
from the type doesn't matter for the struct type.
Do print the embedded type rather than the derived field
name, as we have always done in the past. Remove the fancy
new code which was just plain wrong.
The struct output printing is only relevant for debugging
and test cases. Reverting to the original code (pre-generics)
fixes a couple of x/tools tests.
Unfortunately, the original code is (also) not correct for
embedded type aliases. Adjusted a gccgoimporter test
accordingly and filed issue #44410.
This is a follow-up on https://golang.org/cl/293961 which
addressed the issue only partially and left the incorrect
code in place.
Change-Id: Icb7a89c12ef7929c221fb1a5792f144f7fcd5855
Reviewed-on: https://go-review.googlesource.com/c/go/+/293962
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In CL 292109 we removed unnecessary writes to gp.sched.g
but put wrong register to save g (R4 saves pointer to g) on mips64x
Change-Id: I9777846a7b0a46e1af83dcfc73b74649e0dba3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/293989
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Before this CL, the parser consumed the next token following an invalid
selector expr no matter what it was. This leads to poor error recovery
when this next token is a closing delimiter or other reasonable element
of a stop set. As a side-effect, x/tools tests broke when parser logic
for type parameters was introduced, as they threw off the parser
synchronization to the point where the x/tools test bailed out.
This CL introduces a targeted fix that allows the x/tools tests to pass.
More general improvement for parser error recovery should be done for
go1.17.
Change-Id: I44d73d34b6063e62d16a23d24ab7cbce6500239d
Reviewed-on: https://go-review.googlesource.com/c/go/+/293792
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Prior to 1.16, go/types printed an embedded struct field by simply
printing its type, which may have included a package qualification.
Just printing the type is not useful with generic types and we now
must print the actual field name derived from the type - this leads
to different output for non-generic imported embedded types. Fix by
printing a package qualification in that case.
Change-Id: I2cb2484da7732428d13fdfb5fe4ec1fa1ee813a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/293961
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reqs currently combines requirements with upgrades and downgrades.
However, only Upgrade needs the Upgrade method, and only Downgrade
needs the Previous method.
When we eventually add lazy loading, the lazily-loaded module graph
will not be able to compute upgrades and downgrades, so the
implementation work from here to there will be clearer if we are
explicit about which are still needed.
For #36460
Change-Id: I7bf8c2a84ce6bc4ef493a383e3d26850e9a6a6c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/290771
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
It turns out that the existing call sites of the resolveCandidates
method pass only *either* a slice of queries or a slice of upgrades
(never both), and the behaviors triggered by the two parameters don't
overlap much at all. To clarify the two different operations, split
them into two separate methods.
For #36460
Change-Id: I64651637734fd44fea68740a3cdfbacfb73c19b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/289697
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
On my Surface Pro X running the insider preview,
running "netsh help" from Powershell started from the task bar works.
But running "powershell" at a cmd.exe prompt and then running
"netsh help" produces missing DLL errors.
These aren't our fault, so just skip the netsh-based tests if this happens.
Change-Id: I13a17e01143d823d3b5242d827db056bd253e3e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/293849
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
macOS tests have been disabled since CL 12429045 (Aug 2013).
At the time, macOS required a kernel patch to get a working profiler
(https://research.swtch.com/macpprof), which we didn't want
to require, of course.
macOS has improved - it no longer requires the kernel patch - but
we never updated the list of exceptions.
As far as I can tell, the builders have no problem passing the pprof test now.
(It is possible that the iOS builders have trouble, but that is now a different GOOS.)
Remove the exception for macOS. The test should now pass.
Fixes#6047.
Change-Id: Iab49036cacc1025e56f515bd19d084390c2f5357
Reviewed-on: https://go-review.googlesource.com/c/go/+/292229
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The Surface Pro X's 386 simulator is not completely faithful to a real 387.
The most egregious problem is that it computes Log2(8) as 2.9999999999999996,
but it has some other subtler problems as well. All the problems occur in
routines that we don't even bother with assembly for on amd64.
If the speed of Go code is OK on amd64 it should be OK on 386 too.
Just remove all the 386-only assembly functions.
This leaves Ceil, Floor, Trunc, Hypot, and Sqrt in 386 assembly,
all of which are also in assembly on amd64 and all of which pass
their tests on Surface Pro X.
Compared to amd64, the 386 port omits assembly for Min, Max, and Log.
It never had Min and Max, and this CL deletes Log because Log2 wasn't
even correct. (None of the other architectures have assembly Log either.)
Change-Id: I5eb6c61084467035269d4098a36001447b7a0601
Reviewed-on: https://go-review.googlesource.com/c/go/+/291229
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The assembly is mostly a straightforward conversion of the
equivalent arm assembly.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I61b15d712ade4d3a7285c7680de8e0987aacba10
Reviewed-on: https://go-review.googlesource.com/c/go/+/288828
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL adds a few small files - defs, os, and rt0 - to start
on windows/arm64 support for the runtime.
It also copies sys_windows_arm.s to sys_windows_arm64.s,
with the addition of "#ifdef NOT_PORTED" around the entire file.
This is meant to make future CLs easier to review, since the
general pattern is to translate the 32-bit ARM assembly into
64-bit ARM assembly.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I922037eb3890e77bac48281ecaa8e489595675be
Reviewed-on: https://go-review.googlesource.com/c/go/+/288827
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I5e2b589797808626bcca771cdf860d5cb85586cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/288826
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
types_windows_arm64.go is a copy of types_windows_amd64.go.
All that matters for these types seems to be that they are 64-bit vs 32-bit.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ia7788d6e88e5db899371c75dc7dea7d912a689ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/288825
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This brings in the windows/arm64 support, along with other recent changes.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ifaca710093376c658ecf91239aa05cc33af98a31
Reviewed-on: https://go-review.googlesource.com/c/go/+/288824
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The address space starts at 4GB, so dummy is too far out.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I5f67e268ce729086d9f9fc8541722fabccfd0145
Reviewed-on: https://go-review.googlesource.com/c/go/+/288823
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I397c1d238bb18cbe78b3fca00910660cf1d66b8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288822
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I5ec459063d394b9f434d1b8b5030960b45061038
Reviewed-on: https://go-review.googlesource.com/c/go/+/288821
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
We still need to add test data, but as yet we haven't identified
a good Windows arm64 compiler to produce small binaries.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ifbecb9a6e25f7af38e20b7d7830df7f5efe2798a
Reviewed-on: https://go-review.googlesource.com/c/go/+/288820
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
- Add Windows SystemInfo constant for arm64
- Add windows/arm64 to GOOS/GOARCH list
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I6109bd87512b5cb1d227d7a85fd0ac20eb2259e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288819
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We used to clear GOPATH in all the build scripts.
Clearing GOPATH is misleading at best, since you just end up
with the default GOPATH (%USERPROFILE%\go on Windows).
Unless that's your GOROOT, in which case you end up with a
fatal error from the go command (#43938).
run.bash changed to setting GOPATH=/dev/null, which has no
clear analogue on Windows.
run.rc still clears GOPATH.
Change them all to set GOPATH to a non-existent directory
/nonexist-gopath or c:\nonexist-gopath.
Change-Id: I51edd66d37ff6a891b0d0541d91ecba97fbbb03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288818
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This matches the prints that deadcode prints later
as the algorithm progresses under -v=2.
It helps to see the initial conditions with -v=2 as well.
Change-Id: I06ae86fe9bd8314d003148f3d941832c9b10aef1
Reviewed-on: https://go-review.googlesource.com/c/go/+/288817
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A bunch of places are a bit too picky about the architecture.
Simplify them.
Also use a large PEBASE for 64-bit systems.
This more closely matches what is usually used on Windows x86-64
and is required for Windows arm64.
Unfortunately, we still need a special case for x86-64 because
of some cgo relocations. This may be fixable separately.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I65212d28ad4d8c40e2b70dc29f7fce072babecb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288816
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The files being deleted contain no code.
They exist because back when we used Makefiles
that listed all the Go sources to be compiled, we wrote
patterns like syscall_$GOOS_$GOARCH.go,
and it was easier to create dummy empty files
than introduce conditionals to not look for that
file on Windows.
Now that we have the go command instead,
we don't need those dummy files.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ie0066d1dd2bf09802c74c6a496276e8c593e4bc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/288815
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Frame pointers were already enabled on linux, darwin, ios,
but not freebsd, android, openbsd, netbsd.
But the space was reserved on all platforms, leading to
two different arm64 framepointer conditions in different
parts of the code, one of which had no name
(framepointer_enabled || GOARCH == "arm64",
which might have been "framepointer_space_reserved").
So on the disabled systems, the stack layouts were still
set up for frame pointers and the only difference was not
actually maintaining the FP register in the generated code.
Reduce complexity by just enabling the frame pointer
completely on all the arm64 systems.
This commit passes on freebsd, android, netbsd.
I have not been able to try it on openbsd.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I83bd23369d24b76db4c6a648fa74f6917819a093
Reviewed-on: https://go-review.googlesource.com/c/go/+/288814
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Document the various hard-coded architecture checks
or remove them in favor of more general checks.
This should be a no-op now but will make the arm64 port
have fewer diffs.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ifd6b19e44e8c9ca4a0d2590f314928ce235821b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/288813
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Externalthreadhandler was not handling its own stack correctly.
It incorrectly referred to the saved LR slot (uninitialized, it turned out)
as holding the return value from the called function.
Externalthreadhandler is used to call two different functions:
profileloop1 and ctrlhandler1.
Profileloop1 does not return, so no harm done.
Ctrlhandler1 returns a boolean indicating whether the handler
took care of the control event (if true, no other handlers run).
It's hard to say exactly what uninitialized values are likely to
have been returned instead of ctrlhandler1's result, but it
probably wasn't helping matters.
Change-Id: Ia02f1c033df618cb82c2193b3a8241ed048a8b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/288812
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This code has clearly never run successfully,
since one of the “tail calls" calls the wrong function,
and both of them appear in functions with stack frames
that are never going to be properly unwound.
Probably there is no windows/arm under WINE at all.
But might as well fix the code.
Change-Id: I5fa62274b3661bc6bce098657b5bcf11d59655eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/288811
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
The isAbort check was wrong for non-x86 systems.
That was causing the exception chain to be passed back to Windows.
That was causing some other kind of fault - not sure what.
That was leading back to lastcontinuehandler to print a larger
stack trace, and then the throwing = 1 print added runtime.abort,
which made TestAbort pass even though it wasn't really working.
Recognize abort properly and handle it as Go, not as something
for Windows to try to handle.
Keep the throwing = 1 print, because more detail on throw is
always better.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: If614f4ab2884bd90410d29e28311bf969ceeac09
Reviewed-on: https://go-review.googlesource.com/c/go/+/288810
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If traceback fails, it prints a helpful hex dump of the stack.
But the hex numbers have no 0x prefix, which might make it
a little unclear that they are hex.
We only print two per line, so there is plenty of room for the 0x.
Print it, which lets us delete a custom hex formatter.
Also, in the translated <name+off> hints, print off in hex
(with a 0x prefix). The offsets were previously decimal, which
could have been confused for hex since none of the hex had
0x prefixes. And decimal is kind of useless anyway since the
offsets shown in the main traceback are hex, so you can't
easily match them up without mental base conversions.
Just print hex everywhere, clearly marked by 0x.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I72d26a4e41ada38b620bf8fe3576d787a2e59b47
Reviewed-on: https://go-review.googlesource.com/c/go/+/288809
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The constant was wrong, and the “right” constant doesn't work either.
But with the actually-right constant (and possibly earlier fixes in this
stack as well), profiling now works.
Change-Id: If8caff1da556826db40961fb9bcfe2b1f31ea9f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/288808
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Also give up on the fiction that these files can be regenerated.
They contain many manual edits, and they're fairly small anyway.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ib4e4e20a43d8beb1d5390fd184160c33607641f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288807
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The architecture-specific interpretation of m->tls[0]
is unnecessary and fragile. Delete it.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I927345e52fa2f1741d4914478a29d1fb8acb0dc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/288806
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This was added in 2018 to fix a runtime crash during unwind
during a unhandled-panic-induced crash.
(See https://golang.org/cl/90895 and #23576.)
Clearly we cannot unwind past this function, and the change
did stop the unwind. But it's not a top-of-stack function, and
the real issue is that SP is changed.
The new SPWRITE bit takes care of this instead, so we can drop
it from the topofstack function.
At this point the topofstack function is only checking the
TOPFRAME bit, so we can inline that into the one call site.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I856552298032770e48e06c95a20823a1dbd5e38c
Reviewed-on: https://go-review.googlesource.com/c/go/+/288805
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I added morestack to this list in 2013 with an explanation
that they were needed if we “start a garbage collection on g0
during a stack split or unsplit”.
(https://golang.org/cl/11533043)
This explanation no longer applies for a handful of reasons,
most importantly that if we did stop a stack scan in the middle
of a call to morestack, we'd ignore pointers above the split,
which would lead to memory corruption. But we don't scan
goroutine stacks during morestack now, so that can't happen.
If we did see morestack during a GC, that would be a good time
to crash the program.
The real problem with morestack is during profiling, as noted
in the code review conversation during 2013. And in profiling
we just need to know to stop and not unwind further, which
the new SPWRITE bit will do for us.
So remove from topofstack and let the program crash if GC
sees morestack and otherwise let the SPWRITE stop morestack
unwinding during profiling.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I06d95920b18c599c7c46f64c21028104978215d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/288804
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I added mcall to this list in 2013 without explaining why.
(https://codereview.appspot.com/11085043/diff/61001/src/pkg/runtime/traceback_x86.c)
I suspect I was stopping crashes during profiling where the unwind
tried to walk up past mcall and got confused.
mcall is not something you can unwind past, because it switches
stacks, but it's also not something you should expect as a
standard top-of-stack frame. So if you do see it during say
a garbage collection stack walk, it would be important to crash
instead of silently stopping the walk prematurely.
This CL removes it from the topofstack list to avoid the silent stop.
Now that mcall is detected as SPWRITE, that will stop the
unwind (with a crash if encountered during GC, which we want).
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I666487ce24efd72292f2bc3eac7fe0477e16bddd
Reviewed-on: https://go-review.googlesource.com/c/go/+/288803
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
