- 11 Jun, 2019 2 commits
-
-
Jonathan Amsterdam authored
Check the value of target after As returns true. Change-Id: I76a2b25fe825ee1dbb5f39f8f0b211c55bd25a4f Reviewed-on: https://go-review.googlesource.com/c/go/+/181299Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Andrew Bonventre authored
Change-Id: I34fd45ee252474c12f2e9c8d9b1a75b9eabb57f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/181549Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
- 10 Jun, 2019 10 commits
-
-
Dmitri Shuralyov authored
Change-Id: I8ae00d2392c20c627d58cf7e79015e982b971802 Reviewed-on: https://go-review.googlesource.com/c/go/+/181551Reviewed-by: Filippo Valsorda <filippo@golang.org>
-
Dmitri Shuralyov authored
Change-Id: I1c3e3305dfee4545a6caedd48243770ab3b28277 Reviewed-on: https://go-review.googlesource.com/c/go/+/181550Reviewed-by: Filippo Valsorda <filippo@golang.org>
-
Bryan C. Mills authored
$GOEXE exists and is documented in 'go env', so $exe is redundant and a bit confusing. Notably, mod_modinfo.txt already assumes that GOEXE is set (even though it isn't), and thus fails on Windows. After this CL, `go test cmd/go/...` passes on a windows-amd64-2016 builder. However, given that the $PATH on the builder is very minimal (#32430) and network access is limited, tests that rely on binaries (such as 'git') or external networking may still be broken. Updates #25300 Change-Id: I9d80f2a0fbaa8bc35fa2205b6898aeccecda4e94 Reviewed-on: https://go-review.googlesource.com/c/go/+/181542 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Andrew Bonventre authored
Change-Id: I684e3522e387b2d96d5cfb2878d2f77bf4558443 Reviewed-on: https://go-review.googlesource.com/c/go/+/181545Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
No references to this function remain; remove it to avoid confusion and reduce build overhead. The last reference was removed in CL 167748. Change-Id: I9d023c5d8904800edd3898fed79aa9f824dfb46a Reviewed-on: https://go-review.googlesource.com/c/go/+/181548Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
Keith Randall authored
64 bits is 8 bytes. Duh. Change-Id: I991b359df6241889bdef13152f551af9db6e14c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/181557 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
Bryan C. Mills authored
Add a helper-function to testenv to make these skips more ergonomic. Also update a few existing skips in cmd/go/... to use it. Updates #25300 Change-Id: I4205b4fb2b685dfac1cff3c999f954bff7b0f3c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/181538Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Keith Randall authored
This reverts CL 180761 Reason for revert: Reinstate the stack-allocated defer CL. There was nothing wrong with the CL proper, but stack allocation of defers exposed two other issues. Issue #32477: Fix has been submitted as CL 181258. Issue #32498: Possible fix is CL 181377 (not submitted yet). Change-Id: I32b3365d5026600069291b068bbba6cb15295eb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/181378Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
On freebsd 12, the system call for getdirentries writes 64 bits to *basep, even on 32-bit systems. Accomodate that by providing a uint64 to the system call and copy the base to/from that uint64. The uint64 seems to be a virtual file offset, so failing if the high bits are not zero should be fine for reasonable-sized directories. Fixes #32498 Change-Id: Ie22c0d301c6091bd20e813432928b24ab95cc314 Reviewed-on: https://go-review.googlesource.com/c/go/+/181377 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
Fixes #27698 Fixes #32227 Change-Id: I2416408b3de2f9f1ae1af2911cc327a65d2c0170 Reviewed-on: https://go-review.googlesource.com/c/go/+/181037Reviewed-by: Jay Conrod <jayconrod@google.com>
-
- 09 Jun, 2019 1 commit
-
-
Dmitri Shuralyov authored
This is a followup to CL 181278 and CL 181177. According to cmd/go/testdata/script/README: Each line is parsed into a sequence of space-separated command words, with environment variable expansion and # marking an end-of-line comment. Adding single quotes around text keeps spaces in that text from being treated as word separators and also disables environment variable expansion. We want $HOME to be expanded, so leave it out of the single-quoted block of text. I tested this change on macOS, and it makes TestScript/env_write pass. Fixes #32503 Change-Id: I13621aec82263e5cb6978c13a1ad71d2210a0e42 Reviewed-on: https://go-review.googlesource.com/c/go/+/181418 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 07 Jun, 2019 12 commits
-
-
Daniel Martí authored
I didn't realise that the trybots don't include any Mac machines, so I assumed this test change was fine when submitting CL 181177. In any case, this is a simple fix. I forgot to add the quotes, as the new UserConfigDir on Mac includes a space. Change-Id: I0766b966fc41736e9fc859e37f059a3f12788d7a Reviewed-on: https://go-review.googlesource.com/c/go/+/181278 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Martí authored
The old code used ~/Library/Preferences, which is documented by Apple as: This directory contains app-specific preference files. You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app. It looks like we missed everything after the first sentence; it's definitely not the right choice for files that Go programs and users should be touching directly. Instead, use ~/Library/Application Support, which is documented as: Use this directory to store all app data files except those associated with the user’s documents. For example, you might use this directory to store app-created data files, configuration files, templates, or other fixed or modifiable resources that are managed by the app. An app might use this directory to store a modifiable copy of resources contained initially in the app’s bundle. A game might use this directory to store new levels purchased by the user and downloaded from a server. This seems in line with what UserConfigDir is for, so use it. The documentation quotes above are obtained from the surprisingly long link below: https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html Fixes #32475. Change-Id: Ic27a6c92d76a5d7a4d4b8eac5cd8472f67a533a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/181177 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Keith Randall authored
The logic for detecting deferreturn calls is wrong. We used to look for a relocation whose symbol is runtime.deferreturn and has an offset of 0. But on some architectures, the relocation offset is not zero. These include arm (the offset is 0xebfffffe) and s390x (the offset is 6). This ends up setting the deferreturn offset at 0, so we end up using the entry point live map instead of the deferreturn live map in a frame which defers and then segfaults. Instead, use the IsDirectCall helper to find calls. Fixes #32477 Update #6980 Change-Id: Iecb530a7cf6eabd7233be7d0731ffa78873f3a54 Reviewed-on: https://go-review.googlesource.com/c/go/+/181258 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Brad Fitzpatrick authored
This is the net/http half of #32476. This supplies the method needed by the other half in x/net/http2 in the already-submitted CL 181259, which this CL also bundles in h2_bundle.go. Thanks to Tom Thorogood (@tmthrgd) for the bug report and test. Fixes #32476 Updates #30694 Change-Id: I79d2a280e486fbf75d116f6695fd3abb61278765 Reviewed-on: https://go-review.googlesource.com/c/go/+/181260 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
dist passes the -allabis flag to the compiler to avoid having to recreate the cross-package ABI logic from cmd/go. However, we removed that logic from cmd/go in CL 179863 and replaced it with a different mechanism that doesn't depend on the build system. Hence, passing -allabis in dist is no longer necessary. This CL removes -allabis from dist and, since that was the only use of it, removes support for it from the compiler as well. Updates #31230. Change-Id: Ib005db95755a7028f49c885785e72c3970aea4f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/181079 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Matt Layher authored
The documentation comment was duplicated for each of these methods, and the LazyProc.Call documentation incorrectly mentioned that Call accepts only 15 arguments, but it actually accepts 18 now. To prevent further documentation drift, refer the reader to the documentation for Proc.Call instead of duplicating it for LazyProc.Call. In addition, note that LazyProc's Addr, Call, and Find methods each trigger a procedure lookup. Change-Id: I6756cf7601fba79d1414ff5a5d6eef900aa590e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/181199 Run-TryBot: Matt Layher <mdlayher@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Constantin Konstantinidis authored
Checks if modules are enabled in GOPATH mode. Error message returned when no version is provided. Relevant tests updated. Test for GO111MODULE=off added. Fixes #27783 Change-Id: I12cdaced5fa38a9c49c0ecfed4c479eb86ed061f Reviewed-on: https://go-review.googlesource.com/c/go/+/179998 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Daniel Martí authored
In #32038, it was decided to remove get's -m, since one former use case is removed, and the other can be done via -d, as pointed by Russ. However, a user getting this short error might not realise that they can switch to -d to skip building packages. Add a short mention to point them in the right direction. It's important to note "packages", because -m was a flag that acted on modules, while -d acts on packages. Simply replacing -m with -d might not be enough in some cases because of that distinction. Change-Id: I0947b25c4223bdad3cd0e535848527da8db8a16d Reviewed-on: https://go-review.googlesource.com/c/go/+/179361Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Fixes #32335 Change-Id: I1cf8645ecc5ba0866d9b3589a18bb500ea17f865 Reviewed-on: https://go-review.googlesource.com/c/go/+/181018 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Daniel Martí authored
In particular, the returned template isn't independent from the parent. For example, it can't be parsed concurrently with other children templates. Only methods which are explicitly safe for concurrent use, like Execute, may be used concurrently. Fixes #30281. Change-Id: Idc84bf4199c035316cdb83b950fd4a8f2a71cd0c Reviewed-on: https://go-review.googlesource.com/c/go/+/172297 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
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 15 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>
-