The findEmbed function looking for comment by readbyte,
however it might have constant or variables that contains
comment.
Maybe we should use ast parser in the future.
Fixes#43373
Change-Id: I92544384fc4c11363d8b2f6b9898c8dea1602767
Reviewed-on: https://go-review.googlesource.com/c/go/+/280332
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Change-Id: Ifcc565b34b3c3bb7ee62bb0525648a5d2895bf0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/282013
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
For #41127
Change-Id: I794a082299c6dce4202223197ece1864bed36810
Reviewed-on: https://go-review.googlesource.com/c/go/+/282555
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
io/fs is introduced in 2020, not 2009 nor 2010
Change-Id: I7d63aae17b1f8c3af1ded2f639e3fb76ff2aea81
Reviewed-on: https://go-review.googlesource.com/c/go/+/282232
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In particular bring in CL 201973, which reverts support for multiple
keys in a struct tag.
For #40281
For #43083
For #43226
Change-Id: I66e76639cbbca55bdbff6956acdb0a97650fdd31
Reviewed-on: https://go-review.googlesource.com/c/go/+/282412
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Proposal #40281 was initially accepted, but has now been declined.
This CL removes most of the work done to implement it.
Specifically this reverts CLs 248341, 274448, 274474, and 278392.
For #40281
For #43226
Change-Id: I5a9ebb4d9cb5fb0962434b64c59beb8343030be5
Reviewed-on: https://go-review.googlesource.com/c/go/+/281515
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
The documentation was copied from filepath.WalkFunc, and the copy was
not fully adjusted to the new circumstances.
Fixes#43536
Change-Id: I09687c7656e6938ebd9fc1e1643d34be88cf141d
Reviewed-on: https://go-review.googlesource.com/c/go/+/282172
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Marco Gazerro <gazerro@open2b.com>
golang.org/cl/251878 disallowed non-ASCII characters in import paths,
in module mode. They were already disallowed in module paths, so this
change just extended the restriction to the package subdirectory of
the module. Update the release notes to alert users of this change.
Fixes#43052
Change-Id: I1caf9ef978dd3ac599a3f82c5c376ad62e6fc436
Reviewed-on: https://go-review.googlesource.com/c/go/+/282194
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
For the example in #43551, before late call expansion, the OpArg type is
decomposed to int64. But the late call expansion is currently decompose
it to "x.Key" instead.
This CL make expand_calls decompose further for struct { 1-field type }
and array [1]elem.
This matches the previous rules for early decompose args:
(StructSelect (StructMake1 x)) => x
(ArraySelect (ArrayMake1 x)) => x
Fixes#43551
Change-Id: I2f1ebe18cb81cb967f494331c3d237535d2859e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/282332
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This change the struct fields for EmbedPatterns and EmbedFiles
to the Package struct listed in the go list documentation that
specifies the fields available to the go list template.
Fixes#43081
Change-Id: I89c325a9d6292a6ce484ee588b172d2f84e2333a
Reviewed-on: https://go-review.googlesource.com/c/go/+/282195
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The text/template functions are stored in a data structure shared by
all related templates, so do the same with the original, unwrapped,
functions on the html/template side.
For #39807Fixes#43295
Change-Id: I9f64a0a601f1151c863a2833b5be2baf649b6cef
Reviewed-on: https://go-review.googlesource.com/c/go/+/279492
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
In general, we don't want to encourage reading them from CSRs, and
applications that really want to can parse the Extensions field.
Note that this also fixes a bug where the error of
parseKeyUsageExtension was not handled in parseCertificateRequest.
Fixes#43477
Updates #37172
Change-Id: Ia5707b0e23cecc0aed57e419a1ca25e26eea6bbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/281235
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
We are trying to avoid by not automatically updating go.mod. The
suggestion should be that users actually add the dependencies they
need, and the command in an easily copy-pastable form now.
Fixes: #43430
Change-Id: I2227dab498fcd8d66184c94ebe9e776629ccadfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/280713
Run-TryBot: Baokun Lee <bk@golangcn.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
The panic message erroneously refers to float64 values.
Change-Id: I83380f41d6c28a72bc69a94b9bcdf9d42b1503c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/281236
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Fix a deadlock in DumpRequestOut which can occur if the request is
cancelled between response being sent and it being processed.
Also:
* Ensure we don't get a reader leak when an error is reported by the
transport before the body is consumed.
* Add leaked goroutine retries to avoid false test failures.
Fixes#38352
Change-Id: I83710791b2985b997f61fe5b49eadee0bb51bdee
Reviewed-on: https://go-review.googlesource.com/c/go/+/232798
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Damien Neil <dneil@google.com>
modload.Init now sets the default value for -mod if it wasn't set
explicitly. This happens before go.mod is loaded, so
modload.LoadModFile sets the default value again in order to enable
automatic vendoring.
Previously, cfg.BuildMod wasn't set at all if LoadModFile wasn't
called, as is the case for commands that run outside of a module
root. This problem only affected 'go install pkg@version' since other
commands are either forbidden in module mode or run with -mod=mod
(like 'go get' and 'go mod' subcommands).
This change also suppresses "missing sum" errors when -mod=readonly is
enabled and there is no module root.
Fixes#43278
Related #40278
Change-Id: I6071cc42bc5e24d0d7e84556e5bfd8e368e0019d
Reviewed-on: https://go-review.googlesource.com/c/go/+/279490
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
For #41191
Change-Id: I75d327759c3d9ef061c19a80b9b2619038dedf68
Reviewed-on: https://go-review.googlesource.com/c/go/+/281492
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In a gccgo installation the standard library sources are not available.
Change-Id: I929f3645e3ac95a1fa7047d6a3d243159a86ba66
Reviewed-on: https://go-review.googlesource.com/c/go/+/281493
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
tracebackothers is called from fatal throw/panic.
A fatal throw may be taken with allglock held (notably in the allocator
when allglock is held), which would cause a deadlock in tracebackothers
when we try to take allglock again. Locking allglock here is also often
a lock order violation w.r.t. the locks held when throw was called.
Avoid the deadlock and ordering issues by skipping locking altogether.
It is OK to miss concurrently created Gs (which are generally avoided by
freezetheworld(), and which were possible previously anyways if created
after the loop).
Fatal throw/panic freezetheworld(), which should freeze other threads
that may be racing to modify allgs. However, freezetheworld() does _not_
guarantee that it stops all other threads, so we can't simply drop the
lock.
Fixes#42669
Updates #43175
Change-Id: I657aec46ed35fd5d1b3f1ba25b500128ab26b088
Reviewed-on: https://go-review.googlesource.com/c/go/+/270861
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
What a year it has been. If there's one thing we can count on
at a time like this, it's that 2021 is the Year of the Gopher.
Change-Id: I4f6fbbe3d9b4b70df8fadd0d18237f05cd572265
Reviewed-on: https://go-review.googlesource.com/c/go/+/280163
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It isn't necessary on darwin/arm64 (macOS).
It was probably leftover from the old code when darwin/arm64
meant iOS. The test passes on iOS builder. Apparently this is
not needed either. Remove.
Change-Id: I6fa0c55d6086325d4b722862c4fe6c30bcd6e6e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/280158
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Changelog
'make rearguard_tarballs' no longer generates a bad rearguard.zi,
fixing a 2020e bug.
No actual changes to timezones data. See
http://mm.icann.org/pipermail/tz-announce/2020-December/000064.html
Updates #22487
Change-Id: I78f7adba1c3c1d3489b0da870601117b9b8cb0d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/280455
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The original Darwin/ARM port is gone. For ARM64, it works fine
without the flags on macOS/ARM64. Remove the flags.
Change-Id: I9cc00c49dd71376dd9c52abb78c2d8cec656b3db
Reviewed-on: https://go-review.googlesource.com/c/go/+/280157
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Somehow I missed that one. It works fine.
Change-Id: I0b1286bf1e6a8f40b9f3f114f49b3034079e0b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/280156
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A typo was made, which I noticed while looking through the recent master
commits.
Change-Id: Ieed5d6664a1f3ff5892d59abf194963b44ef0e55
Reviewed-on: https://go-review.googlesource.com/c/go/+/280454
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change-Id: Idf8e5d808c0996e0ca00979e7b8d7627f29cd10f
Reviewed-on: https://go-review.googlesource.com/c/go/+/280552
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Fixes#42655
Change-Id: I7d2b70098a4ba4dcb325fb0be076043789b86135
Reviewed-on: https://go-review.googlesource.com/c/go/+/280312
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Elias Naur <mail@eliasnaur.com>
When time.Parse sees a timezone name that matches the local timezone,
it uses the local timezone. The tests weren't expecting that,
so using MDT broke with TZ=America/Boise (where MDT means Mountain
Daylight Time). Just use GMT instead.
Fixes#43354
Change-Id: Ida70c8c867e2568b1535d1dfbf1fb0ed9e0e5c1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/280072
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Today, timeHistogram, when copied, has the wrong set of counts for the
bucket that should represent (-inf, 0), when in fact it contains [0, 1).
In essence, the buckets are all shifted over by one from where they're
supposed to be.
But this also means that the existence of the overflow bucket is wrong:
the top bucket is supposed to extend to infinity, and what we're really
missing is an underflow bucket to represent the range (-inf, 0).
We could just always zero this bucket and continue ignoring negative
durations, but that likely isn't prudent.
timeHistogram is intended to be used with differences in nanotime, but
depending on how a platform is implemented (or due to a bug in that
platform) it's possible to get a negative duration without having done
anything wrong. We should just be resilient to that and be able to
detect it.
So this change removes the overflow bucket and replaces it with an
underflow bucket, and timeHistogram no longer panics when faced with a
negative duration.
Fixes#43328.
Fixes#43329.
Change-Id: If336425d7d080fd37bf071e18746800e22d38108
Reviewed-on: https://go-review.googlesource.com/c/go/+/279468
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently these two metrics are reported incorrectly, going by the
documentation in the runtime/metrics package. We just copy in the
size-class-based values from the runtime wholesale, but those implicitly
have an inclusive upper-bound and exclusive lower-bound (e.g. 48-byte
size class contains objects in the size range (32, 48]) but the API
declares inclusive lower-bounds and exclusive upper-bounds.
Also, the bottom bucket representing (-inf, 1) should always be empty.
Extend the consistency check to verify this.
Updates #43329.
Change-Id: I11b5b062a34e13405ab662d15334bda91f779775
Reviewed-on: https://go-review.googlesource.com/c/go/+/279467
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
A comment in mgcmark.go indicates that we scan stacks a second time but
we don't, at least not since changing to the hybrid write barrier.
Change-Id: I9376adbb6d8b6dd9dc3cee62e077b5dfb8a3fdde
Reviewed-on: https://go-review.googlesource.com/c/go/+/279797
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Changelog:
Volgograd switches to Moscow time on 2020-12-27 at 02:00.
Small changes to past timestamps and abbreviations.
See
http://mm.icann.org/pipermail/tz-announce/2020-December/000063.html
Updates #22487
Change-Id: I709abe899ca498698463e945ccbcf4bc5fe60b92
Reviewed-on: https://go-review.googlesource.com/c/go/+/279794
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A fix for a trivial (yet still confusing for neophytes like me!) typo in
contribute.html.
Change-Id: Ic68673fb2a3855c2b9e8042047087450e8793e6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/279452
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
'go get pkg@vers' will now add an explicit requirement for the module
providing pkg if that version was already indirectly required.
'go get mod@vers' will do the same if mod is a module path but not a
package.
Requirements promoted this way will be marked "// indirect" because
'go get' doesn't know whether they're needed to build packages in the
main module. So users should prefer to run 'go get ./pkg' (where ./pkg
is a package in the main module) to promote requirements.
Fixes#43131
Change-Id: Ifbb65b71274b3cc752a7a593d6ddd875f7de23b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/278812
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The syscall.AllThreadsSyscall() fixup mechanism needs to cooperate
with signal handling to ensure a notetsleepg() thread can wake up
to run the mDoFixup() function.
Fixes#43149
Change-Id: I6651b25bc44a4de47d3fb71d0293d51aef8b79c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/277434
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Under linux+cgo, OS threads are launched via pthread_create().
This abstraction, under linux, requires we avoid blocking
signals 32,33 and 34 indefinitely because they are needed to
reliably execute POSIX-semantics threading in glibc and/or musl.
When blocking signals the go runtime generally re-enables them
quickly. However, when a thread exits (under cgo, this is
via a return from mstart()), we avoid a deadlock in C-code by
not blocking these three signals.
Fixes#42494
Change-Id: I02dfb2480a1f97d11679e0c4b132b51bddbe4c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/269799
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
By default (and with -mod=readonly), the go command imports an error
if a package provided by an implicitly required module is
imported by a package in the main module. This import requires an
update to go.mod: the module must be required explicitly.
The package loader now provides a hint that 'go get' should be run on
the importing package. This is preferred to 'go get' on the imported
package, since that would add an "// indirect" requirement.
For #43131
Change-Id: I0b353ce8ac8c4ddf1a9863544dfaf6c1964daf42
Reviewed-on: https://go-review.googlesource.com/c/go/+/279528
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>
The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.
However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.
So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.
We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.
Fixes#42866.
Fixes#43182.
Change-Id: I059450021405cdf2ef1c195ddbab3960764ad711
Reviewed-on: https://go-review.googlesource.com/c/go/+/268337
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
In issue11656.go, it tests that if the runtime can get a
reasonable traceback when it faults at a non-function PC. It does
it by jumping to an address that contains an illegal or trap
instruction. When it traps, the SIGTRAP crashes the runtime.
This CL changes it to use an instruction that triggers SIGSEGV.
This is due to two reasons:
- currently, the handling of bad PC is done by preparePanic,
which is only used for a panicking signal (SIGSEGV, SIGBUS,
SIGFPE), not a fatal signal (e.g. SIGTRAP).
- the test uses defer+recover to get a traceback, which only
works for panicking signals, not fatal signals.
Ideally, we should handle all kinds of faults (SIGSEGV, SIGBUS,
SIGILL, SIGTRAP, etc.) with a nice traceback. I'll leave this
for the future.
This CL also adds RISCV64 support.
Fixes#43283.
Change-Id: I5e0fbf8530cc89d16e05c3257d282bc1d4d03405
Reviewed-on: https://go-review.googlesource.com/c/go/+/279423
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go 1.15 pack's r command creates the output file if it does not
exist. The system "ar" command does this as well. Do the same.
For bazelbuild/rules_go#2762.
Change-Id: Icd88396b5c714b735c859a29ab29851e4301f4d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/279516
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The FreeBSD syscall convention uses the carry flag to indicate whether
an error has occured. The sys_umtx_op, thr_new, and pipe2 syscall
wrappers were failing to account for this convention and silently
suppressing errors as a result. This commit corrects these wrappers
by copying the pattern used by the other fallible syscall wrappers.
Note that futexsleep1 must now explicitly ignore the ETIMEDOUT error
from sys_umtx_op. Previously ETIMEDOUT was implicitly ignored because
sys_umtx_op never returned an error.
Fixes#43106.
Change-Id: I9c422b87cf4c6d308003bf42c3b419f785578b5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/276892
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Than McIntosh <thanm@google.com>
Treat the compiler's -linkobj output as "compiler object, which
means "pack c" will "see through" the file and add individual
entry to the new archive, instead of the object as a whole.
This is somewhat peculiar. But Go 1.15's cmd/pack does this,
although seemingly accidental. We just do the same. FWIW, it
does make things more consistent with/without -linkobj flag.
Fixes#43271.
Change-Id: I6b2d99256db7ebf0fa430f85afa7464e334f6bcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/279483
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
May fix#43302.
Change-Id: I6b7ddf94495c4fa80cf8a50a38eef5f8b2872669
Reviewed-on: https://go-review.googlesource.com/c/go/+/279481
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>