| Age | Commit message (Collapse) | Author |
|---|
|
This patch removes redundant guards for the crash stack feature, as all
supported Go architectures now have a crash stack implementation.
Change-Id: I7ffb61c57955778d687073418130b2aaab0ff183
GitHub-Last-Rev: 6ff56d6420093ee8f95c75019557dc8bcec32ed7
GitHub-Pull-Request: golang/go#67202
Reviewed-on: https://go-review.googlesource.com/c/go/+/583416
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
|
|
Change-Id: Ic6fcdfb6a9a912a9b1dd268836d2e5ab44d80440
GitHub-Last-Rev: dab6ecc0660d3e0f8e23944286f965a3bb15b4cb
GitHub-Pull-Request: golang/go#65305
Reviewed-on: https://go-review.googlesource.com/c/go/+/558698
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
|
|
Change-Id: Ib787b27670ad0f10bcc94b3ce76e86746997af00
GitHub-Last-Rev: e5abb9a556ae709d30d6ffb5a13805923c215254
GitHub-Pull-Request: golang/go#65934
Reviewed-on: https://go-review.googlesource.com/c/go/+/566715
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Change-Id: Ide4002d1cf82f2daaf7261b367c391dedbbf7719
GitHub-Last-Rev: 80ee248c3e34529e7a522acc97db9fb69c82dffb
GitHub-Pull-Request: golang/go#65308
Reviewed-on: https://go-review.googlesource.com/c/go/+/558699
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: Icc2641b888440cc27444b5dfb2b8ff286e6a595d
GitHub-Last-Rev: f5772e32e9190ab1eed94fcf2c9e58d6bc0d74d6
GitHub-Pull-Request: golang/go#63923
Reviewed-on: https://go-review.googlesource.com/c/go/+/539536
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Change-Id: Ie923f7bbe5ef22e381ae4f421387fbd570622a28
GitHub-Last-Rev: f8f21635025eb6e26c6994679995ade501e870cf
GitHub-Pull-Request: golang/go#63908
Reviewed-on: https://go-review.googlesource.com/c/go/+/539296
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
|
|
Currently if morestack on g0 happens the wasm runtime prints
"RuntimeError: memory access out of bounds", which is quite misleading.
By switching to a crash stack we can get better stacktraces
for the error.
There is no way to automate tests for this feature on wasm, since
TestG0StackOverflow relies on spawning a subprocess which is not
supported by the wasm port.
The way I got this tested manually is to comment everything in
TestG0StackOverflow, leaving just runtime.G0StackOverflow().
Then it is a matter of invoking the test:
GOOS=js GOARCH=wasm go test runtime -v -run=TestG0StackOverflow
Change-Id: If450f3ee5209bb32efc1abd0a34b1cc4a29d0c46
GitHub-Last-Rev: 0d7c396e4cfeadc1188cae2b55661af10c8189e7
GitHub-Pull-Request: golang/go#63956
Reviewed-on: https://go-review.googlesource.com/c/go/+/539995
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Change-Id: I8d1011509c4f0f529e97055280606603747a2e1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/541775
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
|
|
Change-Id: I240ea7dd6430f4c89cfdadbfa790e4a70a4fd79d
GitHub-Last-Rev: 585742b5eebad7c03ec313b590e2171491b78b37
GitHub-Pull-Request: golang/go#63905
Reviewed-on: https://go-review.googlesource.com/c/go/+/539295
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
|
|
Change-Id: Ib89a71e20f9c6b86c97814c75cb427e9bd7075e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/538735
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
|
|
Error like "morestack on g0" is one of the errors that is very
hard to debug, because often it doesn't print a useful stack trace.
The runtime doesn't directly print a stack trace because it is
a bad stack state to call print. Sometimes the SIGABRT may trigger
a traceback, but sometimes not especially in a cgo binary. Even if
it triggers a traceback it often does not include the stack trace
of the bad stack.
This CL makes it explicitly print a stack trace and throw. The
idea is to have some space as an "emergency" crash stack. When the
stack is in a really bad state, we switch to the crash stack and
do a traceback.
Currently only implemented on AMD64 and ARM64.
TODO: also handle errors like "morestack on gsignal" and bad
systemstack. Also handle other architectures.
Change-Id: Ibfc397202f2bb0737c5cbe99f2763de83301c1c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/419435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
This patch contains the linker changes needed to enable deadcoding of
large unreferenced map variables, in combination with a previous
compiler change. We add a new cleanup function that runs just after
deadcode that looks for relocations in "init" funcs that are weak, of
type R_CALL (and siblings), and are targeting an unreachable function.
If we find such a relocation, after checking to make sure it targets a
map.init.XXX helper, we redirect the relocation to a point to a no-op
routine ("mapinitnoop") in the runtime.
Compilebench results for this change:
│ out.base.txt │ out.wrap.txt │
│ sec/op │ sec/op vs base │
Template 218.6m ± 2% 221.1m ± 1% ~ (p=0.129 n=39)
Unicode 180.5m ± 1% 178.9m ± 1% -0.93% (p=0.006 n=39)
GoTypes 1.162 ± 1% 1.156 ± 1% ~ (p=0.850 n=39)
Compiler 143.6m ± 1% 142.6m ± 1% ~ (p=0.743 n=39)
SSA 8.698 ± 1% 8.719 ± 1% ~ (p=0.145 n=39)
Flate 142.6m ± 1% 143.9m ± 3% ~ (p=0.287 n=39)
GoParser 247.7m ± 1% 248.8m ± 1% ~ (p=0.265 n=39)
Reflect 588.0m ± 1% 590.4m ± 1% ~ (p=0.269 n=39)
Tar 198.5m ± 1% 201.3m ± 1% +1.38% (p=0.005 n=39)
XML 259.1m ± 1% 260.0m ± 1% ~ (p=0.376 n=39)
LinkCompiler 746.8m ± 2% 747.8m ± 1% ~ (p=0.706 n=39)
ExternalLinkCompiler 1.906 ± 0% 1.902 ± 1% ~ (p=0.207 n=40)
LinkWithoutDebugCompiler 522.4m ± 21% 471.1m ± 1% -9.81% (p=0.000 n=40)
StdCmd 21.32 ± 0% 21.39 ± 0% +0.32% (p=0.035 n=40)
geomean 609.2m 606.0m -0.53%
│ out.base.txt │ out.wrap.txt │
│ user-sec/op │ user-sec/op vs base │
Template 401.9m ± 3% 406.9m ± 2% ~ (p=0.291 n=39)
Unicode 191.9m ± 6% 196.1m ± 3% ~ (p=0.052 n=39)
GoTypes 3.967 ± 3% 4.056 ± 1% ~ (p=0.099 n=39)
Compiler 171.1m ± 3% 173.4m ± 3% ~ (p=0.415 n=39)
SSA 30.04 ± 4% 30.25 ± 4% ~ (p=0.106 n=39)
Flate 246.3m ± 3% 248.9m ± 4% ~ (p=0.499 n=39)
GoParser 518.7m ± 1% 520.6m ± 2% ~ (p=0.531 n=39)
Reflect 1.670 ± 1% 1.656 ± 2% ~ (p=0.137 n=39)
Tar 352.7m ± 2% 360.3m ± 2% ~ (p=0.117 n=39)
XML 528.8m ± 2% 521.1m ± 2% ~ (p=0.296 n=39)
LinkCompiler 1.128 ± 2% 1.140 ± 2% ~ (p=0.324 n=39)
ExternalLinkCompiler 2.165 ± 2% 2.147 ± 2% ~ (p=0.537 n=40)
LinkWithoutDebugCompiler 484.2m ± 4% 490.7m ± 3% ~ (p=0.897 n=40)
geomean 818.5m 825.1m +0.80%
│ out.base.txt │ out.wrap.txt │
│ text-bytes │ text-bytes vs base │
HelloSize 766.0Ki ± 0% 766.0Ki ± 0% ~ (p=1.000 n=40) ¹
CmdGoSize 10.02Mi ± 0% 10.02Mi ± 0% -0.03% (n=40)
geomean 2.738Mi 2.738Mi -0.01%
¹ all samples are equal
│ out.base.txt │ out.wrap.txt │
│ data-bytes │ data-bytes vs base │
HelloSize 14.17Ki ± 0% 14.17Ki ± 0% ~ (p=1.000 n=40) ¹
CmdGoSize 308.3Ki ± 0% 298.5Ki ± 0% -3.19% (n=40)
geomean 66.10Ki 65.04Ki -1.61%
¹ all samples are equal
│ out.base.txt │ out.wrap.txt │
│ bss-bytes │ bss-bytes vs base │
HelloSize 197.3Ki ± 0% 197.3Ki ± 0% ~ (p=1.000 n=40) ¹
CmdGoSize 228.2Ki ± 0% 228.1Ki ± 0% -0.01% (n=40)
geomean 212.2Ki 212.1Ki -0.01%
¹ all samples are equal
│ out.base.txt │ out.wrap.txt │
│ exe-bytes │ exe-bytes vs base │
HelloSize 1.192Mi ± 0% 1.192Mi ± 0% +0.00% (p=0.000 n=40)
CmdGoSize 14.85Mi ± 0% 14.83Mi ± 0% -0.09% (n=40)
geomean 4.207Mi 4.205Mi -0.05%
Also tested for any linker changes by benchmarking relink of k8s
"kubelet"; no changes to speak of there.
Updates #2559.
Updates #36021.
Updates #14840.
Change-Id: I4cc5370b3f20679a1065aaaf87bdf2881e257631
Reviewed-on: https://go-review.googlesource.com/c/go/+/463395
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
runtime.no_pointers_stackmap is an odd beast.
It is defined in a Go file, populated by assembly,
used by the GC, and its address is magic used
by async pre-emption to ascertain whether a
routine was implemented in assembly.
A subsequent change will force all GC data into the go.func.* linker symbol.
runtime.no_pointers_stackmap is GC data, so it must go there.
Yet it also needs to go into rodata, for the runtime address trick.
This change eliminates it entirely.
Replace the runtime address check with the newly introduced asm funcflag.
Handle the assembly macro as magic, similarly to our handling of go_args_stackmap.
This allows the no_pointers_stackmap to be identical in all ways
to other gclocals stackmaps, including content-addressability.
Change-Id: Id2f20a262cfab0719beb88e6342984ec4b196268
Reviewed-on: https://go-review.googlesource.com/c/go/+/353672
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
assembly functions
There are a few assembly functions in the runtime that are marked
as ABIInternal, solely because funcPC can get the right address.
The functions themselves do not actually follow ABIInternal (or
irrelevant). Now we have internal/abi.FuncPCABI0, use that, and
un-mark the functions.
Also un-mark assembly functions that are only called in assembly.
For them, it only matters if the caller and callee are consistent.
Change-Id: I240e126ac13cb362f61ff8482057ee9f53c24097
Reviewed-on: https://go-review.googlesource.com/c/go/+/321950
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
In case that we are panicking in ABI0 context or external code,
special registers are not initialized. Initialized them in
injected code before calling sigpanic.
TODO: Windows, Plan 9.
Change-Id: I0919b80e7cc55463f3dd94f1f63cba305717270a
Reviewed-on: https://go-review.googlesource.com/c/go/+/289710
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
CL [152537](https://go-review.googlesource.com/c/go/+/152537/) changed the way inlined frames are represented in tracebacks to no longer use skipPC
Change-Id: I42386fdcc5cf72f3c122e789b6af9cbd0c6bed4b
GitHub-Last-Rev: 79c26dcd532907eda4ffc30951845c1c01243501
GitHub-Pull-Request: golang/go#39829
Reviewed-on: https://go-review.googlesource.com/c/go/+/239701
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Part 1: CL 199499 (GOOS nacl)
Part 2: CL 200077 (amd64p32 files, toolchain)
Part 3: stuff that arguably should've been part of Part 2, but I forgot
one of my grep patterns when splitting the original CL up into
two parts.
This one might also have interesting stuff to resurrect for any future
x32 ABI support.
Updates #30439
Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/200318
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
runtime/asm.s contains two variable declarations that don't seem
needed. The variables are defined in Go and not referenced in
assembly. They were added in 2014 during the C to Go transition.
Maybe they were useful at that time, but not now. Remove them.
Change-Id: Id00d724813d18db47126c2f2b8cacfc9d77ffd4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/192378
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
|
|
This marks all Go symbols called from assembly in other packages with
"go:linkname" directives to ensure they get ABI wrappers.
Now that we have this go:linkname convention, this also removes the
abi0Syms definition in the runtime, which was used to give morestackc
an ABI0 wrapper. Instead, we now just mark morestackc with a
go:linkname directive.
This was tested with buildall.bash in the default configuration, with
-race, and with -gcflags=all=-d=ssa/intrinsics/off. Since I couldn't
test cgo on non-Linux configurations, I manually grepped for runtime
symbols in runtime/cgo.
Updates #31230.
Change-Id: I6c8aa56be2ca6802dfa2bf159e49c411b9071bf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/179862
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
There are three cases where we don't currently have the visibility to
get the ABIs of runtime symbols right, which this CL fixes:
1. For Go functions referenced from non-Go code in other packages.
This is runtime.morestackc (which is referenced from function
prologues) and a few syscall symbols. For these we need to generate
ABI0 wrappers, so this CL adds dummy calls in the assembly code to
force wrapper generation. There are many other cross-package
references to runtime and runtime/internal/atomic, but these are
handled specially by cmd/go.
2. For calls generated by the compiler to runtime Go functions, there
are a few symbols that aren't declared in builtins.go because we've
never needed their type information before. Now we at least need
their ABI information, so these are added to builtins.go.
3. For calls generated by the compiler to runtime assembly functions,
the compiler is going to assume the internal ABI is available, so
we add Go stubs to the runtime to trigger wrapper generation. For
these we're probably going to want to provide internal ABI
definitions directly in the assembly for performance, but for now
the ABIs are the same so it doesn't matter.
For #27539.
Change-Id: I9c224e7408d2ef4dd9b0e4c9d7e962ddfe111245
Reviewed-on: https://go-review.googlesource.com/c/146822
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
This commit adds the wasm architecture to the link command.
Design doc: https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4
Updates #18892
Change-Id: I5aef29954984537f2979679b5d393209e462f564
Reviewed-on: https://go-review.googlesource.com/103795
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
The `skip` argument passed to runtime.Caller and runtime.Callers should
be interpreted as the number of logical calls to skip (rather than the
number of physical stack frames to skip). This changes runtime.Callers
to skip inlined calls in addition to physical stack frames.
The result value of runtime.Callers is a slice of program counters
([]uintptr) representing physical stack frames. If the `skip` parameter
to runtime.Callers skips part-way into a physical frame, there is no
convenient way to encode that in the resulting slice. To avoid changing
the API in an incompatible way, our solution is to store the number of
skipped logical calls of the first frame in the _second_ uintptr
returned by runtime.Callers. Since this number is a small integer, we
encode it as a valid PC value into a small symbol called:
runtime.skipPleaseUseCallersFrames
For example, if f() calls g(), g() calls `runtime.Callers(2, pcs)`, and
g() is inlined into f, then the frame for f will be partially skipped,
resulting in the following slice:
pcs = []uintptr{pc_in_f, runtime.skipPleaseUseCallersFrames+1, ...}
We store the skip PC in pcs[1] instead of pcs[0] so that `pcs[i:]` will
truncate the captured stack trace rather than grow it for all i.
Updates #19348.
Change-Id: I1c56f89ac48c29e6f52a5d085567c6d77d499cf1
Reviewed-on: https://go-review.googlesource.com/37854
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
|
|
They are unused, and vet wants them to have
a function prototype.
Updates #11041
Change-Id: Idedc96ddd3c3cf1b1d2ab6d98796367eab29f032
Reviewed-on: https://go-review.googlesource.com/27492
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.
Go policy has been single space after periods in comments for some time.
The copyright header template at:
https://golang.org/doc/contribute.html#copyright
also uses a single space.
Make them all consistent.
Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The main change is that #include "zasm_GOOS_GOARCH.h"
is now #include "go_asm.h" and/or #include "go_tls.h".
Also, because C StackGuard is now Go _StackGuard,
the assembly name changes from const_StackGuard to
const__StackGuard.
In asm_$GOARCH.s, add new function getg, formerly
implemented in C.
The renamed atomics now have Go wrappers, to get
escape analysis annotations right. Those wrappers
are in CL 174860043.
LGTM=r, aram
R=r, aram
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/168510043
|
|
The goal here is to allow assembly functions to appear in the middle
of a Go stack (having called other code) and still record enough information
about their pointers so that stack copying and garbage collection can handle
them precisely. Today, these frames are handled only conservatively.
If you write
func myfunc(x *float64) (y *int)
(with no body, an 'extern' declaration), then the Go compiler now emits
a liveness bitmap for use from the assembly definition of myfunc.
The bitmap symbol is myfunc.args_stackmap and it contains two bitmaps.
The first bitmap, in effect at function entry, marks all inputs as live.
The second bitmap, not in effect at function entry, marks the outputs
live as well.
In funcdata.h, define new assembly macros:
GO_ARGS opts in to using the Go compiler-generated liveness bitmap
for the current function.
GO_RESULTS_INITIALIZED indicates that the results have been initialized
and need to be kept live for the remainder of the function; it causes a
switch to the second generated bitmap for the assembly code that follows.
NO_LOCAL_POINTERS indicates that there are no pointers in the
local variables being stored in the function's stack frame.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/137520043
|
