summaryrefslogtreecommitdiff
path: root/src/cmd/internal/objabi
Commit message (Collapse)AuthorAgeFilesLines
* runtime, cmd: rationalize StackLimit and StackGuardAustin Clements2023-04-211-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current definitions of StackLimit and StackGuard only indirectly specify the NOSPLIT stack limit and duplicate a literal constant (928). Currently, they define the stack guard delta, and from there compute the NOSPLIT limit. Rationalize these by defining a new constant, abi.StackNosplitBase, which consolidates and directly specifies the NOSPLIT stack limit (in the default case). From this we then compute the stack guard delta, inverting the relationship between these two constants. While we're here, we rename StackLimit to StackNosplit to make it clearer what's being limited. This change does not affect the values of these constants in the default configuration. It does slightly change how StackGuardMultiplier values other than 1 affect the constants, but this multiplier is a pretty rough heuristic anyway. before after stackNosplit 800 800 _StackGuard 928 928 stackNosplit -race 1728 1600 _StackGuard -race 1856 1728 For #59670. Change-Id: Ia94094c5e47897e7c088d24b4a5e33f5c2768db5 Reviewed-on: https://go-review.googlesource.com/c/go/+/486976 Auto-Submit: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* internal/abi, runtime, cmd: merge StackSmall, StackBig consts into internal/abiAustin Clements2023-04-211-4/+5
| | | | | | | | | | | For #59670. Change-Id: I91448363be2fc678964ce119d85cd5fae34a14da Reviewed-on: https://go-review.googlesource.com/c/go/+/486975 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Auto-Submit: Austin Clements <austin@google.com>
* internal/abi, runtime, cmd: merge PCDATA_* and FUNCDATA_* consts into ↵Austin Clements2023-04-211-51/+0
| | | | | | | | | | | | | | | | | | internal/abi We also rename the constants related to unsafe-points: currently, they follow the same naming scheme as the PCDATA table indexes, but are not PCDATA table indexes. For #59670. Change-Id: I06529fecfae535be5fe7d9ac56c886b9106c74fd Reviewed-on: https://go-review.googlesource.com/c/go/+/485497 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* internal/abi, runtime, cmd: merge funcFlag_* consts into internal/abiAustin Clements2023-04-211-10/+0
| | | | | | | | | | | For #59670. Change-Id: Ie784ba4dd2701e4f455e1abde4a6bfebee4b1387 Reviewed-on: https://go-review.googlesource.com/c/go/+/485496 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Auto-Submit: Austin Clements <austin@google.com>
* internal/abi, runtime, cmd: merge funcID_* consts into internal/abiAustin Clements2023-04-211-60/+31
| | | | | | | | | | | For #59670. Change-Id: I517e97ea74cf232e5cfbb77b127fa8804f74d84b Reviewed-on: https://go-review.googlesource.com/c/go/+/485495 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
* Revert "internal/abi, runtime, cmd: merge StackSmall, StackBig consts into ↵Austin Clements2023-04-201-5/+4
| | | | | | | | | | | | | internal/abi" This reverts commit CL 486379. Submitted out of order and breaks bootstrap. Change-Id: Ie20a61cc56efc79a365841293ca4e7352b02d86b Reviewed-on: https://go-review.googlesource.com/c/go/+/486917 TryBot-Bypass: Austin Clements <austin@google.com> Reviewed-by: David Chase <drchase@google.com>
* Revert "runtime, cmd: rationalize StackLimit and StackGuard"Austin Clements2023-04-201-3/+12
| | | | | | | | | | | This reverts commit CL 486380. Submitted out of order and breaks bootstrap. Change-Id: I67bd225094b5c9713b97f70feba04d2c99b7da76 Reviewed-on: https://go-review.googlesource.com/c/go/+/486916 Reviewed-by: David Chase <drchase@google.com> TryBot-Bypass: Austin Clements <austin@google.com>
* runtime, cmd: rationalize StackLimit and StackGuardAustin Clements2023-04-201-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current definitions of StackLimit and StackGuard only indirectly specify the NOSPLIT stack limit and duplicate a literal constant (928). Currently, they define the stack guard delta, and from there compute the NOSPLIT limit. Rationalize these by defining a new constant, abi.StackNosplitBase, which consolidates and directly specifies the NOSPLIT stack limit (in the default case). From this we then compute the stack guard delta, inverting the relationship between these two constants. While we're here, we rename StackLimit to StackNosplit to make it clearer what's being limited. This change does not affect the values of these constants in the default configuration. It does slightly change how StackGuardMultiplier values other than 1 affect the constants, but this multiplier is a pretty rough heuristic anyway. before after stackNosplit 800 800 _StackGuard 928 928 stackNosplit -race 1728 1600 _StackGuard -race 1856 1728 For #59670. Change-Id: Ibe20825ebe0076bbd7b0b7501177b16c9dbcb79e Reviewed-on: https://go-review.googlesource.com/c/go/+/486380 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* internal/abi, runtime, cmd: merge StackSmall, StackBig consts into internal/abiAustin Clements2023-04-201-4/+5
| | | | | | | | | | For #59670. Change-Id: I04a17079b351b9b4999ca252825373c17afb8a88 Reviewed-on: https://go-review.googlesource.com/c/go/+/486379 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
* cmd/link: establish dependable package initialization orderKeith Randall2023-04-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This is a retry of CL 462035 which was reverted at 474976. The only change from that CL is the aix fix SRODATA->SNOPTRDATA at inittask.go:141) As described here: https://github.com/golang/go/issues/31636#issuecomment-493271830 "Find the lexically earliest package that is not initialized yet, but has had all its dependencies initialized, initialize that package, and repeat." Simplify the runtime a bit, by just computing the ordering required in the linker and giving a list to the runtime. Update #31636 Fixes #57411 RELNOTE=yes Change-Id: I28c09451d6aa677d7394c179d23c2c02c503fc56 Reviewed-on: https://go-review.googlesource.com/c/go/+/478916 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/internal/obj/loong64, cmd/internal/objabi, cmd/link: add support for ↵limeidan2023-04-112-9/+16
| | | | | | | | | | | | | | | | | --buildmode=c-shared on loong64 Updates #53301 Updates #58784 Change-Id: Ifcb40871f609531dfd8b568db9ac14da9b451742 Reviewed-on: https://go-review.googlesource.com/c/go/+/425476 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: WANG Xuerui <git@xen0n.name>
* cmd/internal/obj: generate SEH aux symbols for windows/amd64qmuntal2023-04-052-2/+4
| | | | | | | | | | | | | | | | | | | | This CL updates the Go compiler so it generate SEH unwind info [1] as a function auxiliary symbol when building for windows/amd64. A follow up CL will teach the Go linker how to assemble these codes into the PE .xdata section. Updates #57302 [1] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-unwind_info Change-Id: I40ae0437bfee326c1a67c2b5e1496f0bf3ecea17 Reviewed-on: https://go-review.googlesource.com/c/go/+/461749 Reviewed-by: Davis Goodin <dagood@microsoft.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
* all: add wasip1 definitionsJohan Brandhorst-Satzkorn2023-03-301-0/+5
| | | | | | | | | | | | | | | | | Add wasip1 GOOS definitions to the compiler and build definitions. Co-authored-by: Richard Musiol <neelance@gmail.com> Co-authored-by: Achille Roussel <achille.roussel@gmail.com> Co-authored-by: Julien Fabre <ju.pryz@gmail.com> Co-authored-by: Evan Phoenix <evan@phx.io> Change-Id: I087e7ff4205a34187bbca18b1693ad911ddd1219 Reviewed-on: https://go-review.googlesource.com/c/go/+/479616 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
* cmd/link,cmd/internal/objabi: support ADDR32NB relocations on windowsqmuntal2023-03-292-2/+7
| | | | | | | | | | | | | | | | | | | | | | | This CL updates the linker to support IMAGE_REL_[I386|AMD64|ARM|ARM64]_ADDR32NB relocations via the new R_PEIMAGEOFF relocation type. This relocation type references symbols using RVAs instead of VA, so it can use 4-byte offsets to reference symbols that would normally require 8-byte offsets. This new relocation is still not used, but will be useful when generating Structured Exception Handling (SEH) metadata, which needs to reference functions only using 4-byte addresses, thus using RVAs instead of VA is of great help. Updates #57302 Change-Id: I28d73e97d5cb78a3bc7194dc7d2fcb4a03f9f4d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/461737 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Davis Goodin <dagood@microsoft.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* Revert "cmd/link: establish dependable package initialization order"Keith Randall2023-03-091-6/+0
| | | | | | | | | | | | | | This reverts commit ce2a609909d9de3391a99a00fe140506f724f933. aka CL 462035 Reason for revert: this CL is causing some problems in some internal Google programs. Change-Id: I4476b8d8d2c3d7b5703d1d85c93baebb4b4e5d26 Reviewed-on: https://go-review.googlesource.com/c/go/+/474976 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
* Revert "cmd/internal/objabi: regenerate RelocType stringer file"Keith Randall2023-03-091-3/+2
| | | | | | | | | | | | | This reverts commit 99914db5eea927c7694276169585f1fff9e614c8. aka CL 473875 Reason for revert: init order change that required this CL is causing some problems in some internal Google programs. Change-Id: I801e278ab58d542c05c0332a9f1977b9588b6151 Reviewed-on: https://go-review.googlesource.com/c/go/+/474975 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Bypass: Keith Randall <khr@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
* cmd/internal/objabi: regenerate RelocType stringer fileqmuntal2023-03-071-2/+3
| | | | | | | | | | | | | | reloctype_strings.go is out-of-date since CL 462035, regenerate it. Found while working on CL 461737. Change-Id: I5cf910ab14c3618d6653c87861a4d53d3c91feff Reviewed-on: https://go-review.googlesource.com/c/go/+/473875 Auto-Submit: Quim Muntal <quimmuntal@gmail.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
* cmd/link: establish dependable package initialization orderKeith Randall2023-03-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | As described here: https://github.com/golang/go/issues/31636#issuecomment-493271830 "Find the lexically earliest package that is not initialized yet, but has had all its dependencies initialized, initialize that package, and repeat." Simplify the runtime a bit, by just computing the ordering required in the linker and giving a list to the runtime. Update #31636 Fixes #57411 RELNOTE=yes Change-Id: I1e4d3878ebe6e8953527aedb730824971d722cac Reviewed-on: https://go-review.googlesource.com/c/go/+/462035 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/dist: make toolchain build reproducibleRuss Cox2023-01-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Build cmd with CGO_ENABLED=0. Doing so removes the C compiler toolchain from the reproducibility perimeter and also results in cmd/go and cmd/pprof binaries that are statically linked, so that they will run on a wider variety of systems. In particular the Linux versions will run on Alpine and NixOS without needing a simulation of libc.so.6. The potential downside of disabling cgo is that cmd/go and cmd/pprof use the pure Go network resolver instead of the host resolver on Unix systems. This means they will not be able to use non-DNS resolver mechanisms that may be specified in /etc/resolv.conf, such as mDNS. Neither program seems likely to need non-DNS names like those, however. macOS and Windows systems still use the host resolver, which they access without cgo. - Build cmd with -trimpath when building a release. Doing so removes $GOPATH from the file name prefixes stored in the binary, so that the build directory does not leak into the final artifacts. - When CC and CXX are empty, do not pick values to hard-code into the source tree and binaries. Instead, emit code that makes the right decision at runtime. In addition to reproducibility, this makes cross-compiled toolchains work better. A macOS toolchain cross-compiled on Linux will now correctly look for clang, instead of looking for gcc because it was built on Linux. - Convert \ to / in file names stored in .a files. These are converted to / in the final binaries, but the hashes of the .a files affect the final build ID of the binaries. Without this change, builds of a Windows toolchain on Windows and non-Windows machines produce identical binaries except for the input hash part of the build ID. - Due to the conversion of \ to / in .a files, convert back when reading inline bodies on Windows to preserve output file names in error messages. Combined, these four changes (along with Go 1.20's removal of installed pkg/**.a files and conversion of macOS net away from cgo) make the output of make.bash fully reproducible, even when cross-compiling: a released macOS toolchain built on Linux or Windows will contain exactly the same bits as a released macOS toolchain built on macOS. The word "released" in the previous sentence is important. For the build IDs in the binaries to work out the same on both systems, a VERSION file must exist to provide a consistent compiler build ID (instead of using a content hash of the binary). For #24904. Fixes #57007. Change-Id: I665e1ef4ff207d6ff469452347dca5bfc81050e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/454836 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Russ Cox <rsc@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* runtime,cmd/link: increase stack guard space when building with -raceKeith Randall2022-11-181-6/+15
| | | | | | | | | | | | | | More stuff to do = more stack needed. Bump up the guard space when building with the race detector. Fixes #54291 Change-Id: I701bc8800507921bed568047d35b8f49c26e7df7 Reviewed-on: https://go-review.googlesource.com/c/go/+/451217 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
* all: fix problematic commentscui fliter2022-11-111-2/+2
| | | | | | | | | | | Change-Id: Ib6ea1bd04d9b06542ed2b0f453c718115417c62c Reviewed-on: https://go-review.googlesource.com/c/go/+/449755 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com>
* cmd/link: support PPC64 prefixed relocations for power10Paul E. Murphy2022-11-032-28/+55
| | | | | | | | | | | | | | | | | | Handle emitting (to ld) or resolving commonly used ELFv2 1.5 relocations. The new ISA provides PC relative addressing with 34 bit signed addresses, and many other relocations which can replace addis + d-form type relocations with a single prefixed instruction. Updates #44549 Change-Id: I7d4f4314d1082daa3938f4353826739be35b0e81 Reviewed-on: https://go-review.googlesource.com/c/go/+/355149 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Paul Murphy <murp@ibm.com>
* cmd/compile: add ability to indicate 'concurrentOk' for debug flagsDavid Chase2022-10-311-14/+22
| | | | | | | | | | | | Also removes no-longer-needed "Any" field from compiler's DebugFlags. Test/use case for this is the fmahash CL. Change-Id: I214f02c91f30fc2ce53caf75fa5e2b905dd33429 Reviewed-on: https://go-review.googlesource.com/c/go/+/445495 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: David Chase <drchase@google.com>
* cmd/internal/obj/arm64: optimize ADRP+ADD+LD/ST to ADRP+LD/ST(offset)eric fang2022-10-283-34/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL optimizes the sequence of instructions ADRP+ADD+LD/ST to the sequence of ADRP+LD/ST(offset). This saves an ADD instruction. The test result of compilecmp: name old text-bytes new text-bytes delta HelloSize 763kB ± 0% 755kB ± 0% -1.06% (p=0.000 n=20+20) name old data-bytes new data-bytes delta HelloSize 13.5kB ± 0% 13.5kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 227kB ± 0% 227kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.33MB ± 0% 1.33MB ± 0% -0.02% (p=0.000 n=20+20) file before after Δ % addr2line 3760392 3759504 -888 -0.024% api 5361511 5295351 -66160 -1.234% asm 5014157 4948674 -65483 -1.306% buildid 2579949 2579485 -464 -0.018% cgo 4492817 4491737 -1080 -0.024% compile 23359229 23156074 -203155 -0.870% cover 4823337 4756937 -66400 -1.377% dist 3332850 3331794 -1056 -0.032% doc 3902649 3836745 -65904 -1.689% fix 3269708 3268828 -880 -0.027% link 6510760 6443496 -67264 -1.033% nm 3670740 3604348 -66392 -1.809% objdump 4069599 4068967 -632 -0.016% pack 2374824 2374208 -616 -0.026% pprof 13874860 13805700 -69160 -0.498% test2json 2599210 2598530 -680 -0.026% trace 13231640 13162872 -68768 -0.520% vet 7360899 7292267 -68632 -0.932% total 113589131 112775517 -813614 -0.716% Change-Id: Ie1cf277e149ddd3f352d05fa0753d0ced7e0b894 Reviewed-on: https://go-review.googlesource.com/c/go/+/444715 Run-TryBot: Eric Fang <eric.fang@arm.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
* cmd/compile,cmd/link: hooks for identifying coverage countersThan McIntosh2022-09-272-3/+8
| | | | | | | | | | | | | | | Add a new "coverage counter" classification for variables to be used for storing code coverage counter values (somewhat in the same way that we identify fuzzer counters). Tagging such variables allows us to aggregate them in the linker, and to treat updates specially. Updates #51430. Change-Id: Ib49fb05736ffece98bcc2f7a7c37e991b7f67bbb Reviewed-on: https://go-review.googlesource.com/c/go/+/401235 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* all: replace package ioutil with os and io in srcAndy Pan2022-09-201-2/+1
| | | | | | | | | | | | | For #45557 Change-Id: I56824135d86452603dd4ed4bab0e24c201bb0683 Reviewed-on: https://go-review.googlesource.com/c/go/+/426257 Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Andy Pan <panjf2000@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
* cmd/internal/objabi: record GO$GOARCH setting in object headerRuss Cox2022-09-161-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The object header string is meant to record the relevant toolchain configuration, so that we don't import or link object files that are incompatible with each other. One important part of compatibility is the sub-architecture version (GOARM for GOARCH=arm, and so on). Add the sub-architecture info to the object header line so that binaries cannot be built that have inconsistent sub-architecture configurations across the build. This check is only important when the build system makes a mistake. Builds using the go command don't make this kind of mistake anymore, but we just debugged a difficult problem inside Google where a custom build system had built part of a program with GOARM=5 and part of a program with GOARM=7, resulting in corrupted execution when signal-based preemption was attempted. Updating the check will avoid this kind of problem in the future, in any custom build system, or if the go command makes a mistake. After this change: % sed 3q pkg/darwin_amd64/runtime.a !<arch> __.PKGDEF 0 0 0 644 30525 ` go object darwin amd64 devel go1.20-102ebe10b7 Wed Aug 17 14:31:01 2022 -0400 GOAMD64=v1 X:regabiwrappers,regabiargs % Change-Id: I901e0758f1002dd2c58292dc65e2d06da86e4495 Reviewed-on: https://go-review.googlesource.com/c/go/+/427174 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/internal/objabi: declare HeadType String on a non-pointer receiverJoel Sing2022-09-131-3/+3
| | | | | | | | | | | | | | objabi.HeadType is typically used as a non-pointer type, however the String function is declared on a pointer receiver. This means that in most cases its integer value is printed, rather than the value from the String function. Change-Id: I3d28d9680e88a714bc1152ed5e1df4ac43d7a33f Reviewed-on: https://go-review.googlesource.com/c/go/+/430556 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Jenny Rakoczy <jenny@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Jenny Rakoczy <jenny@golang.org>
* cmd/internal/objabi: use strings.Builderhopehook2022-09-011-3/+1
| | | | | | | | | | | | | | Since when go1.17 is now used for bootstraping. Change-Id: I5ee65aff72500a04e243238cffeae92ea659627b Reviewed-on: https://go-review.googlesource.com/c/go/+/427555 Auto-Submit: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: hopehook <hopehook@golangcn.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
* cmd/dist: force stackGuardMultiplierDefault to 1Russ Cox2022-08-051-1/+1
| | | | | | | | | | | | Nothing seems to break, not even the noopt builder. For #51256 (the conversation there is headed toward additional changes). Change-Id: Icb7ca451159a74f351c25d2cefb32c773b9bb017 Reviewed-on: https://go-review.googlesource.com/c/go/+/416859 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile, cmd/link: use libFuzzer 8-bit instead of extra countersKhaled Yakdan2022-05-202-5/+5
| | | | | | | | | | | | | | | | | | | | | | | By using libFuzzer’s 8-bit counters instead of extra counters, the coverage instrumentation in libFuzzer mode is improved in three ways: 1- 8-bit counters are supported on all platforms, including macOS and Windows, with all relevant versions of libFuzzer, whereas extra counters are a Linux-only feature that only recently received support on Windows. 2- Newly covered blocks are now properly reported as new coverage by libFuzzer, not only as new features. 3- The NeverZero strategy is used to ensure that coverage counters never become 0 again after having been positive once. This resolves issues encountered when fuzzing loops with iteration counts that are multiples of 256 (e.g., larger powers of two). Change-Id: I9021210d7fbffd07c891ad08750402ee91cb3df5 GitHub-Last-Rev: 9057e4b21d146ce9ffb3993982bfb84b96705989 GitHub-Pull-Request: golang/go#51318 Reviewed-on: https://go-review.googlesource.com/c/go/+/387334 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org>
* cmd/internal/objabi: define Go relocation types for loong64Xiaodong Liu2022-05-022-8/+42
| | | | | | | | | | | | | | | | | | | | | | | | | Contributors to the loong64 port are: Weining Lu <luweining@loongson.cn> Lei Wang <wanglei@loongson.cn> Lingqin Gong <gonglingqin@loongson.cn> Xiaolin Zhao <zhaoxiaolin@loongson.cn> Meidan Li <limeidan@loongson.cn> Xiaojuan Zhai <zhaixiaojuan@loongson.cn> Qiyuan Pu <puqiyuan@loongson.cn> Guoqi Chen <chenguoqi@loongson.cn> This port has been updated to Go 1.15.6: https://github.com/loongson/go Updates #46229 Change-Id: I8d31b3cd827325aa0ff748ca8c0c0da6df6ed99f Reviewed-on: https://go-review.googlesource.com/c/go/+/396734 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
* all: separate doc comment from //go: directivesRuss Cox2022-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | A future change to gofmt will rewrite // Doc comment. //go:foo to // Doc comment. // //go:foo Apply that change preemptively to all comments (not necessarily just doc comments). For #51082. Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9 Reviewed-on: https://go-review.googlesource.com/c/go/+/384260 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/internal/objabi: fix FuncID of runtime.rt0_go and runtime.systemstack_switchzhouguangyuan2022-04-051-20/+20
| | | | | | | | | | | Fixes #52092 Change-Id: I774a6722c6e3ce6781e1d8bc16ac68efee6f9c70 Reviewed-on: https://go-review.googlesource.com/c/go/+/396797 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Trust: Ian Lance Taylor <iant@golang.org>
* internal/buildcfg: initialize GOROOT to runtime.GOROOTBryan C. Mills2022-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the beginning the Go compiler was in C, and C had a function 'getgoroot' that returned GOROOT from either the environment or a generated constant. 'getgoroot' was mechanically converted to Go (as obj.Getgoroot) in CL 3046. obj.Getgoroot begat obj.GOROOT. obj.GOROOT begat objabi.GOROOT, which begat buildcfg.GOROOT. As far as I can tell, today's buildcfg.GOROOT is functionally identical to runtime.GOROOT(). Let's reduce some complexity by defining it in those terms. While we're thinking about buildcfg.GOROOT, also check whether it is non-empty: if the toolchain is built with -trimpath, the value of GOROOT might not be valid or meaningful if the user invokes cmd/compile or cmd/link directly, or via a build tool other than cmd/go that doesn't care as much about GOROOT. (As of CL 390024, runtime.GOROOT will return the empty string instead of a bogus one when built with -trimpath.) For #51461. Change-Id: I9fec020d5fa65d4aff0dd39b805f5ca93f86c36e Reviewed-on: https://go-review.googlesource.com/c/go/+/393155 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* internal/buildcfg: extract logic specific to cmd/goBryan C. Mills2022-03-182-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cmd/go/internal/cfg duplicates many of the fields of internal/buildcfg, but initializes them from a Go environment file in addition to the usual process environment. internal/buildcfg doesn't (and shouldn't) know or care about that environment file, but prior to this CL it exposed hooks for cmd/go/internal/cfg to write data back to internal/buildcfg to incorporate information from the file. It also produced quirky GOEXPERIMENT strings when a non-trivial default was overridden, seemingly so that 'go env' would produce those same quirky strings in edge-cases where they are needed. This change reverses that information flow: internal/buildcfg now exports a structured type with methods — instead of top-level functions communicating through global state — so that cmd/go can utilize its marshaling and unmarshaling functionality without also needing to write results back into buildcfg package state. The quirks specific to 'go env' have been eliminated by distinguishing between the raw GOEXPERIMENT value set by the user (which is what we should report from 'go env') and the cleaned, canonical equivalent (which is what we should use in the build cache key). For #51461. Change-Id: I4ef5b7c58b1fb3468497649a6d2fb6c19aa06c70 Reviewed-on: https://go-review.googlesource.com/c/go/+/393574 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile, runtime: use unwrapped PC for goroutine creation tracingCherry Mui2022-02-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the switch to the register ABI, we now generate wrapper functions for go statements in many cases. A new goroutine's start PC now points to the wrapper function. This does not affect execution, but the runtime tracer uses the start PC and the function name as the name/label of that goroutine. If the start function is a named function, using the name of the wrapper loses that information. Furthur, the tracer's goroutine view groups goroutines by start PC. For multiple go statements with the same callee, they are grouped together. With the wrappers, which is context-dependent as it is a closure, they are no longer grouped. This CL fixes the problem by providing the underlying unwrapped PC for tracing. The compiler emits metadata to link the unwrapped PC to the wrapper function. And the runtime reads that metadata and record that unwrapped PC for tracing. (This doesn't work for shared buildmode. Unfortunate.) TODO: is there a way to test? Fixes #50622. Change-Id: Iaa20e1b544111c0255eb0fc04427aab7a5e3b877 Reviewed-on: https://go-review.googlesource.com/c/go/+/384158 Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile,cmd/internal/objabi: move -d flag parser to objabiAustin Clements2021-11-051-0/+164
| | | | | | | | | | | | | | | | | | | | | | | | | This moves and slightly generalizes the -d debug flag parser from cmd/compile/internal/base to cmd/internal/objabi so that we can use the same debug flag syntax in other tools. This makes a few minor tweaks to implementation details. The flag itself is now just a flag.Value that gets constructed explicitly, rather than at init time, and we've cleaned up the implementation a little (e.g., using a map instead of a linear search of a slice). The help text is now automatically alphabetized. Rather than describing the values of some flags in the help text footer, we simply include it in the flags' help text and make sure multi-line help text renders sensibly. For #48297. Change-Id: Id373ee3b767e456be483fb28c110d025149be532 Reviewed-on: https://go-review.googlesource.com/c/go/+/359956 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* cmd/compile, runtime: track argument stack slot livenessCherry Mui2021-10-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, for stack traces (e.g. at panic or when runtime.Stack is called), we print argument values from the stack. With register ABI, we may never store the argument to stack therefore the argument value on stack may be meaningless. This causes confusion. This CL makes the compiler keep trace of which argument stack slots are meaningful. If it is meaningful, it will be printed in stack traces as before. If it may not be meaningful, it will be printed as the stack value with a question mark ("?"). In general, the value could be meaningful on some code paths but not others depending on the execution, and the compiler couldn't know statically, so we still print the stack value, instead of not printing it at all. Also note that if the argument variable is updated in the function body the printed value may be stale (like before register ABI) but still considered meaningful. Arguments passed on stack are always meaningful therefore always printed without a question mark. Results are never printed, as before. (Due to a bug in the compiler we sometimes don't spill args into their dedicated spill slots (as we should), causing it having fewer meaningful values than it should be.) This increases binary sizes a bit: old new hello 1129760 1142080 +1.09% cmd/go 13932320 14088016 +1.12% cmd/link 6267696 6329168 +0.98% Fixes #45728. Change-Id: I308a0402e5c5ab94ca0953f8bd85a56acd28f58c Reviewed-on: https://go-review.googlesource.com/c/go/+/352057 Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
* cmd/compile,cmd/link: introduce generic interface call relocationsKeith Randall2021-10-252-39/+45
| | | | | | | | | | | | | | | | | | | | To capture the fact that a method was called on a generic interface, so we can make sure the linker doesn't throw away any implementations that might be the method called. See the comment in reflect.go for details. Fixes #49049 Change-Id: I0be74b6e727c1ecefedae072b149f59d539dc1e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/357835 Trust: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dan Scales <danscales@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
* cmd, runtime: mark assembly routines in FuncFlagsJosh Bleecher Snyder2021-10-041-0/+1
| | | | | | | | | | | | | | | | | | | | There's no good way to ascertain at runtime whether a function was implemented in assembly. The existing workaround doesn't play nicely with some upcoming linker changes. This change introduces an explicit marker for routines implemented in assembly. This change doesn't use the new bit anywhere, it only introduces it. Change-Id: I4051dc0afc15b260724a04b9d18aeeb94911bb29 Reviewed-on: https://go-review.googlesource.com/c/go/+/353671 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
* cmd/internal/obj/riscv,cmd/link/internal/riscv64: add call trampolines for ↵Joel Sing2021-10-022-53/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | riscv64 CALL and JMP on riscv64 are currently implemented as an AUIPC+JALR pair. This means that every call requires two instructions and makes use of the REG_TMP register, even when the symbol would be directly reachable via a single JAL instruction. Add support for call trampolines - CALL and JMP are now implemented as a single JAL instruction, with the linker generating trampolines in the case where the symbol is not reachable (more than +/-1MiB from the JAL instruction), is an unknown symbol or does not yet have an address assigned. Each trampoline contains an AUIPC+JALR pair, which the relocation is applied to. Due to the limited reachability of the JAL instruction, combined with the way that the Go linker currently assigns symbol addresses, there are cases where a call is to a symbol that has no address currently assigned. In this situation we have to assume that a trampoline will be required, however we can patch this up during relocation, potentially calling directly instead. This means that we will end up with trampolines that are unused. In the case of the Go binary, there are around 3,500 trampolines of which approximately 2,300 are unused (around 9200 bytes of machine instructions). Overall, this removes over 72,000 AUIPC instructions from the Go binary. Change-Id: I2d9ecfb85dfc285c7729a3cd0b3a77b6f6c98be0 Reviewed-on: https://go-review.googlesource.com/c/go/+/345051 Trust: Joel Sing <joel@sing.id.au> Run-TryBot: Joel Sing <joel@sing.id.au> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
* cmd/compile: break out constants for local and global dictionary prefixesDan Scales2021-09-221-1/+2
| | | | | | | | | | | | | | | | Create constant LocalDictName for the pname/refix for dictionary parameters or local variables, and constant GlobalDictPrefix for the prefix for names of global dictionaries. I wanted to make sure these constants were set up as we add more reference to dictionaries for debugging, etc. Change-Id: Ide801f842383300a2699c96943ec06decaecc358 Reviewed-on: https://go-review.googlesource.com/c/go/+/351450 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
* cmd/link: remove ABI aliasesCherry Mui2021-09-222-11/+3
| | | | | | | | | | | It is now gone. Change-Id: I59f68b324af706476695de2f291dd3aa5734e192 Reviewed-on: https://go-review.googlesource.com/c/go/+/351332 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>
* [dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loopAustin Clements2021-08-031-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, deferreturn runs deferred functions by backing up its return PC to the deferreturn call, and then effectively tail-calling the deferred function (via jmpdefer). The effect of this is that the deferred function appears to be called directly from the deferee, and when it returns, the deferee calls deferreturn again so it can run the next deferred function if necessary. This unusual flow control leads to a large number of special cases and complications all over the tool chain. This used to be necessary because deferreturn copied the deferred function's argument frame directly into its caller's frame and then had to invoke that call as if it had been called from its caller's frame so it could access it arguments. But now that we've simplified defer processing so the runtime only deals with argument-less closures, this approach is no longer necessary. This CL simplifies all of this by making deferreturn simply call deferred functions in a loop. This eliminates the need for jmpdefer, so we can delete a bunch of per-architecture assembly code. This eliminates several special cases on Wasm, since it couldn't support these calling shenanigans directly and thus had to simulate the loop a different way. Now Wasm can largely work the way the other platforms do. This eliminates the per-architecture Ginsnopdefer operation. On PPC64, this was necessary to reload the TOC pointer after the tail call (since TOC pointers in general make tail calls impossible). The tail call is gone, and in the case where we do force a jump to the deferreturn call when recovering from an open-coded defer, we go through gogo (via runtime.recovery), which handles the TOC. On other platforms, we needed a NOP so traceback didn't get confused by seeing the return to the CALL instruction, rather than the usual return to the instruction following the CALL instruction. Now we don't inject a return to the CALL instruction at all, so this NOP is also unnecessary. The one potential effect of this is that deferreturn could now appear in stack traces from deferred functions. However, this could already happen from open-coded defers, so we've long since marked deferreturn as a "wrapper" so it gets elided not only from printed stack traces, but from runtime.Callers*. This is a retry of CL 337652 because we had to back out its parent. There are no changes in this version. Change-Id: I3f54b7fec1d7ccac71cc6cf6835c6a46b7e5fb6c Reviewed-on: https://go-review.googlesource.com/c/go/+/339397 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
* [dev.typeparams] Revert "[dev.typeparams] runtime,cmd/compile,cmd/link: ↵Austin Clements2021-07-301-0/+2
| | | | | | | | | | | | | | | replace jmpdefer with a loop" This reverts CL 227652. I'm reverting CL 337651 and this builds on top of it. Change-Id: I03ce363be44c2a3defff2e43e7b1aad83386820d Reviewed-on: https://go-review.googlesource.com/c/go/+/338709 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
* [dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loopAustin Clements2021-07-301-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, deferreturn runs deferred functions by backing up its return PC to the deferreturn call, and then effectively tail-calling the deferred function (via jmpdefer). The effect of this is that the deferred function appears to be called directly from the deferee, and when it returns, the deferee calls deferreturn again so it can run the next deferred function if necessary. This unusual flow control leads to a large number of special cases and complications all over the tool chain. This used to be necessary because deferreturn copied the deferred function's argument frame directly into its caller's frame and then had to invoke that call as if it had been called from its caller's frame so it could access it arguments. But now that we've simplified defer processing so the runtime only deals with argument-less closures, this approach is no longer necessary. This CL simplifies all of this by making deferreturn simply call deferred functions in a loop. This eliminates the need for jmpdefer, so we can delete a bunch of per-architecture assembly code. This eliminates several special cases on Wasm, since it couldn't support these calling shenanigans directly and thus had to simulate the loop a different way. Now Wasm can largely work the way the other platforms do. This eliminates the per-architecture Ginsnopdefer operation. On PPC64, this was necessary to reload the TOC pointer after the tail call (since TOC pointers in general make tail calls impossible). The tail call is gone, and in the case where we do force a jump to the deferreturn call when recovering from an open-coded defer, we go through gogo (via runtime.recovery), which handles the TOC. On other platforms, we needed a NOP so traceback didn't get confused by seeing the return to the CALL instruction, rather than the usual return to the instruction following the CALL instruction. Now we don't inject a return to the CALL instruction at all, so this NOP is also unnecessary. The one potential effect of this is that deferreturn could now appear in stack traces from deferred functions. However, this could already happen from open-coded defers, so we've long since marked deferreturn as a "wrapper" so it gets elided not only from printed stack traces, but from runtime.Callers*. Change-Id: Ie9f700cd3fb774f498c9edce363772a868407bf7 Reviewed-on: https://go-review.googlesource.com/c/go/+/337652 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
* [dev.typeparams] runtime: remove variadic defer/go callsCherry Mui2021-06-081-1/+0
| | | | | | | | | | | | | | | Now that defer/go wrapping is used, deferred/go'd functions are always argumentless. Remove the code handling arguments. This CL is mostly removing the fallback code path. There are more cleanups to be done, in later CLs. Change-Id: I87bfd3fb2d759fbeb6487b8125c0f6992863d6e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/325915 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
* cmd/compile: always include underlying type for map typesKeith Randall2021-05-242-35/+39
| | | | | | | | | | | | | | | This is a different fix for #37716. Should help make the fix for #46283 easier, since we will no longer need to keep compiler-generated hash functions and the runtime hash function in sync. Change-Id: I84cb93144e425dcd03afc552b5fbd0f2d2cc6d39 Reviewed-on: https://go-review.googlesource.com/c/go/+/322150 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
* syscall, etc.: use abi.FuncPCABI0 for libc syscall wrappersCherry Zhang2021-04-261-2/+0
| | | | | | | | | | | | | | | | | | | | In CL 288092 we made Darwin syscall wrappers as ABIInternal, so their addresses taken from Go using funcPC are the actual function entries, not the wrappers. As we introduced internal/abi.FuncPCABIxxx intrinsics, use that. And change the assembly functions back to ABI0. Do it on OpenBSD as well, as OpenBSD and Darwin share code generator. Change-Id: I408120795f7fc826637c867394248f8f373906bd Reviewed-on: https://go-review.googlesource.com/c/go/+/313230 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
View Lorry Controller Status