Just rely on the testsuite timeout. If this hangs we will hopefully
get some real information.
Fixes#57475
Change-Id: I18dc5cae54ad5d2d8cc472056b8a3b4d5455c8b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/476356
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Use the explicit API for acquiring an empty available buffer,
rather than the hack that's implemented in terms of Bytes and Len.
Change-Id: If286ed42693acd61ffe28dc849ed4b76c3ae4434
Reviewed-on: https://go-review.googlesource.com/c/go/+/476337
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This allows to use this helper function in packages other than syscall,
namely package net.
For #58114
Change-Id: I72c59ab013e9195801ff1315019ae1aef4396287
Reviewed-on: https://go-review.googlesource.com/c/go/+/476216
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This consolidates a condition that was previously repeated (in
different approximations) in several different places in the code.
For #58807.
Change-Id: Idd308759f6262b1f5c61f79022965612319edf94
Reviewed-on: https://go-review.googlesource.com/c/go/+/475457
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 475935 fixed the the ELFv2 ABI violations, but in the process created a
Go ABI violation by failing to allocate stack space for arguments.
Allocate this space while keeping the frame 16 byte aligned.
Updates #58953
Change-Id: I9942d9a433118b391ef8cd7bcea5808695cf94d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/476296
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As the comment on CodePad goes, we "might want to pad with a trap
instruction to catch wayward programs". The current behavior of
zero-padding is equivalent to padding with an instruction of 0x00000000,
which is invalid according to the LoongArch manuals nevertheless, but
rumor has it that some early and/or engineering samples of Loongson
3A5000 recognized it (maybe behaving like NOP). It is better to avoid
undocumented behavior and ensure execution flow would not overflow the
pads.
Change-Id: I531b1eabeb355e9ad4a2d5340e61f2fe71349297
Reviewed-on: https://go-review.googlesource.com/c/go/+/475616
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The canonical LoongArch NOP instruction form is "andi r0, r0, 0", as
described in the LoongArch Reference Manual Volume 1, Section 2.2.1.10.
We currently use NOR instead, which may or may not change anything (e.g.
performance on less capable micro-architectures) but is deviation from
upstream standards nevertheless. Fix them to use the explicit hardware
NOP which happens to be supported as `NOOP`.
Change-Id: I0a799a1da959e9c3b582feb88202df2bab0ab23a
Reviewed-on: https://go-review.googlesource.com/c/go/+/475615
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Remove the meaningless jump, and add the missing NOFRAME flag to _rt0_loong64_linux.
Change-Id: I1aec68c556615b42042684bd176dfc2a8af094d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/420977
Run-TryBot: M Zhuo <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: WANG Xuerui <git@xen0n.name>
In order to avoid a recursive call to ReadFrom, we were converting
a *File to an io.Writer. But all we really need to do is hide
the ReadFrom method. In particular, this gives us the option of
adding a WriteTo method.
For #58808
Change-Id: I20d3a45749d528c93c23267c467e607fc17dc83f
Reviewed-on: https://go-review.googlesource.com/c/go/+/475535
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This removes an allocation in Conn.grabConn that, while not super
important, was distracting me when optimizing code elsewhere.
While here, convert an atomic that was forgotten when this package was
earlier updated to use the new Go 1.19 typed atomics.
Change-Id: I4666256b4c0512e2162bd485c389130699f9d5ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/475415
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The tsan13 test highlighted a few bugs.
The first being runtime.sigprofNonGoWrapper was being
called from C code and violating the C ABI.
The second was a missed tsan acquire/release after
thread creation.
The third was runtime.cgoSigtramp violating ELFv2
ABI constraints when loading g. It is reworked to
avoid clobbering R30 and R31 via runtime.load_g.
Change-Id: Ib2d98047fa1b4e72b8045767e86457a8ddfe492e
Reviewed-on: https://go-review.googlesource.com/c/go/+/475935
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This patch changes the Go command to examine the set of compiler
flags feeding into the C compiler when packages that use cgo are built.
If any of a specific set of strange/dangerous flags are in use,
then the Go command generates a token file ("preferlinkext") and
embeds it into the compiled package's archive.
When the Go linker reads the archives of the packages feeding into the
link and detects a "preferlinkext" token, it will then use external
linking for the program by default (although this default can be
overridden with an explicit "-linkmode" flag).
The intent here is to avoid having to teach the Go linker's host object
reader to grok/understand the various odd symbols/sections/types that
can result from boutique flag use, but rather to just boot the objects
in question over to the C linker instead.
Updates #58619.
Updates #58620.
Updates #58848.
Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/475375
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Microsoft's PE documentation is contradictory. It says that the
symbol's complex type [1] is stored in the pesym.Type most significant
byte (MSB), but MSVC, LLVM, and mingw store it in the 4 high bits of
the less significant byte (LSB). dumpbin understands both encoding.
Previous to CL 475355 the Go compiler mixed MSB and LSB encoding.
CL 475355 updated to compiler to use the MSB, but this causes problems
with mingw, which emits a warning when MSB is used.
For reference, LLVM also hit this issue long time ago:
https://github.com/llvm/llvm-project/issues/8692
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#type-representation
Change-Id: I7e750bde9c20e2c4c1c023203d7abd6fb26d9d30
Reviewed-on: https://go-review.googlesource.com/c/go/+/475855
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The problem requiring a revert was creation (somehow) of /-containing
paths in compiler messages on Windows. The new code deals with this
existing-but-unexpected behavior.
original was CL 465805
revert was CL 473795
this is the original, plus a correction for unexpected paths on Windows.
Change-Id: I786e875e704c2d7018c8248960f2ff7188cac3ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/474015
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: David Chase <drchase@google.com>
This CL add support for instrinsifying the TrialingZeros{8,32,64}
functions for 386 architecture. We need handle the case when the input
is 0, which could lead to undefined output from the BSFL instruction.
Next CL will remove the assembly code in runtime/internal/sys package.
Change-Id: Ic168edf68e81bf69a536102100fdd3f56f0f4a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/475735
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Lowercase letters occur more frequently than uppercase letters
in English text. In IsWordChar, evaluate the most common case
(lowercase letters) first to minimize the expected value of its
execution time. Code clarity does not suffer by rearranging the
order of the checks.
Add a benchmark on a sentence demonstrating the performance
improvement.
name old time/op new time/op delta
IsWordChar-10 122ns ± 0% 114ns ± 1% -6.68% (p=0.000 n=8+10)
Change-Id: Ieee8126a4bd8ee8703905b4f75724623029f6fa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/404100
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: thepudds <thepudds1460@gmail.com>
The former does not exist (yet) but the latter very much exists and is in active use.
Change-Id: Ic8812b98a10f01061a211a0de4caa9e9cfff36fa
GitHub-Last-Rev: 0dab9f524c
GitHub-Pull-Request: golang/go#59014
Reviewed-on: https://go-review.googlesource.com/c/go/+/476016
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, in -N mode we skip the tighten pass. However, for very
large functions, many values live across blocks can cause
pathological behavior in the register allocator, which could use
a huge amount of memory or cause the program to hang. For
functions that large, debugging using a debugger is unlikely to be
very useful (the function is probably generated anyway). So we do
a little optimization to make fewer values live across blocks and
make it easier for the compiler.
Fixes#52180.
Change-Id: I355fe31bb87ea5d0870bb52dd06405dd5d791dab
Reviewed-on: https://go-review.googlesource.com/c/go/+/475339
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The Testing function reports whether the program is a test created
by "go test".
Fixes#52600
Change-Id: Ie0fff7c7dfdfdf997c18b4b6112632600b327cc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/475496
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This change eliminates the easy, arbitrary timouts that should
never happen. It leaves in place a couple of more complicated ones
that will probably need retry loops for robustness.
For #49336.
For #36179.
Change-Id: I657ef223a66461413a915da5ce9150f49acec04a
Reviewed-on: https://go-review.googlesource.com/c/go/+/476035
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Creates x509.RevocationListEntry, a new type representing a single
revoked certificate entry in a CRL. Like the existing Certificate and
RevocationList types, this new type has a field for its Raw bytes, and
exposes its mostly-commonly-used extension (ReasonCode) as a top-level
field. This provides more functionality to the user than the existing
pkix.RevokedCertificate type.
Adds a RevokedCertificateEntries field which is a []RevocationListEntry
to RevocationList. This field deprecates the RevokedCertificates field.
When the RevokedCertificates field is removed in a future release, this
will remove one of the last places where a pkix type is directly exposed
in the x509 package API.
Updates the ParseRevocationList function to populate both fields for
now, and updates the CreateRevocationList function to prefer the new
field if it is populated, but use the deprecated field if not. Finally,
also updates the x509 unit tests to use the new .ReasonCode field in
most cases.
Fixes#53573
Change-Id: Ia6de171802a5bd251938366508532e806772d7d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/468875
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
CLONE_NEWTIME can only be used with the clone3 and unshare system calls,
see 769071ac9f:
> All available clone flags have been used, so CLONE_NEWTIME uses the highest
> bit of CSIGNAL. It means that it can be used only with the unshare() and
> the clone3() system calls.
The clone3 syscall was added in Linux kernel version 5.3 and
CLONE_NEWTIME was added in version 5.6. However, it was non-functional
until version 6.3 (and stable versions with the corresponding fix [1]).
[1] https://lore.kernel.org/lkml/20230308105126.10107-1-tklauser@distanz.ch/
In case CLONE_NEWTIME is set in SysProcAttr.Cloneflags on an unsupported
kernel version, the fork/exec call will fail.
Fixes#49779
Change-Id: Ic3ecfc2b601bafaab12b1805d7f9512955a8c7e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/474356
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The assumptions of some of the assembly functions were still scarcely
documented and even disregarded: p256ScalarMult was relying on the fact
that the "undefined behavior" of p256PointAddAsm with regards to
infinity inputs was returning the infinity.
Aside from expanding comments, moving the bit window massaging into a
more easily understood p256OrdRsh function, and fixing the above, this
change folds the last iteration of p256ScalarMult into the loop to
reduce special cases and inverts the iteration order of p256BaseMult so
it matches p256ScalarMult for ease of comparison.
Updates #58647
Change-Id: Ie5712ea778aadbe5adcdb478d111c2527e83caa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/471256
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
This change fixes time.LoadLocationFromTZData and time.Location.lookup logic if the given time is after the last transition and the extend string doesn't have the DST rule.
Fixes#58682
Change-Id: Ie34a6d658d14c2b33098b29ab83c041ef0d34266
GitHub-Last-Rev: f6681eb44c
GitHub-Pull-Request: golang/go#58684
Reviewed-on: https://go-review.googlesource.com/c/go/+/471020
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
This adds a new Buffer.AvailableBuffer method that returns
an empty buffer with a possibly non-empty capacity for use
with append-like APIs.
The typical usage pattern is something like:
b := bb.AvailableBuffer()
b = appendValue(b, v)
bb.Write(b)
It allows logic combining append-like APIs with Buffer
to avoid needing to allocate and manage buffers themselves and
allows the append-like APIs to directly write into the Buffer.
The Buffer.Write method uses the builtin copy function,
which avoids copying bytes if the source and destination are identical.
Thus, Buffer.Write is a constant-time call for this pattern.
Performance:
BenchmarkBufferAppendNoCopy 2.909 ns/op 5766942167.24 MB/s
This benchmark should only be testing the cost of bookkeeping
and never the copying of the input slice.
Thus, the MB/s should be orders of magnitude faster than RAM.
Fixes#53685
Change-Id: I0b41e54361339df309db8d03527689b123f99085
Reviewed-on: https://go-review.googlesource.com/c/go/+/474635
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: Ia110d19fe5ff3adc8bbf86dd2112f9702164d495
Reviewed-on: https://go-review.googlesource.com/c/go/+/475515
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The vast majority of users of Go toolchains have no need for
binaries like the go command and compiler to include DWARF
information, and the DWARF information is 34% of the size of
the overall Go toolchain zip files (14% when the toolchain is
unzipped on disk, because other parts get bigger).
To save network and disk, disable DWARF in build release binaries.
DWARF remains enabled when developing in the main branch
(signaled by no VERSION file existing), for better debuggability
when actually working on the compiler and go command.
Note that removing DWARF does not break the backtraces shown
when a binary panics, nor does it break other uses of stack traces
from within a Go program, such as runtime.Callers.
To build a release toolchain with DWARF included, people can use
GO_LDFLAGS=-w=0 ./make.bash
Change-Id: Ib0bbe1446adca4599066b2fb2f2734e6825c1106
Reviewed-on: https://go-review.googlesource.com/c/go/+/475378
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix a few lingering reproducibility problems.
- Do not set CC during go install std if it is unset,
so that the automatic disabling of cgo in cmd/go can run.
- Since CC is not necessary, remove code insisting on it.
- Use a fixed quoting algorithm instead of %q from the
bootstrap toolchain, which can differ from release to release.
- Remove go_bootstrap tool successfully on Windows.
For #24904.
Change-Id: I5c29ba6a8592e93bfab37f123b69f55c02f12ce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/475377
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL removes the NOFRAME flag from runtime.asmcgocall,
runtime.systemstack and runtime.mcall so the compiler can place
the frame pointer on the stack.
This will help unwinding cgo stack frames, and might be all what's
needed for tools that only use the frame pointer to unwind the stack.
That's not the case for gdb, which uses DWARF CFI, and windbg,
which uses SEH. Yet, having the frame pointer correctly set lays
the foundation for supporting cgo unwinding with DWARF CFI and SEH.
Updates #58378
Change-Id: I7655363b3fb619acccd9d5a7f0e3d3dec953cd52
Reviewed-on: https://go-review.googlesource.com/c/go/+/472195
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL moves the usleep2HighRes from assembly to good old Go.
This is safe because since CL 288793 usleep is always called with
a g, else one wold have to call usleep_no_g. This condition was
not enforced when high resolution timers were first implemented
on Windows (CL 248699), so the implementation was done in assembly.
Other than removing a bunch of obscure assembly code, this CL makes
high resolution timers work on windows arm/arm64 by free, as the
system calls are the same in all windows platforms.
Change-Id: I41ecf78026fd7e11e85258a411ae074a77e8c7fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/471142
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Fixes#41198
Change-Id: Ib33a11d0eb311f8e2b81de24d11df49e00b2fc81
Reviewed-on: https://go-review.googlesource.com/c/go/+/473935
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL updates IMAGE_SYM_DTYPE_FUNCTION and IMAGE_SYM_DTYPE_ARRAY
definition and usage so their value can be set to what's defined in
the Microsoft PE docs [1], fixing a long-standing TODO.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#type-representation
Change-Id: I93c19eb78e8a770e8c72245fe9495647e2c5ae5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/475355
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The test unconditionally calls testenv.GoToolPath, which will skip the
test anyway. Moving the skip earlier gets this test out of goroutine
dumps if the test process fails or times out, making it easier to
diagnose failures in the remaining tests.
Change-Id: Ibd39546708a83b6f15616b2c4ae7af420e2401f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/475455
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Many of the tests skipped platforms that build PIE binaries by
default, but (still) lack a central function to report which platforms
those are.
Some of the tests assumed (but did not check for) internal linking
support, or invoked `go tool link` directly without properly
configuring the external linker.
A few of the tests seem to be triggering latent bugs in the linker.
For #58806.
For #58807.
For #58794.
Change-Id: Ie4d06b1597f404590ad2abf978d4c363647407ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/472455
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Pass type checker error codes to base.ErrorfAt function calls
in the compiler (but don't do anything yet with the code).
Also, provide error codes to base.ErrorfAt calls in the
compiler as needed.
This opens the door towards reporting the error code and/or
providing a link/reference to more detailed explanations
(see internal/types/errors/codes.go).
Change-Id: I0ff9368d8163499ffdac6adfe8331fdc4a19b4b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/475198
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Printing is the only remaining functionality of gentraceback. Move
this into the traceback printing code and eliminate gentraceback. This
lets us simplify the logic, which fixes at least one minor bug:
previously, if inline unwinding pushed the total printed count over
_TracebackMaxFrames, we would print extra frames and then fail to
print "additional frames elided".
The cumulative performance effect of the series of changes starting
with "add a benchmark of Callers" (CL 472956) is:
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
│ baseline │ unwinder │
│ sec/op │ sec/op vs base │
Callers/cached-48 1.464µ ± 1% 1.684µ ± 1% +15.03% (p=0.000 n=20)
Callers/inlined-48 1.391µ ± 1% 1.536µ ± 1% +10.42% (p=0.000 n=20)
Callers/no-cache-48 10.50µ ± 1% 11.11µ ± 0% +5.82% (p=0.000 n=20)
StackCopyPtr-48 88.74m ± 1% 81.22m ± 2% -8.48% (p=0.000 n=20)
StackCopy-48 80.90m ± 1% 70.56m ± 1% -12.78% (p=0.000 n=20)
StackCopyNoCache-48 2.458m ± 1% 2.209m ± 1% -10.15% (p=0.000 n=20)
StackCopyWithStkobj-48 26.81m ± 1% 25.66m ± 1% -4.28% (p=0.000 n=20)
geomean 518.8µ 512.9µ -1.14%
The performance impact of intermediate CLs in this sequence varies a
lot as we went through many refactorings. The slowdown in Callers
comes primarily from the introduction of unwinder because that doesn't
get inlined and results in somewhat worse code generation in code
that's extremely hot in those microbenchmarks. The performance gains
on stack copying come mostly from replacing callbacks with direct use
of the unwinder.
Updates #54466.
Fixes#32383.
Change-Id: I4970603b2861633eecec30545e852688bc7cc9a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/468301
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, filling PC traceback buffers is one of the jobs of
gentraceback. This moves it into a new function, tracebackPCs, with a
simple API built around unwinder, and changes all callers to use this
new API.
Updates #54466.
Change-Id: Id2038bded81bf533a5a4e71178a7c014904d938c
Reviewed-on: https://go-review.googlesource.com/c/go/+/468300
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently, gentraceback's loop ends with a call to tracebackCgoContext
to process cgo frames. This requires spreading various parts of the
printing and pcbuf logic across these two functions.
Clean this up by moving cgo unwinding into unwinder and then lifting
the printing and pcbuf logic from tracebackCgoContext into
gentraceback along with the other printing and pcbuf logic.
Updates #54466.
Change-Id: Ic71afaa5ae110c0ea5be9409e267e4284e36a8c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/468299
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Many compiler-generated panics are dynamically changed to a "throw"
when they happen in the runtime. One effect of this is that they are
allowed in nowritebarrierrec contexts. Currently, the unsafe.Slice
panics don't have this treatment.
We're about to expose more code that uses unsafe.Slice to the write
barrier checker (it's actually already there and it just can't see
through an indirect call), so give these panics the dynamic check.
Very indirectly updates #54466.
Change-Id: I65cb96fa17eb751041e4fa25a1c1bd03246c82ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/468296
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently, all stack walking logic is in one venerable, large, and
very, very complicated function: runtime.gentraceback. This function
has three distinct operating modes: printing, populating a PC buffer,
or invoking a callback. And it has three different modes of unwinding:
physical Go frames, inlined Go frames, and cgo frames. It also has
several flags. All of this logic is very interwoven.
This CL reimplements the monolithic gentraceback function as an
"unwinder" type with an iterator API. It moves all of the logic for
stack walking into this new type, and gentraceback is now a
much-simplified wrapper around the new unwinder type that still
implements printing, populating a PC buffer, and invoking a callback.
Follow-up CLs will replace uses of gentraceback with direct uses of
unwinder.
Exposing traceback functionality as an iterator API will enable a lot
of follow-up work such as simplifying the open-coded defer
implementation (which should in turn help with #26813 and #37233),
printing the bottom of deep stacks (#7181), and eliminating the small
limit on CPU stacks in profiles (#56029).
Fixes#54466.
Change-Id: I36e046dc423c9429c4f286d47162af61aff49a0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/458218
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
