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>
Currently, gentraceback consumes the gp.cgoCtxt slice by copying the
slice header and then sub-slicing it as it unwinds. The code for this
is nice and clear, but we're about to lift this state into a structure
and mutating it is going to introduce write barriers that are
disallowed in gentraceback.
This CL replaces the mutable slice header with an index into
gp.cgoCtxt.
For #54466.
Change-Id: I6b701bb67d657290a784baaca34ed02d8247ede2
Reviewed-on: https://go-review.googlesource.com/c/go/+/466863
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This converts all places in the runtime that perform inline expansion
to use the new inlineUnwinder abstraction.
For #54466.
Change-Id: I48d996fb6263ed5225bd21d30914a27ae434528d
Reviewed-on: https://go-review.googlesource.com/c/go/+/466099
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
We're about to rewrite this code and it has almost no test coverage
right now.
This test is also more complete than the existing
TestTracebackInlineExcluded, so we delete that test.
For #54466.
Change-Id: I144154282dac5eb3798f7d332b806f44c4a0bdf6
Reviewed-on: https://go-review.googlesource.com/c/go/+/466098
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Since srcFunc can represent information for either an real text
function or an inlined function, this means we no longer have to
synthesize a fake _func just to call showframe on an inlined frame.
This is cleaner and also eliminates the one case where _func values
live in the heap. This will let us mark them NotInHeap, which will in
turn eliminate pesky write barriers in the traceback rewrite.
For #54466.
Change-Id: Ibf5e24d01ee4bf384c825e1a4e2922ef444a438e
Reviewed-on: https://go-review.googlesource.com/c/go/+/466097
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We've replicated the code to expand inlined frames in many places in
the runtime at this point. This CL adds a simple iterator API that
abstracts this out.
We also use this to try out a new idea for structuring tests of
runtime internals: rather than exporting this whole internal data type
and API, we write the test in package runtime and import the few bits
of std we need. The idea is that, for tests of internals, it's easier
to inject public APIs from std than it is to export non-public APIs
from runtime. This is discussed more in #55108.
For #54466.
Change-Id: Iebccc04ff59a1509694a8ac0e0d3984e49121339
Reviewed-on: https://go-review.googlesource.com/c/go/+/466096
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Currently, gentraceback resolves the funcInfo of the caller prior to
processing the current frame (calling the callback, printing it, etc).
As a result, if this lookup fails in a verbose context, it will print
the failure before printing the frame that it's already resolved.
To fix this, move the resolution of LR to a funcInfo to after current
frame processing.
This also has the advantage that we can reduce the scope of "flr" (the
caller's funcInfo) to only the post-frame part of the loop, which will
make it easier to stack-rip gentraceback into an iterator.
For #54466.
Change-Id: I8be44d4eac598a686c32936ab37018b8aa97c00b
Reviewed-on: https://go-review.googlesource.com/c/go/+/458217
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
gentraceback also tracks the funcID of the callee, which is more
general. Fix this up to happen in all cases and eliminate waspanic in
favor of checking the funcID of the caller.
For #54466.
Change-Id: Idc98365a6f05022db18ddcd5b3ed8684a6872a88
Reviewed-on: https://go-review.googlesource.com/c/go/+/458216
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, gentraceback keeps a copy of the stack bounds of the stack
it's walking in the "stack" variable. Now that "gp" always refers to
the G whose stack it's walking, we can simply use gp.stack instead of
keeping a separate copy.
For #54466.
Change-Id: I68256e5dff6212cfcf14eda615487e66a92d4914
Reviewed-on: https://go-review.googlesource.com/c/go/+/458215
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're about to make major changes to tracebacks. We have benchmarks of
stack copying, but not of PC buffer filling, so add some that we can
track through these changes.
For #54466.
Change-Id: I3ed61d75144ba03b61517cd9834eeb71c99d74df
Reviewed-on: https://go-review.googlesource.com/c/go/+/472956
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
If there was a execution limit enabled, and a result put us beyond that
limit, but the result expanded coverage *and* was a duplicate of an
entry already in the cache, the check if we were passed the limit would
be skipped. Since this check was inside the result check body, and we
would no longer send any new inputs, we'd never get to that check again,
causing the coordinator to just sit in an infinite loop.
This moves the check up to the top of the coordinator loop, so that it
is checked after every result is processed. Also add a cmd/go TestScript
regression test which triggered this case much more frequently.
Updates #51484
Change-Id: I7a2181051177acb853c1009beedd334a40796177
Reviewed-on: https://go-review.googlesource.com/c/go/+/475196
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The stable counter is described in Section 2.2.10.4, LoongArch Reference Manual Volume 1.
Ref: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
Change-Id: I160b695a8c0e38ef49b21fb8b41460fd23d9538c
Reviewed-on: https://go-review.googlesource.com/c/go/+/421656
Reviewed-by: Meidan Li <limeidan@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Michael Pratt <mpratt@google.com>
This patch changes the relative order of "CanInline" and "InlineCalls"
operations within the inliner for clumps of functions corresponding to
strongly connected components in the call graph. This helps increase
the amount of inlining within SCCs, particularly in Go's runtime
package, which has a couple of very large SCCs.
For a given SCC of the form { fn1, fn2, ... fnk }, the inliner would
(prior to this point) walk through the list of functions and for each
function first compute inlinability ("CanInline") and then perform
inlining ("InlineCalls"). This meant that if there was an inlinable
call from fn3 to fn4 (for example), this call would never be inlined,
since at the point fn3 was visited, we would not have computed
inlinability for fn4.
We now do inlinability analysis for all functions in an SCC first,
then do actual inlining for everything. This results in 47 additional
inlines in the Go runtime package (a fairly modest increase
percentage-wise of 0.6%).
Updates #58905.
Change-Id: I48dbb1ca16f0b12f256d9eeba8cf7f3e6dd853cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/474955
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The test had been assuming that any 'gcc' or 'clang' command found in
$PATH could be used to compile cgo dependencies for the target GOARCH
and GOOS. That assumption does not hold in general: for example,
the GOARCH/GOOS configuration may be cross-compiling, which will cause
the test to fail if the native 'gcc' and/or 'clang' is not configured
for the target architecture.
Instead, leave the 'CC' variable unset and assume only that the user
has configured it appropriate to the environment in which they are
running the test.
For #58829.
Change-Id: I9a1269ae3e0b4af281702114dabba844953f74bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/475155
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On darwin, the external linker generally supports CALL relocations
with addend. One exception is that for a very large binary when it
decides to insert a trampoline, instead of applying the addend to
the call target (in the trampoline), it applies the addend to the
CALL instruction in the caller, i.e. generating a call to
trampoline+addend, which is not the correct address and usually
points to unreloated functions.
To work around this, we use label symbols so the CALL is targeting
a label symbol without addend. To make things simple we always use
label symbols for CALLs with addend (in external linking mode on
darwin/arm64), even for small binaries.
Fixes#58935.
Change-Id: I38aed6b62a0496c277c589b5accbbef6aace8dd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/474620
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Factor out check for identical origin.
Match unification code with type identity check.
Add a test case for #53692.
Change-Id: I1238b28297a5ac549e99261c8a085dd46f3dd65f
Reviewed-on: https://go-review.googlesource.com/c/go/+/474197
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Remove the compiler's "-wrapglobalmapinit" flag; it is potentially
confusing for users and isn't appropriate as a top level flag. Move
the enable/disable control to the "wrapglobalmapctl" debug flag
(values: 0 on by default, 1 disabled, 2 stress mode). No other changes
to compiler functionality.
Change-Id: I0d120eaf90ee34e29d5032889e673d42fe99e5dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/475035
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#58729
The reason why these deletions exist is that the old state.variable method
will assign the new value to the given key of map when the key doesn't exist,
but after this commit: 5a6e511c61 (diff-e754f9fc8eaf878714250cfc03844eb3b58185ac806a8c1c4f9fbabd86cda921L3972)
the state.variable doesn't do that anymore, thus these deletions became redundant.
Change-Id: Ie6e2471ca445f907a2bb1607c293f9301f0d73e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/471355
Run-TryBot: Andy Pan <panjf2000@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This reverts commit ce2a609909.
aka CL 462035
Reason for revert: this CL is causing some problems in some internal Google programs.
Change-Id: I4476b8d8d2c3d7b5703d1d85c93baebb4b4e5d26
Reviewed-on: https://go-review.googlesource.com/c/go/+/474976
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This reverts commit 99914db5ee.
aka CL 473875
Reason for revert: init order change that required this CL is causing some problems in some internal Google programs.
Change-Id: I801e278ab58d542c05c0332a9f1977b9588b6151
Reviewed-on: https://go-review.googlesource.com/c/go/+/474975
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
A previous iteration of the tracer's user annotation API had different
names for tasks and regions, and used to return functions for ending
them rather than types with End methods. This CL updates the doc
comments to reflect those changes, and also fixes up the internal
documentation of the events (similar to go.dev/cl/465335, the stack
argument was in the wrong place in the list).
The User Log event internal documentation might also look wrong since
the value argument follows the stack argument. However, the User Log
event is a special case where the log message is appended immediately
following the normal event, including the stack argument. There isn't
much room to clarify this next to the event type definitions, so this CL
clarifies the comment where the event is encoded.
Change-Id: I846c709f6026ef01c0a272557d6390b2c17074e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/472955
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Nick Ripley <nick.ripley@datadoghq.com>
This small PR allows optimizations made in io.Copy (like the use of
io.WriterTo) to be used in one possible path of http.ServeContent
(in case of a non-Range request).
This, in turn, allows us to skip the buffer allocation in io.Copy.
Change-Id: Ifa2ece206ecd4556aaaed15d663b65e95e00bb0a
GitHub-Last-Rev: 94fc031814
GitHub-Pull-Request: golang/go#56480
Reviewed-on: https://go-review.googlesource.com/c/go/+/446276
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Currently we fail to print errors from os.Open and profile.Parse of the
PGO profile, losing context useful to understand these errors.
In fixing this, cleanup error use overall to return an error from
pgo.New and report the problematic file at the top level.
Change-Id: Id7e9c781c4b8520eee96b6f5fe8a0b757d947f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/474995
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
This code is generic to ppc64/ppc64le - there is no need to limit it to
aix or linux.
Updates #56001
Change-Id: I613964a90f9c5ca637720219a0260d65427f4be0
Reviewed-on: https://go-review.googlesource.com/c/go/+/473697
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Because each M in Plan 9 runs in a separate OS process with its
own current working directory, a Chdir call in one goroutine needs
to be propagated to other goroutines before a subsequent syscall
with a local pathname (see #9428). This is done by function
syscall.Fixwd, but there is still a race if a goroutine is
preempted and rescheduled on a different M between calling Fixwd
and executing the syscall which it protects. By locking the
goroutine to its OS thread from the start of Fixwd to the end of
the protected syscall, this race can be prevented.
Fixes#58802.
Change-Id: I89c0e43ef4544b5bfb5db7d2158f13f24b42e1f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/474055
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
If the test actually deadlocks, we probably want a goroutine dump to
debug it anyway. Otherwise, the arbitrary timeout can only cause
spurious failures.
Fixes#36179.
Change-Id: Ic2037496959a38d3231eefdbc1dd5d45eebdf306
Reviewed-on: https://go-review.googlesource.com/c/go/+/474582
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ifb8d64f18b67c8b712feec29ffb6719c6e9718ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/474198
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This issue has been fixed with unified IR, so just add a test.
Update #53087
Change-Id: I965d9f27529fa6b7c89e2921c65e5a100daeb9fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/410197
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Keith Randall <khr@google.com>
buildinfo did not check for fat magic, which caused go version to report
unrecognized file format.
This change reads the fat file and passes the first arch file to machoExe.
Fixes#58796
Change-Id: I45cd26729352e46cc7ecfb13f2e9a8d96d62e0a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/473615
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This ISA 3.0 (power9) instruction is helpful for some string functions
in a future change.
Change-Id: I1a659488ffb5099f8c89f480c39af4ef9c4b556a
Reviewed-on: https://go-review.googlesource.com/c/go/+/472635
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add support for concurrently reading from an HTTP/1 request body
while writing the response.
Normally, the HTTP/1 server automatically consumes any remaining
request body before starting to write a response, to avoid deadlocking
clients which attempt to write a complete request before reading the
response.
Add a ResponseController.EnableFullDuplex method which disables this
behavior.
For #15527
For #57786
Change-Id: Ie7ee8267d8333e9b32b82b9b84d4ad28ab8edf01
Reviewed-on: https://go-review.googlesource.com/c/go/+/472636
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Also annotate calls to tooSlow with specific reasons.
This will somewhat reduce test coverage on the 'darwin' builders until
we have darwin 'longtest' builders (#35678,#49055), but still seems
worthwhile to avoid alert fatigue from tests that really shouldn't be
running in the short configurations.
Fixes#58918.
Fixes#58919.
Change-Id: I0000f0084b262beeec3eca3e9b8a45d61fab4313
Reviewed-on: https://go-review.googlesource.com/c/go/+/474137
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#58882
Change-Id: I65842a4aa3f808533e28128078e7e94a9b121404
Reviewed-on: https://go-review.googlesource.com/c/go/+/473915
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
reloctype_strings.go is out-of-date since CL 462035, regenerate it.
Found while working on CL 461737.
Change-Id: I5cf910ab14c3618d6653c87861a4d53d3c91feff
Reviewed-on: https://go-review.googlesource.com/c/go/+/473875
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Original version of TestWindowsStackMemory did not consider sysmon and
other threads running during the test. Allow for 5 extra threads in this
test - this should cover any new threads in the future.
Fixes#58570
Change-Id: I215790f9b94ff40a32ddd7aa54af715d1dc391c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/473415
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On ARM64, in -dynlink mode (building a shared library or a plugin),
accessing global variable is made using the GOT. Currently, the
GOT accessing instruction sequence our assembler generates doesn't
handle large offset well, so we don't fold the offset into loads
and stores in the compiler. Currently, the rewrite rules are
guarded with the -shared flag. However, the GOT access
instructions are only generated in the -dynlink mode (which
implies -shared, but not the other direction).
CL 445535 attempted to remove the guard althgether. But that
causes build failure for -dynlink mode for the reason above. This
CL changes it to guard specifically on -dynlink mode, allowing
the optimization in more cases (-shared but not -dynlink build
modes).
Updates #58826.
Change-Id: I1391db6a33e8d0455a304e7cae7fcfdeb49bfdab
Reviewed-on: https://go-review.googlesource.com/c/go/+/473999
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
No changes to non-tracing related code.
Change-Id: I3d004528281111a4479a02543a3e5443485182cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/474135
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Add functionality to retrieve values for .dynamic entries that don't
correspond to entries in the string table.
Fixes#56892
Change-Id: I6edabc8ca331c819e442d06e19b7f4df8343372b
Reviewed-on: https://go-review.googlesource.com/c/go/+/452617
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ib2c4ddec9740f7c21c180c9f0980394dceeedfaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/473975
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Previously if PrivateKey.Sign was called for Ed25519ctx with a context
longer than 255 bytes, the error message would mention Ed25519ph.
For Ed25519ph, the order of message length vs context length errors now
matches VerifyWithOptions. A message length error will be surfaced in
preference to a context length error. It also preferences hash errors
ahead of context length errors which also matches the behaviour of
VerifyWithOptions.
Change-Id: Iae380b3d879e0a9877ea057806fcd1e0ef7f7376
Reviewed-on: https://go-review.googlesource.com/c/go/+/473595
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
If a type doesn't implement an interface due to an ambiguous method,
say so in the error message instead of just reporting a missing method.
Fixes#57352.
Change-Id: I5608f893c485de578b7f86362ca6f66033653695
Reviewed-on: https://go-review.googlesource.com/c/go/+/473658
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
If a method is not found on a type V, for better error messages we
report if the method is on *V. There's no need to do a 2nd lookup
for that because the relevant information is readily returned by
lookupFieldOrMethod already.
Simplifies code and removes a long-standing TODO.
Change-Id: Ibdb2269b04c0db61bfe4641404ab1df330397b2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/473655
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This reverts CL 465805 (commit 3eedba50b1).
Reason for revert: The longtest on Windows was typoed, silently ignored, and it turns out it fails there.
Change-Id: I362e9a22a7ec569314a0da932730ba137a98ecda
Reviewed-on: https://go-review.googlesource.com/c/go/+/473795
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
