- 07 Jun, 2019 2 commits
-
-
Ian Lance Taylor authored
This recognizes new features that the gofrontend has started emitting in the export data to support cross-package inlinable functions. This is a port of CL 180677 and 180758 from the gofrontend repo. Change-Id: I48af6e71f9d8b04ba874ea0c204d39d1d461f8ad Reviewed-on: https://go-review.googlesource.com/c/go/+/181118 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
-
Daniel Martí authored
To pick up the structtag vet fix for 1.13. Fixes #30846. Change-Id: I5e011a7db1ffb9435793d533097d768f209c18e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/179999 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
- 06 Jun, 2019 18 commits
-
-
Austin Clements authored
CL 179862 introduced go:linkname directives to create ABI wrappers for Store and Store64 on s390x, but a concurrent change (CL 180439) replaced the Go definitions of these functions with assembly definitions. This resulted in conflicting definitions for the ABI0 symbols, which led to a bootstrap linking failure. Fix this by removing the now-incorrect go:linkname directives for Store and Store64. This should fix the linux-s390x builders. Updates #31230. Change-Id: I8de8c03c23412fc217d428c0018cc56eb2f9996f Reviewed-on: https://go-review.googlesource.com/c/go/+/181078Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Austin Clements authored
Somehow I missed these two functions in CL 179863. This should fix the linux-arm builders. Updates #31230. Change-Id: I3f8bef3fac331b505a55c0850b0fbc799b7c06c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/181077 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
The built-in Go resolver works significantly better. In particular, the use of res_search does not support CNAME or PTR queries and may not even be thread-safe. This CL is essentially a revert of CL 166297 plus fixes, including CL 180842. See CL 180842 for additional notes about problems with this approach. Fixes #31705. Change-Id: I0a30a0de2fbd04f6c461520fd34378c84aadf66c Reviewed-on: https://go-review.googlesource.com/c/go/+/180843 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Russ Cox authored
This code was added in April in CL 166297, for #12524. This CL fixes the following problems in the code: - The test for failure in the assembly stubs checked for 64-bit -1 instead of 32-bit -1 to decide to fetch errno. - These C routines (res_init and res_search) don't set errno anyway, so the Go code using errno to decide success is incorrect. (The routines set h_errno, which is a racy global variable that can't safely be consulted, storing values in a different error space.) - The Go call passed res_search a non-NUL-terminated name. - The C res_search rejects calls asking for TypeALL as opposed to more specific answers like TypeA/TypeAAAA/TypeCNAME, breaking cgoLookupHost in all cases and cgoLookupIP except with IP-version-specific networks. - The DNS response packet was parsed twice, once with msg.Unpack (discarded), and once with the lower-level dnsmessage.Parser. The Parser loop was missing a call to p.SkipAllQuestions, with the result that no DNS response packet would ever parse successfully. - The parsing of the DNS response answers, if reached, behaved as if that the AResource and AAAAResource record contained textual IP addresses, while in fact they contain binary ones. The calls to parseIPv4 and parseIPv6 therefore would always returns nil, so that no useful result would be returned from the resolver. With these fixes, cgoLookupIP can correctly resolve google.com and return both the A and AAAA addresses. Even after fixing all these things, TestGoLookupIP still fails, because it is testing that in non-cgo builds the cgo stubs correctly report "I can't handle the lookup", and as written the code intentionally violates that expectation. This CL adds new direct tests of the pseudo-cgo routines. The direct IP address lookups succeed, but the CNAME query causes res_search to hang, and the PTR query fails unconditionally (a trivial C program confirms these behaviors are due to res_search itself). Traditionally, res_search is only intended for single-threaded use. It is unclear whether this one is safe for use from multiple goroutines. If you run net.test under lldb, that causes syslog messages to be printed to standard error suggesting double-free bugs: 2019-06-05 19:52:43.505246-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD 2019-06-05 19:52:43.505274-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD 2019-06-05 19:52:43.505303-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD 2019-06-05 19:52:43.505329-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD This res_search is from libsystem_info; a normal C program would get res_search (#defined to res_9_search) from libresolv instead. It is unclear what the relation between the two is. Issue #12524 was about supporting the /etc/resolver directory tree, but only libresolv contains code for that; libsystem_info does not. So this code probably does not enable use of /etc/resolver. In short: - Before this CL, the code clearly had never run successfully. - The code appears not to improve upon the usual non-cgo fallback. - The code carries with it no tests of improved behavior. - The code breaks existing tests. - Calling res_search does not work for PTR/CNAME queries, so the code breaks existing behavior, even after this CL. - It's unclear whether res_search is safe to call from multiple threads. - It's unclear whether res_search is used by any other macOS programs. Given this, it probably makes sense to delete this code rather than rejigger the test. This CL fixes the code first, so that there is a working copy to bring back later if we find out that it really is necessary. For #31705. Change-Id: Id2e11e8ade43098b0f90dd4d16a62ca86a7a244a Reviewed-on: https://go-review.googlesource.com/c/go/+/180842 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Russ Cox authored
It matters whether we are calling a function that would return a 32-bit or 64-bit -1 on error. A few sites were wrong and this key detail was omitted from syscall/syscallX docs. Change-Id: I48a421b6cc4d2d2b5e58f790cc947e3cb2f98940 Reviewed-on: https://go-review.googlesource.com/c/go/+/180841 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Austin Clements authored
This removes the special case for finding assembly references to Go symbols in runtime and runtime/internal/atomic. These are no longer necessary because we've now marked all symbols in these packages that must be accessible from assembly in other packages. Fixes #31230. Change-Id: I70c90b70e13b922a6669f3d46c53347f98d6fc3f Reviewed-on: https://go-review.googlesource.com/c/go/+/179863 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Austin Clements authored
This marks all Go symbols called from assembly in other packages with "go:linkname" directives to ensure they get ABI wrappers. Now that we have this go:linkname convention, this also removes the abi0Syms definition in the runtime, which was used to give morestackc an ABI0 wrapper. Instead, we now just mark morestackc with a go:linkname directive. This was tested with buildall.bash in the default configuration, with -race, and with -gcflags=all=-d=ssa/intrinsics/off. Since I couldn't test cgo on non-Linux configurations, I manually grepped for runtime symbols in runtime/cgo. Updates #31230. Change-Id: I6c8aa56be2ca6802dfa2bf159e49c411b9071bf1 Reviewed-on: https://go-review.googlesource.com/c/go/+/179862 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
-
Austin Clements authored
The //go:linkname directive can be used to make a symbol accessible to another package (when it wouldn't normally be). Sometimes you want to do this without actually changing the symbol's object file symbol name; for example, in gccgo this makes unexported symbols non-static, and in gc this provides ABI0 wrappers for Go symbols so they can be called from assembly in other packages. Currently, this results in stutter like //go:linkname entersyscall runtime.entersyscall This CL makes the second argument to go:linkname optional for the case where the intent is simply to expose the symbol rather than to rename it in the object file. Updates #31230. Change-Id: Id06d9c4b2ec3d8e27f9b8a0d65212ab8048d734f Reviewed-on: https://go-review.googlesource.com/c/go/+/179861 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Austin Clements authored
Calling a Go symbol from assembly in another package currently results in a link failure because the Go symbol is defined as ABIInternal, but the assembly call is from ABI0. In general this is okay because you shouldn't do this anyway, but there are special cases where this is necessary, especially between the runtime and packages closely tied to the runtime in std. Currently, we address this for runtime symbols with a hack in cmd/go that knows to scan related packages when building the symabis file for the runtime and runtime/internal/atomic. However, in addition to being a messy solution in the first place, this hack causes races in cmd/go that are difficult to work around. We considered creating dummy references from assembly in the runtime to these symbols, just to make sure they get ABI0 wrappers. However, there are a fairly large number of these symbols on some platforms, and it can vary significantly depending on build flags (e.g., race mode), so even this solution is fairly unpalatable. This CL addresses this by providing a way to mark symbols in Go code that should be made available to assembly in other packages. Rather than introduce a new pragma, we lightly expand the meaning of "//go:linkname", since that pragma already generally indicates that you're making the symbol available in a way it wasn't before. This also dovetails nicely with the behavior of go:linkname in gccgo, which makes unexported symbols available to other packages. Follow-up CLs will make use of this and then remove the hack from cmd/go. Updates #31230. Change-Id: I23060c97280626581f025c5c01fb8d24bb4c5159 Reviewed-on: https://go-review.googlesource.com/c/go/+/179860 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Michael Munday authored
The z/Architecture does not guarantee that a load following a store will not be reordered with that store, unless they access the same address. Therefore if we want to ensure the sequential consistency of atomic loads and stores we need to perform serialization operations after atomic stores. We do not need to serialize in the runtime when using StoreRel[ease] and LoadAcq[uire]. The z/Architecture already provides sufficient ordering guarantees for these operations. name old time/op new time/op delta AtomicLoad64-16 0.51ns ± 0% 0.51ns ± 0% ~ (all equal) AtomicStore64-16 0.51ns ± 0% 0.60ns ± 9% +16.47% (p=0.000 n=17+20) AtomicLoad-16 0.51ns ± 0% 0.51ns ± 0% ~ (all equal) AtomicStore-16 0.51ns ± 0% 0.60ns ± 9% +16.50% (p=0.000 n=18+20) Fixes #32428. Change-Id: I88d19a4010c46070e4fff4b41587efe4c628d4d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/180439 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
David Chase authored
Tool refactoring smallStacks into smallFrames helpfully "corrected" the capitalization in a string, this undoes the help. This is necessary to ensure correct (re)building when the flag is used to research stack-marking GC latency bugs. Updates #27732. Change-Id: Ib7c8d4a36c9e4f9612559be68bd481f9d9cc69f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/180958 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Meng Zhuo authored
This is a follow up CL of CL 180877: It will skip test create user namespaces under 3 conditions: 1. sysctl file is missing 2. file reads nothing 3. user don't have permission to create namespaces Change-Id: I25f00a6b67213bf98d654972388637789978e1fe Reviewed-on: https://go-review.googlesource.com/c/go/+/180937 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
David Chase authored
Shrinks the size of things that can be stack allocated from 10M to 128k for declared variables and from 64k to 16k for implicit allocations (new(T), &T{}, etc). Usage: "go build -gcflags -smallframes hello.go" An earlier GOEXPERIMENT version of this caused only one problem, when a gc-should-detect-oversize-stack test no longer had an oversized stack to detect. The change was converted to a flag to make it easier to access (for diagnosing "long" GC-related single-thread pauses) and to remove interference with the test. Includes test to verify behavior. Updates #27732. Change-Id: I1255d484331e77185e07c78389a8b594041204c2 Reviewed-on: https://go-review.googlesource.com/c/go/+/180817 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Meng Zhuo authored
The original test (CL 166460) didn't check the existence of /proc/sys/kernel/unprivileged_userns_clone and continue the test if the file doesn't exist. Fixes #32459 Change-Id: Iab4938252fcaded32b61e17edf68f966c2565582 Reviewed-on: https://go-review.googlesource.com/c/go/+/180877 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
Russ Cox authored
Change-Id: Ie00494f098bd2bce9bfd1b18dbf9543cf46faad6 Reviewed-on: https://go-review.googlesource.com/c/go/+/180840 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Change-Id: I6940a4c747f2da871263afa6a4e3386395d5cf54 Reviewed-on: https://go-review.googlesource.com/c/go/+/180839 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
If the test fails, conf.teardown wouldn't be. It doesn't look like it matters much, but clean up anyway. Change-Id: I45c18095abfd49422975d061be20cbd971a98f8f Reviewed-on: https://go-review.googlesource.com/c/go/+/180780 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
At least one libc call we make (res_search, which calls _mdns_query and then mdns_item_call) pushes a 64 kB stack frame onto the stack. Then it faults on the guard page. Use the default system stack size, under the assumption that the C code being called is compatible with that stack size. For #31705. Change-Id: I1b0bfc2e54043c49f0709255988ef920ce30ee82 Reviewed-on: https://go-review.googlesource.com/c/go/+/180779 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 05 Jun, 2019 10 commits
-
-
ng0 authored
Fixes #32167 Change-Id: If1277789ac96363430045e73e49d008bdae9be79 GitHub-Last-Rev: 71c9435c8417b19faaf66dc2e08740d7a9c22e3b GitHub-Pull-Request: golang/go#32171 Reviewed-on: https://go-review.googlesource.com/c/go/+/178397 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Alex Myasoedov authored
Fixes #32427 Change-Id: I4b863bd3836067dcc2eb3a9c3a7169656763d003 Reviewed-on: https://go-review.googlesource.com/c/go/+/180438Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Keith Randall authored
This reverts commit fff4f599. Reason for revert: Seems to still have issues around GC. Fixes #32452 Change-Id: Ibe7af629f9ad6a3d5312acd7b066123f484da7f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/180761 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Austin Clements authored
Change-Id: Ibe514058770bd5342e1f344c5b8a9ab1427d5dfe Reviewed-on: https://go-review.googlesource.com/c/go/+/180297 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
It was rolled back. Change-Id: I8372bb7e11bab7be242f4af7093a73d2fa093067 Reviewed-on: https://go-review.googlesource.com/c/go/+/180760Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Andrew Bonventre authored
The additions were generated using golang.org/x/build/cmd/relnote. Change-Id: Ie7322f7d01a2dd4a7bca89b9ef9c1ce93bc2671a Reviewed-on: https://go-review.googlesource.com/c/go/+/180778Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
Windows does not have atomic renames; instead, it produces one of a handful of errors in case a read races with a rename. CL 180219 added a utility function that retries those errors in most cases; this change updates the locations that use renameio for writes to also use the new renameio.ReadFile function for reads. It remains possible for a renameio.ReadFile to fail with a spurious ERROR_FILE_NOT_FOUND, but with retries in place for the other errors (and practical limits on write concurrency) such failures are unlikely in practice. Fixes #32188 Change-Id: I78c81051cc871325c1e3229e696b921b0fcd865a Reviewed-on: https://go-review.googlesource.com/c/go/+/180517 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
ReadFile is a drop-in replacement for ioutil.ReadFile that works around Windows filesystem flakiness under load. A followup CL will replace uses of ioutil.ReadFile in cmd/go with this function. Updates #32188 Change-Id: I232ba893b132bdc84cd7b0edde436165a69e1aa8 Reviewed-on: https://go-review.googlesource.com/c/go/+/180219 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Ian Lance Taylor authored
Updates #31093 Change-Id: I7962aaca0b012de01768b7b42dc2283d5845eeea Reviewed-on: https://go-review.googlesource.com/c/go/+/180377 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Ian Lance Taylor authored
Roll back CL 159258 and CL 168337. Those changes broke existing code. I can't see any way to keep existing code working while also producing good error messages for types like C.ulong (such as the ones already tested for in misc/cgo/errors). This is not an exact roll back because parts of the code have changed since those CLs. Updates #29878 Fixes #31093 Change-Id: I56fe76c167ff0ab381ed273b9ca4b952402e1434 Reviewed-on: https://go-review.googlesource.com/c/go/+/180357 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
- 04 Jun, 2019 4 commits
-
-
Dmitri Shuralyov authored
Roll back CL 161738. That fix changed StripPrefix behavior in the general case, not just in the situation where where stripping the prefix from path resulted in the empty string, causing issue #31622. That kind of change to StripPrefix behavior is not backwards compatible, and there can be a smaller, more targeted fix for the original issue. Fixes #31622 Updates #30165 Change-Id: Ie2fcfe6787a32e44f71d564d8f9c9d580fc6f704 Reviewed-on: https://go-review.googlesource.com/c/go/+/180498 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Tyler Bui-Palsulich authored
GOSUMDB and GONOSUMDB are described in detail by 'go help module-auth'. So, this change mentions the two variables and says to see 'go help module-auth'. This also adds GONOPROXY to 'go help environment'. Fixes #32292 and updates #32056. Change-Id: I2eae0f906a3fbfcb88ad5c8fb4870917d0d7bbcd Reviewed-on: https://go-review.googlesource.com/c/go/+/179219Reviewed-by: Russ Cox <rsc@golang.org>
-
Keith Randall authored
When a defer is executed at most once in a function body, we can allocate the defer record for it on the stack instead of on the heap. This should make defers like this (which are very common) faster. This optimization applies to 363 out of the 370 static defer sites in the cmd/go binary. name old time/op new time/op delta Defer-4 52.2ns ± 5% 36.2ns ± 3% -30.70% (p=0.000 n=10+10) Fixes #6980 Update #14939 Change-Id: I697109dd7aeef9e97a9eeba2ef65ff53d3ee1004 Reviewed-on: https://go-review.googlesource.com/c/go/+/171758 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Agniva De Sarker authored
Some <h3>s were missing ids due to which the anchor links weren't getting generated. Fixes #32415 Change-Id: Ica21425c1a7c49735231c1de96b6c77dd594ce64 Reviewed-on: https://go-review.googlesource.com/c/go/+/180397Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 03 Jun, 2019 6 commits
-
-
Andrew Gerrand authored
The example in example_test.go requires that the whole file be displayed; the addition of ExampleAs meant that only the body of the package example function was shown, rather than the surrounding context. This change moves ExampleAs to the file wrap_test.go file, restoring the package example to its former glory. Update #31716 Change-Id: Id0ea77bc06023b239a63c1d6a7c8b3c1dae91ce9 Reviewed-on: https://go-review.googlesource.com/c/go/+/179737Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: Jean de Klerk <deklerk@google.com> Run-TryBot: Benny Siegert <bsiegert@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
LE Manh Cuong authored
Fixes #32386 Change-Id: I29ad4113b02264336eebe7865895f07ef386f450 Reviewed-on: https://go-review.googlesource.com/c/go/+/180177 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ben Shi authored
ARM64's R19-R29 and F8-F15 are callee saved registers, which should be saved in the beginning of sigtramp, and restored at the end. fixes #31827 Change-Id: I622e03f1a13fec969d3a11b6a303a8a492e02bcd Reviewed-on: https://go-review.googlesource.com/c/go/+/177045 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Keith Randall authored
Normally, reflect.makeFuncStub records the context value at a known point in the stack frame, so that the runtime can get the argument map for reflect.makeFuncStub from that known location. This doesn't work for defers or goroutines that haven't started yet, because they haven't allocated a frame or run an instruction yet. The argument map must be extracted from the context value. We already do this for defers (the non-nil ctxt arg to getArgInfo), we just need to do it for unstarted goroutines as well. When we traceback a goroutine, remember the context value from g.sched. Use it for the first frame we find. (We never need it for deeper frames, because we normally don't stop at the start of reflect.makeFuncStub, as it is nosplit. With this CL we could allow makeFuncStub to no longer be nosplit.) Fixes #25897 Change-Id: I427abf332a741a80728cdc0b8412aa8f37e7c418 Reviewed-on: https://go-review.googlesource.com/c/go/+/180258Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Bryan C. Mills authored
Fixes #31857 Change-Id: Ic4afe1262d863112db97794edc1ade20f6926d64 Reviewed-on: https://go-review.googlesource.com/c/go/+/180197Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Andrew Gerrand authored
When adding coverage counters to a block, the block's statement list is mutated. CL 77150 removed the part where the mutated list is assigned back to its parent node; this was confusing ast.Walk, which would then lose its place and stop walking the current block, dropping counters in the process. This change has addCounters make a copy of the list before mutating it, so that the original list doesn't change under Walk's feet. Fix #32200 Change-Id: Ia3b67d8cee860ceb7caf8748cb7a80ff9c6276e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/179581Reviewed-by: Rob Pike <r@golang.org>
-