Fixes#31544
Change-Id: Ic99875ad227876eb741e93653589310327c9c0ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/477195
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For the following description, consider the following basic block graph:
b1 ───┐┌──── b2
││
││
▼▼
b3
For register allocator transitions between basic blocks, there are two
key passes (significant paraphrasing):
First, each basic block is visited in some predetermined visit order.
This is the core visitOrder range loop in regAllocState.regalloc. The
specific ordering heuristics aren't important here, except that the
order guarantees that when visiting a basic block at least one of its
predecessors has already been visited.
Upon visiting a basic block, that block sets its expected starting
register state (regAllocState.startRegs) based on the ending register
state (regAlloc.State.endRegs) of one of its predecessors. (How it
chooses which predecessor to use is not important here.)
From that starting state, registers are assigned for all values in the
block, ultimately resulting in some ending register state.
After all blocks have been visited, the shuffle pass
(regAllocState.shuffle) ensures that for each edge, endRegs of the
predecessor == startRegs of the successor. That is, it makes sure that
the startRegs assumptions actually hold true for each edge. It does this
by adding moves to the end of the predecessor block to place values in
the expected register for the successor block. These may be moves from
other registers, or from memory if the value is spilled.
Now on to the actual problem:
Assume that b1 places some value v1 into register R10, and thus ends
with endRegs containing R10 = v1.
When b3 is visited, it selects b1 as its model predecessor and sets
startRegs with R10 = v1.
b2 does not have v1 in R10, so later in the shuffle pass, we will add a
move of v1 into R10 to the end of b2 to ensure it is available for b3.
This is all perfectly fine and exactly how things should work.
Now suppose that b3 does not use v1. It does need to use some other
value v2, which is not currently in a register. When assigning v2 to a
register, it finds all registers are already in use and it needs to dump
a value. Ultimately, it decides to dump v1 from R10 and replace it with
v2.
This is fine, but it has downstream effects on shuffle in b2. b3's
startRegs still state that R10 = v1, so b2 will add a move to R10 even
though b3 will unconditionally overwrite it. i.e., the move at the end
of b2 is completely useless and can result in code like:
// end of b2
MOV n(SP), R10 // R10 = v1 <-- useless
// start of b3
MOV m(SP), R10 // R10 = v2
This is precisely what happened in #58298.
This CL addresses this problem by dropping registers from startRegs if
they are never used in the basic block prior to getting dumped. This
allows the shuffle pass to avoid placing those useless values into the
register.
There is a significant limitation to this CL, which is that it only
impacts the immediate predecessors of an overwriting block. We can
discuss this by zooming out a bit on the previous graph:
b4 ───┐┌──── b5
││
││
▼▼
b1 ───┐┌──── b2
││
││
▼▼
b3
Here we have the same graph, except we can see the two predecessors of
b1.
Now suppose that rather than b1 assigning R10 = v1 as above, the
assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the
value at all, and simply passes it through to endRegs R10 = v1.
Now the shuffle pass will require both b2 and b5 to add a move to
assigned R10 = v1, because that is specified in their successor
startRegs.
With this CL, b3 drops R10 = v1 from startRegs, but there is no
backwards propagation, so b1 still has R10 = v1 in startRegs, and b5
still needs to add a useless move.
Extending this CL with such propagation may significantly increase the
number of useless moves we can remove, though it will add complexity to
maintenance and could potentially impact build performance depending on
how efficiently we could implement the propagation (something I haven't
considered carefully).
As-is, this optimization does not impact much code. In bent .text size
geomean is -0.02%. In the container/heap test binary, 18 of ~2500
functions are impacted by this CL. Bent and sweet do not show a
noticeable performance impact one way or another, however #58298 does
show a case where this can have impact if the useless instructions end
up in the hot path of a tight loop.
For #58298.
Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/471158
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Previously, the reverse proxy is unable to detect
the support for hijack or flush if those things
are residing in the response writer in a wrapped
manner.
The reverse proxy now makes use of the new http
response controller as the means to discover
the underlying flusher and hijacker associated
with the response writer, allowing wrapped flusher
and hijacker become discoverable.
Change-Id: I53acbb12315c3897be068e8c00598ef42fc74649
Reviewed-on: https://go-review.googlesource.com/c/go/+/468755
Run-TryBot: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This presumably got missed in CL 393875.
Change-Id: I4f2de00ebd6ec405d5e289a7f8c2fc781607260b
Reviewed-on: https://go-review.googlesource.com/c/go/+/475617
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The backtrace knows to stop in the system stack due to writing to the SP,
so here the fake mstart caller in the system stack is no longer needed and
can be removed
ref. CL 288799
Change-Id: I0841e75fd515cf6a0d98abe4cffc3f63fc275e0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/416035
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Looks like CL 475735 contained a not-quite-up-to-date version
of the generated file. Maybe ABSFL was in an earlier version of the CL
and was removed before checkin without regenerating the generated file?
In any case, update the generated file. Shouldn't cause a problem, as
that field isn't used in x86/ssa.go.
Change-Id: I3f0b7d41081ba3ce2cdcae385fea16b37d7de81b
Reviewed-on: https://go-review.googlesource.com/c/go/+/477096
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
If the -url flag is provided, when encountering a type checking error,
the compiler will also print a URL to a more detailed description of
the error and an example, if available.
Example uses:
go tool compile -url filename.go
go build -gcflags=-url pkg/path
For instance, a duplicate declaration of an identifier will report
https://pkg.go.dev/internal/types/errors#DuplicateDecl
We may refine the provided URL over time.
Change-Id: Iabe3008a49d9dd88bf690f99e4a4a5432dc08786
Reviewed-on: https://go-review.googlesource.com/c/go/+/476716
Auto-Submit: Robert Griesemer <gri@google.com>
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>
When corpusEntryData failed in workerClient.fuzz and
workerClient.minimize, the shared memory mutex wasn't properly given up,
which would cause a deadlock when worker.cleanup was called.
This was tickled by #59062, wherein the fuzz cache directory would be
removed during operation of the fuzzer, causing corpusEntryData to fail
because the entry files no longer existed.
Updates #51484
Change-Id: Iea284041c20d1581c662bddbbc7e12191771a364
Reviewed-on: https://go-review.googlesource.com/c/go/+/476815
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
I think I confused myself in CL 476335. The TTY check did fix the
problem with os.Stdout, but it was still possible to get the same
problem in other ways. I fixed that by making the splice call blocking,
but it turns out that doing that is enough to fix the TTY problem also.
So we can just remove the TTY check.
Fixes#59041
Change-Id: I4d7ca9dad8361001edb4cfa96bb29b1badb54df0
Reviewed-on: https://go-review.googlesource.com/c/go/+/477035
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
These error codes are returned on windows in case a particular functions
is not supported.
Updates #41198
Change-Id: Ic31755a131d4e7c96961ba54f5bb51026fc7a563
Reviewed-on: https://go-review.googlesource.com/c/go/+/476916
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
but this time, correctly.
children of Returns can have For/Range loops in them,
and those must be visited.
Includes test to verify that the optimization occurs,
and also that the problematic case that broke the original
optimization is now correctly handled.
Change-Id: If5a94fd51c862d4bfb318fec78456b7b202f3fcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/472355
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The implementation for lockType, lock, unlock and isNotSupported is the
same on plan9 as on other platforms where filelocks are unsupported.
Change-Id: I8b9c0bdc429e23346ab9145ec3814622319427fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/476915
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As suggested by Bryan, also update (Errno).Is on windows to include the
missing oserror cases that are covered on other platforms.
Quoting Bryan:
> Windows syscalls don't actually return those errors, but the dummy Errno
> constants defined on Windows should still have the same meaning as on
> Unix.
Updates #41198
Change-Id: I15441abde4a7ebaa3c6518262c052530cd2add4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/476875
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The LoongArch ELF psABI v2.00 revamped the relocation design, largely
moving to using the `pcalau12i + addi/ld/st` pair for PC-relative
addressing within +/- 32 bits. The "pcala" in `pcalau12i` stands for
"PC-aligned add"; the instruction's semantics happen to coincide with
arm64's `adrp`.
Add support for emitting this instruction as part of the relevant
addressing ops, for use with new reloc types later.
Updates #58784
Change-Id: Ic1747cd9745aad0d1abb9bd78400cd5ff5978bc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/455016
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
The fuzzing cache for interesting inputs is shared across all
invocations of scripts by default. When 'go clean -fuzzcache' is called,
or fuzz targets in different scripts have the same names, we can get
race-y unexpected behavior.
Since there isn't a easy way to set just the fuzz cache directory (test
has the flag -test.fuzzcachedir, but it requires setting it on each call
to 'go test'), instead we just consistently set GOCACHE to point to a
directory in the WORK dir. As a byproduct this also prevents usage of a
shared build cache, so we see an increase in build time for these tests.
Updates #59062
Change-Id: Ie78f2943b94f3302c5bdf1f8a1e93b207853666a
Reviewed-on: https://go-review.googlesource.com/c/go/+/476755
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#53747
Based on CL 416514
Change-Id: I1ff79c6290b06dfa8672a473045e8fe80c22afcf
GitHub-Last-Rev: 74fba9b309
GitHub-Pull-Request: golang/go#59013
Reviewed-on: https://go-review.googlesource.com/c/go/+/476015
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Per the updated go.dev/wiki/Deprecated, those APIs replaced by
crypto/ecdh (added in Go 1.20) can now be marked as deprecated
in Go 1.21.
Updates #52221
Updates #34648
Change-Id: Id0e11d7faa3a58a1716ce1ec6e2fff97bab96259
Reviewed-on: https://go-review.googlesource.com/c/go/+/459977
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Meant to check if the slice was empty, accidentally dumped the entire
slice to stdout...
Change-Id: I968cb2f20ffb006e4dcfea65a1bad794aac05d17
Reviewed-on: https://go-review.googlesource.com/c/go/+/476795
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
In CL 466099, we accidentally stopped tracking callees while unwinding
inlined frames during traceback printing. The effect is that if you
have a call stack like:
f -> wrapper -> inlined into wrapper -> panic
when considering whether to print the frame for "wrapper", we'll think
that wrapper called panic, rather than the inlined function.
Fix this in the traceback code and add a test.
Change-Id: I30ec836cc316846ce93de94e28a650e23dca184e
Reviewed-on: https://go-review.googlesource.com/c/go/+/476579
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Also don't try to wait for a non-pollable FD.
Fixes#59041
Change-Id: Ife469d8738f2cc27c0beba223bdc8f8bc757b2a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/476335
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
As suggested by Bryan. This should fix the failing
TestIPConnSpecificMethods on plan9 after CL 476217 was submitted.
For #41198
Change-Id: I18e87b3aa7c9f7d48a1bd9c2819340acd1d2ca4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/476578
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also enable debugging information in TestScript/test_fuzz_cov, which
hits a deadlock on builders, but I am unable to trigger locally. This
should make it somewhat easier to track down where the issue actually
is.
Updates #51484
Change-Id: I98124f862242798f2d9eba15cacefbd02924cfe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/476595
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This change is a no-op, but makes the acquire-release pair
traceAcquireBuffer / traceReleaseBuffer more explicit, since the former
does acquirem and the latter releasm.
Change-Id: If8a5b1ba8709bf6f39c8ff27b2d3e0c0b0da0e58
Reviewed-on: https://go-review.googlesource.com/c/go/+/476575
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
As soon as the test server closes its listener, its port may be reused
for another test server. On some platforms port reuse takes a long
time, because they cycle through the available ports before reusing an
old one. However, other platforms reuse ports much more aggressively.
net/http shouldn't know or care which kind of platform it is on —
dialing wild connections is risky and can interfere with other tests
no matter what platform we do it on.
Instead of making the second request after the server has completely
shut down, we can start (and finish!) the entire request while we are
certain that the listener has been closed but the port is still open
serving an existing request. If everything synchronizes as we expect,
that should guarantee that the second request fails.
Fixes#56421.
Change-Id: I56add243bb9f76ee04ead8f643118f9448fd1280
Reviewed-on: https://go-review.googlesource.com/c/go/+/476036
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Tweak the code in trampoline generation that determines if a given
call branch will reach, changing the lower limit guard from "x <
-0x800000" to "x <= -0x800000". This is to resolve linking failures
when the computed displacement is exactly -0x800000, which results in
errors of the form
.../ld.gold: internal error in arm_branch_common, at ../../gold/arm.cc:4079
when using the Gold linker, and
...:(.text+0x...): relocation truncated to fit: R_ARM_CALL against `runtime.morestack_noctxt'
when using the bfd linker.
Fixes#59034.
Updates #58425.
Change-Id: I8a76986b38727df1b961654824c2af23f06b9fcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/475957
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If we increased the NOFILE rlimit when starting the program,
restore the original rlimit when forking a child process.
For #46279
Change-Id: Ia5d2af9ef435e5932965c15eec2e428d2130d230
Reviewed-on: https://go-review.googlesource.com/c/go/+/476097
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
In CL 393354 the os package was changed to raise the open file rlimit
at program start. That code is not inherently tied to the os package.
This CL moves it into the syscall package.
This is in preparation for future changes to restore the original
soft rlimit when exec'ing a new program.
For #46279
Change-Id: I981401b0345d017fd39fdd3dfbb58069be36c272
Reviewed-on: https://go-review.googlesource.com/c/go/+/476096
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In a container environment, creating a socket may be disallowed. Try to
detect these cases and skip the tests instead of failing them.
Fixes#58114
Change-Id: I681d19107e946d2508e2d1704956360f13c7335b
Reviewed-on: https://go-review.googlesource.com/c/go/+/476217
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
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>
