This test is known to be broken on the darwin/arm64 builder.
Skip it while it's being investigated so it doesn't mask other failures.
For #46239.
Updates #43228.
Change-Id: I8fe57a0636bba84c3100337146dcb96cc264e524
Reviewed-on: https://go-review.googlesource.com/c/go/+/321349
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If a filepath.WalkFunc returns filepath.SkipDir when invoked on a
non-directory file, it skips the remaining files in the containing
directory.¹
CL 276272 accidentally added a code path that triggers this behavior
whenever filepath.Walk reaches a non-directory file that begins with
a dot, such as .gitattributes or .DS_Store, causing findGorootModules
to return early without finding any modules in GOROOT. Tests that use
it ceased to provide test coverage that the tree is tidy.
Add an explicit check for info.IsDir in the 5 places that intend to
use filepath.SkipDir to skip traversing that directory. Even paths
like GOROOT/bin and GOROOT/pkg which are unlikely to be anything but
a directory are worth checking, since the goal of moddeps is to take
a possibly problematic GOROOT tree as input and detect problems.
While the goal of findGorootModules is to find all modules in GOROOT
programmatically (in case new modules are added or modified), there
are 4 modules now that are quite likely to exist, so check for their
presence to avoid similar regressions. (It's not hard to update this
test if a well-known GOROOT module is removed or otherwise modified;
but if it becomes hard we can simplify it to check for a reasonable
number of modules instead.)
Also fix the minor skew that has crept in since the test got disabled.
¹ This wasn't necessarily an intentional design decision, but it was
found only when Go 1.4 was already out. See CL 11690 for details.
Fixes#46254.
Change-Id: Id55ed926f8c0094b1af923070de72bacca05996f
Reviewed-on: https://go-review.googlesource.com/c/go/+/320991
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
In cases where the socket operation has no underlying address,
golang.org/cl/291509 unintentionally changed ReadFromUDP from return a
nil *UDPAddr to a non-nil (but zero value) *UDPAddr.
This may break callers that assume "no address" is always addr == nil,
so change it back to remain nil.
Fixes#46238
Change-Id: I8531e8fa16b853ed7560088eabda0b9e3e53f5be
Reviewed-on: https://go-review.googlesource.com/c/go/+/320909
Trust: Michael Pratt <mpratt@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
issue46234.go expects an error output "segmentation violation",
which is UNIX-specific. Check for "nil pointer dereference"
instead, which is emitted by the Go runtime and should work on all
platforms.
Should fix Windows builders.
Change-Id: I3f5a66a687d43cae5eaf6a9e942b877e5a248900
Reviewed-on: https://go-review.googlesource.com/c/go/+/321072
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
"// +build" by itself was like "// +build !" - unsatisfiable.
Make it so again (right now it panics).
Fixes#44487.
Change-Id: Iacbc1398af6f988ef011f9f438e792eb62f8f434
Reviewed-on: https://go-review.googlesource.com/c/go/+/320829
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
When inlining functions with closures, ensure that we don't mark the
body of the closure with a src.Pos marker that reflects the inline,
since this will result in the generation of an inltree table for the
closure itself (as opposed to the routine that the func-with-closure
was inlined into).
Fixes#46234.
Change-Id: I348296de6504fc4745d99adab436640f50be299a
Reviewed-on: https://go-review.googlesource.com/c/go/+/320913
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
Apparently, in bash, the "continue" keyword can only be used
inside of a loop, not in an if block. If readelf exists but $CC
does not, make.bash emits a warning:
./make.bash: line 135: continue: only meaningful in a `for', `while', or `until' loop
Change it to a conditional.
Change-Id: I00a0940ed99bc0c565094e506705961b6b3d362e
Reviewed-on: https://go-review.googlesource.com/c/go/+/320170
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
People continue to be confused by how these work. Address that by some
rejiggering.
Introduce a constant called Layout that both defines the time and
provides a reference point for Parse and Format to refer to. We can
then delete much redundancy, especially for Format's comments, but
Parse tightens a bit too.
Then change the way the concept of the layout string is introduced,
and provide a clearer catalog of what its elements are.
Fixes#38871
Change-Id: Ib967ae70c7d5798a97b865cdda1fda4daed8a99a
Reviewed-on: https://go-review.googlesource.com/c/go/+/320252
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Fix an apparent typo for the right-hand bound in a couple panic
messages, where '[' was used instead of ']'.
Fixes#46215
Change-Id: Ie419c404ca72ed085a83a2c38ea1a5d6ed326cca
Reviewed-on: https://go-review.googlesource.com/c/go/+/320510
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
To pull in CL 318309.
For #41184
Change-Id: I99adb0478e71dbd72e13551a87ed09eae2a0ef2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/320312
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test previously had the hardcoded assumption that /proc/self/status
files had "Groups:" lines containing numerical IDs in ascending order.
Because of the possibility of non-monotonic ordering of GIDs in user
namespaces, this assumption was not universally true for all
/proc/self/gid_map setups.
To ensure this test can pass in those setups, sanity check failed
"Groups:" line matches with a string sorted version of the expected
values. (For the test cases here, numerical and string sorted order
are guaranteed to match.)
Fixes#46145
Change-Id: Ia060e80b123604bc394a15c02582fc406f944d36
Reviewed-on: https://go-review.googlesource.com/c/go/+/319591
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
If a user runs 'go get example.com/cmd' for a package in the main
module, it's more likely they intend to fill in missing dependencies
for that package (especially with -u). If the intent were only to
build and install, 'go install example.com/cmd' would be a better
choice.
For #43684
Resolving a comment on CL 305670.
Change-Id: I5c80ffdcdb3425b448f2f49cc20b07a18cb2bbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/318570
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Some uses of crosscall2 did not work on ppc64le and probably
aix-ppc64. In particular, if there was a main program compiled
with -buildmode=pie and used a plugin which invoked crosscall2,
then failures could occur due to R2 getting set incorrectly along the
way. The problem was due to R2 being saved on the caller's
stack; it is now saved on the crosscall2 stack. More details can be
found in the issue.
This adds a testcase where the main program is built with pie
and the plugin invokes crosscall2.
This also changes the save of the CR bits from MOVD to MOVW as
it should be.
Fixes#43228
Change-Id: Ib5673e25a2ec5ee46bf9a1ffb0cb1f3ef5449086
Reviewed-on: https://go-review.googlesource.com/c/go/+/319489
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Heschi Kreinick <heschi@google.com>
osyield is called in code paths that are not allowed to split
stack, e.g. casgstatus called from entersyscall/exitsyscall.
It is nosplit on all other platforms. Mark it nosplit on OpenBSD
as well.
Change-Id: I3fed5d7f58b3d50610beca6eed2c7e902b8ec52c
Reviewed-on: https://go-review.googlesource.com/c/go/+/319969
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
If the client request never makes it to the server, the outstanding
accept is never broken. Change the test to always close the listening
socket when the client request completes.
Updates #45358
Change-Id: I744a91dfa11704e7e528163d7669c394e90456dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/319275
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The Context.ImportDir method in the go/build package sets Package.Root
to $GOPATH, if a package is inside a GOPATH workspace. The
loadPackageData function keeps this value even when modules are enabled.
Override Package.Root when modules are enabled, instead of just set its
value when Context.ImportDir was unable to set it.
Add a regression test.
Fixes#46119
Change-Id: I900a33fe13a445cb771e2952d0d830f1b4a5921f
Reviewed-on: https://go-review.googlesource.com/c/go/+/319209
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently all script tests use the UNIX path separator with the cd
command, causing the PWD environment variable to have the incorrect path
separator on Windows.
Call filepath.FromSlash on the cd command argument.
Update the testdata/script/README to document that the cd argument must
use slashes.
Add a regression test.
To reproduce this issue, a test must use the cd command followed by a
stdout or stderr command containing the pattern $PWD.
Change-Id: Ib2dc5f185cc2476451402787996d14df91f7dddb
Reviewed-on: https://go-review.googlesource.com/c/go/+/319311
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
There was a space missing in the first line shown below, and an extra
space in the second line shown. Thanks Peter Bourgon for noting this.
BEFORE:
$ go help build | grep -A1 'has some limitations'
has some limitations:importantly, cgo files included from outside the
include path must be in the same directory as the Go package they are
AFTER:
$ go help build | grep -A1 'has some limitations'
has some limitations: importantly, cgo files included from outside the
include path must be in the same directory as the Go package they are
Note that I edited alldocs.go by hand here, as the mkalldocs.sh script
produces a lot more changes, for example adding the -insecure flag
documentation in. Not sure what's wrong there.
Change-Id: I303f6d6b42b0e24cec0748a949dc23beec64b917
Reviewed-on: https://go-review.googlesource.com/c/go/+/319949
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
According to the armv8-a reference manual, conditions AL and NV are not allowed
for instructions CINC, CINV, CNEG, CSET and CSETM. This CL adds this check and
the corresponding test cases.
Change-Id: Icb496b7b13a353f41491f2de4d939a5cd88abb04
Reviewed-on: https://go-review.googlesource.com/c/go/+/317912
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
In the deadcode path we mark runtime.unreachableMethod symbol,
which is a special symbol used for redirecting unreachable
methods. Currently this code is conditioned on not -linkshared.
This is wrong. It should be marked with -linkshared mode as well.
In fact, -linkshared should only affect the entry symbol. Change
the code accordingly.
Change-Id: I252abf850212a930f275589ef0035a43e52cb9cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/319893
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We redirect references to unreachable methods to
runtime.unreachableMethod. We choose to use ABIInternal symbol
for this, because runtime.unreachableMethod is a defined Go
function.
When linking against shared libraries, and ABI wrappers are not
enabled, the imported function symbols are all ABI0 and aliased
to ABIInternal. We need to resolve ABI alias in this case.
Change-Id: Idd64ef46ce0b5f54882ea0069ce0d59dc9b7a599
Reviewed-on: https://go-review.googlesource.com/c/go/+/319891
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
A .tbd file is a macOS text-based stub library and is a valid input to
the macOS linker. This change adds .tbd to the allow-list for acceptable
linker flags.
Fixesgolang/go#44263
Change-Id: Ie5439a13325dbc908e42f95ec70aca518bb549f9
GitHub-Last-Rev: 6055c3b5fa
GitHub-Pull-Request: golang/go#44276
Reviewed-on: https://go-review.googlesource.com/c/go/+/292269
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
It is unclear what the future holds for the go line in go.mod files.
Perhaps at some point we will switch to semver numbering.
Perhaps at some point we will allow specifying minor versions
or even betas and release candidates.
Those kinds of changes are difficult today because the go line
is parsed in dependency modules, meaning that older
versions of the Go toolchain need to understand newer go lines.
This CL makes that case - parsing a go line in a dependency's
go.mod file - a bit more lax about how to find the version.
It allows a leading v and any trailing non-digit-prefixed string
after the MAJOR.MINOR section.
There are no concrete plans to make use of any of these changes,
but if in the future we want to make them, having a few Go releases
under out belt that will accept the syntax in dependencies will
make any changes significantly easier.
Change-Id: I79bb84bba4b769048ac4b14d5c275eb9a3f270c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/317690
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In Perl mode, (|a)* should match an empty string at the start of the
input. Instead it matches as many a's as possible.
Because (|a)+ is handled correctly, matching only an empty string,
this leads to the paradox that e* can match more text than e+
(for e = (|a)) and that e+ is sometimes different from ee*.
This is a very old bug that ultimately derives from the picture I drew
for e* in https://swtch.com/~rsc/regexp/regexp1.html. The picture is
correct for longest-match (POSIX) regexps but subtly wrong for
preferred-match (Perl) regexps in the case where e has a preferred
empty match. Pointed out by Andrew Gallant in private mail.
The current code treats e* and e+ as the same structure, with
different entry points. In the case of e* the preference list ends up
not quite in the right order, in part because the “before e” and
“after e” states are the same state. Splitting them apart fixes the
preference list, and that can be done by compiling e* as if it were
(e+)?.
Like with any bug fix, there is a very low chance of breaking a
program that accidentally depends on the buggy behavior.
RE2, Go, and Rust all have this bug, and we've all agreed to fix it,
to keep the implementations in sync.
Fixes#46123.
Change-Id: I70e742e71e0a23b626593b16ddef3c1e73b413b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/318750
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The DWARF standard requires that the DIEs in a subprogram
corresponding to input and output parameters appear in declaration
order; this patch adds some new code in dwarfgen to enforce this
ordering (relying on the existing fn.Dcl ordering is not sufficient).
Prior to the register ABI, it was easy to keep vars/decls sorted
during DWARF generation since you could always rely on frame offset;
with the ABI sorting by frame offset no longer gives you the original
declaration order in all cases.
Fixes#46055.
Change-Id: I0e070cb781d6453caba896e5d3bee7cd5388050d
Reviewed-on: https://go-review.googlesource.com/c/go/+/318829
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A user encountered a debug/dwarf crash when running the dwarf2json
tool (https://github.com/volatilityfoundation/dwarf2json) on a
debug-built copy of the linux kernel. In this crash, the DWARF type
reader was trying to examine the contents of an array type while that
array type was still in the process of being constructed (due to
cycles in the type graph).
To avoid such situations, this patch extends the mechanism introduced
in https://go-review.googlesource.com/18459 (which handles typedef
types) to delay fixup of array types as well.
Change-Id: I303f6ce5db1ca4bd79da3581957dfc2bfc17cc01
Reviewed-on: https://go-review.googlesource.com/c/go/+/319329
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Yi Chou <yich@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
To pull in CL 318212.
For #41184
Change-Id: Iec0d7bee2d3a5874c24a55ec20efd7746bf70902
Reviewed-on: https://go-review.googlesource.com/c/go/+/319410
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Don't add them to files in vendor and cmd/vendor though. These will be
pulled in by updating the respective dependencies.
For #41184
Change-Id: Icc57458c9b3033c347124323f33084c85b224c70
Reviewed-on: https://go-review.googlesource.com/c/go/+/319389
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The table was not rendered correctly because one line missed a
column.
Change-Id: I1373e4e9fb8b8f2dcd9fd0db339083362cce9b71
Reviewed-on: https://go-review.googlesource.com/c/go/+/319291
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL add runtime.memmove inlining for AMD64 and ARM64.
According to ssa dump from testcases generic rules can't inline
memmomve properly due to one of the arguments is Phi operation. But this
Phi op will be optimized out by later optimization stages. As a result
memmove can be inlined during arch-specific rules.
The commit add new optimization rules to arch-specific rules that can
inline runtime.memmove if it possible during lowering stage.
Optimization fires 5 times in Go source-code using regabi.
Fixes#41662
Change-Id: Iaffaf4c482d068b5f0683d141863892202cc8824
Reviewed-on: https://go-review.googlesource.com/c/go/+/289151
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
As a follow up to an earlier change[1] to add ARMv8+LSE instructions in
the compiler generated atomic intrinsics, make the same change in the
runtime library. Since not all ARMv8 systems support LSE instructions,
they are protected by a feature-flag branch.
[1]: golang.org/cl/234217 commit: ecc3f5112e
Change-Id: I0e2fb22e78d5eddb6547863667a8865946679a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/310591
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
It is valid to see SPWRITE functions at the top of a GC stack traceback,
in the case where they self-preempted during the stack growth check
and haven't actually modified SP in a traceback-unfriendly manner yet.
The current check is therefore too aggressive.
isAsyncSafePoint is taking care of not async-preempting SPWRITE functions
because it doesn't async-preempt any assembly functions at all.
But perhaps it will in the future.
To keep a check that SPWRITE assembly functions are not async-preempted,
add one in preemptPark. Then relax the check in traceback to avoid
triggering on self-preempted SPWRITE functions.
The long and short of this is that the assembly we corrected in x/crypto
issue #44269 was incredibly dodgy but not technically incompatible with
the Go runtime. After this change, the original x/crypto assembly no longer
causes GC traceback crashes during "GOGC=1 go test -count=1000".
But we'll still leave the corrected assembly.
This also means that we don't need to worry about diagnosing SPWRITE
assembly functions that may exist in the wild. They will be skipped for
async preemption and no harm no foul.
Fixes#44269, which was open pending some kind of check for
bad SPWRITE functions in the wild. (No longer needed.)
Change-Id: I6000197b62812bbd2cd92da28eab422634cf75a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/317669
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
We already check mmap errors on some code paths, but we missed
one. Add error check there.
Change-Id: Ic0e9cb0eb03c805de40802cfc5d5500e3e065d99
Reviewed-on: https://go-review.googlesource.com/c/go/+/319290
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When linking a very large binary, the section address may not fit
in int32. Don't truncate it.
Change-Id: Ibcc8d74bf5662611949e547ce44ca8b973de383f
Reviewed-on: https://go-review.googlesource.com/c/go/+/319289
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The regression test introduced in https://golang.org/cl/318770 broke the
the nocgo builders.
Update the cgo package used in the test to ensure that it can be build
both with cgo enabled and disabled.
Change-Id: Iab0486f0b85ac5e5a22fdf8a1998edd50cbb4d96
Reviewed-on: https://go-review.googlesource.com/c/go/+/319210
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The documentation of the go list -find flag says that the Deps list will
be empty. However the current implementation adds implicit imports when
supporting Cgo or SWIG and when linking a main package.
Update the documentation of PackageOpts.IgnoreImport to clarify that
both explicit and implicit imports are ignored.
Add a regression test.
Fixes#46092
Change-Id: I37847528d84adb7a18eb6ff29e4af4b4318a66fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/318770
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
As a cleanup, golang.org/cl/307914 unintentionally caused the idle GC
work recheck to drop sched.lock between acquiring a P and committing to
keep it (once a worker G was found).
This is unsafe, as releasing a P requires extra checks once sched.lock
is taken (such as for runSafePointFn). Since checkIdleGCNoP does not
perform these extra checks, we can now race with other users.
In the case of #45975, we may hang with this sequence:
1. M1: checkIdleGCNoP takes sched.lock, gets P1, releases sched.lock.
2. M2: forEachP takes sched.lock, iterates over sched.pidle without
finding P1, releases sched.lock.
3. M1: checkIdleGCNoP puts P1 back in sched.pidle.
4. M2: forEachP waits forever for P1 to run the safePointFn.
Change back to the old behavior of releasing sched.lock only after we
are certain we will keep the P. Thus if we put it back its removal from
sched.pidle was never visible.
Fixes#45975
For #45916
For #45885
For #45884
Change-Id: I191a1800923b206ccaf96bdcdd0bfdad17b532e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/318569
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
openbsd/mips64 is now the only openbsd port that uses non-libc syscall - revise
build tags to reflect this.
Update #36435
Change-Id: I357b2dd2926d058e25e618fcca42c388587598a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/317919
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The current implementation uses UTF-aware functions
like strings.EqualFold and strings.ToLower.
This could, in some cases, cause http smuggling.
Change-Id: I0e76a993470a1e1b1b472f4b2859ea0a2b22ada0
Reviewed-on: https://go-review.googlesource.com/c/go/+/308009
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roberto Clapis <roberto@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This change alters the CurveParam methods to upgrade from the generic
curve implementation to the specific P224 or P256 implementations when
called on the embedded CurveParams. This removes the trap of using
elliptic.P224().Params() instead of elliptic.P224(), for example, which
results in using the generic implementation instead of the optimized
constant time one. For P224 this is done for all of the CurveParams
methods, except Params, as the optimized implementation covers all
these methods. For P256 this is only done for ScalarMult and
ScalarBaseMult, as despite having implementations of addition and
doubling they aren't exposed and instead the generic implementation is
used. For P256 an additional check that there actually is a specific
implementation is added, as unlike the P224 implementation the P256 one
is only available on certain platforms.
This change takes the simple, fast approach to checking this, it simply
compares pointers. This removes the most obvious class of mistakes
people make, but still allows edge cases where the embedded CurveParams
pointer has been dereferenced (as seen in the unit tests) or when someone
has manually constructed their own CurveParams that matches one of the
standard curves. A more complex approach could be taken to also address
these cases, but it would require directly comparing all of the
CurveParam fields which would, in the worst case, require comparing
against two standard CurveParam sets in the ScalarMult and
ScalarBaseMult paths, which are likely to be the hottest already.
Updates #34648
Change-Id: I82d752f979260394632905c15ffe4f65f4ffa376
Reviewed-on: https://go-review.googlesource.com/c/go/+/233939
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Recently some tsan tests were enabled on ppc64le which had not
been enabled before. This resulted in failures on systems with
tsan available, and while debugging it was determined that
there were other issues related to the use of signals with cgo.
Signals were not being forwarded within programs linked against
libtsan because the nocgo sigaction was being called for ppc64le
with or without cgo. Adding callCgoSigaction and calling that
allows signals to be registered so that signal forwarding works.
For linux-ppc64 and aix-ppc64, this won't change. On linux-ppc64
there is no cgo. I can't test aix-ppc64 so those owners can enable
it if they want.
In reviewing comments about sigtramp in sys_linux_arm64 it was
noted that a previous issue in arm64 due to missing callee save
registers could also be a problem on ppc64x, so code was added
to save and restore those.
Also, the use of R31 as a temp register in some cases caused an
issue since it is a nonvolatile register in C and was being clobbered
in cases where the C code expected it to be valid. The code sequences to
load these addresses were changed to avoid the use of R31 when loading
such an address.
To get around a vet error, the stubs_ppc64x.go file in runtime
was split into stubs_ppc64.go and stubs_ppc64le.go.
Updates #45040
Change-Id: Ia4ecff950613cbe1b89471790b1d3819d5b5cfb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/306369
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
