aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/internal/obj/link.go
AgeCommit message (Collapse)Author
2026-01-26cmd/compile: reduce lock/scheduler contentionDaniel Morsing
During the parallel section of compilation, we limit the amount of parallelism to prevent scheduler churn. We do this with a worker scheduler, but it does not have insight on when a compilation is blocked due to lock contention. The symbol table was protected with a lock. While most lookups were quick lock->read->unlock affairs, sometimes there would be initialization logic involved. This caused every lookup to stall, waiting for init. Since our worker scheduler couldn't see this, it would not launch new goroutine to "cover" the gap. Fix by splitting the symbol lock into 2 cases, initialization and lookup. If symbols need initialization simultaneously, they will wait for each other, but the common case of looking up a symbol will be handled by a syncmap. In practice, I have yet to see this lock being blocked on. Additionally, get rid of the scheduler goroutine and have each compilation goroutine grab work from a central queue. When multiple compilations finished at the same time, the work scheduler would sometime not get run immediately. This ended up starving the system of work. These 2 changes together cuts -1.37% off the build time of typescriptgo on systems with a lot of cores (specifically, the c3h88 perf builder). Updates #73044. Change-Id: I6d4b3be56fd00a4fdd4df132bcbd52e4b2a3e91f Reviewed-on: https://go-review.googlesource.com/c/go/+/724623 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
2025-11-18cmd/asm,cmd/compile,cmd/internal/obj/riscv: use compressed instructions on ↵Joel Sing
riscv64 Make use of compressed instructions on riscv64 - add a compress pass to the end of the assembler, which replaces non-compressed instructions with compressed alternatives if possible. Provide a `compressinstructions` compiler and assembler debug flag, such that the compression pass can be disabled via `-asmflags=all=-d=compressinstructions=0` and `-gcflags=all=-d=compressinstructions=0`. Note that this does not prevent the explicit use of compressed instructions via assembly. Note that this does not make use of compressed control transfer instructions - this will be implemented in later changes. Reduces the text size of a hello world binary by ~121KB and reduces the text size of the go binary on riscv64 by ~1.21MB (between 8-10% in both cases). Updates #71105 Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64 Change-Id: I24258353688554042c2a836deed4830cc673e985 Reviewed-on: https://go-review.googlesource.com/c/go/+/523478 Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-11-11std,cmd: go fix -any std cmdAlan Donovan
This change mechanically replaces all occurrences of interface{} by 'any' (where deemed safe by the 'any' modernizer) throughout std and cmd, minus their vendor trees. Since this fix is relatively numerous, it gets its own CL. Also, 'go generate go/types'. Change-Id: I14a6b52856c3291c1d27935409bca8d5fd4242a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/719702 Commit-Queue: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Alan Donovan <adonovan@google.com>
2025-10-21all: eliminate unnecessary type conversionsJes Cok
Found by github.com/mdempsky/unconvert Change-Id: I88ce10390a49ba768a4deaa0df9057c93c1164de GitHub-Last-Rev: 3b0f7e8f74f58340637f33287c238765856b2483 GitHub-Pull-Request: golang/go#75974 Reviewed-on: https://go-review.googlesource.com/c/go/+/712940 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
2025-10-08cmd/internal/obj: fix Link.Diag printf errorsAlan Donovan
go1.26's vet printf checker can associate the printf-wrapper property with local vars and struct fields if they are assigned from a printf-like func literal (CL 706635). This leads to better detection of mistakes. Change-Id: I604be1e200aa1aba75e09d4f36ab68c1dba3b8a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/710195 Auto-Submit: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-09-30cmd/compile/internal/ssa: remove redundant "type:" prefix checkYoulin Feng
Remove redundant "type:" prefix check on symbol names in isFixedLoad, also refactor some duplicate code into methods. Change-Id: I8358422596eea8c39d1a30a554bd0aae8b570038 Reviewed-on: https://go-review.googlesource.com/c/go/+/701275 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-09-12cmd/asm, cmd/internal/obj: add riscv64 generic CSR opsMark Ryan
Support is added for the generic RISC-V CSR operations; CSRRC, CSRRCI, CSRRS, CSRRSI, CSRRW, CSRRWI. These instructions require special handling as their second operand is a symbolic CSR register name and not an immediate value or a register. CSR names are implemented as special operands. RISC-V CSRs are not currently saved and restored when a go routine is asynchronously pre-empted so it is only safe to use these instructions in hand written assembler. Note that CSRRS was already partially supported by the assembler so this restriction predates this commit. We mention it here as this commit makes CSRRS much easier to use. Change-Id: I9ff8d804328b418a879d463e7d9cc31f489c7a00 Reviewed-on: https://go-review.googlesource.com/c/go/+/630519 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Joel Sing <joel@sing.id.au> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-02-22cmd: initial compiler+linker support for DWARF5 .debug_addrThan McIntosh
This patch rolls the main .debug_info DWARF section from version 4 to version 5, and also introduces machinery in the Go compiler and linker for taking advantage of the DWARF5 ".debug_addr" section for subprogram DIE "high" and "low" PC attributes. All functionality is gated by GOEXPERIMENT=dwarf5. For the compiler portion of this patch, we add a new DIE attribute form "DW_FORM_addrx", which accepts as an argument a function (text) symbol. The dwarf "putattr" function is enhanced to handle this format by invoking a new dwarf context method "AddIndirectTextRef". Under the hood, this method invokes the Lsym method WriteDwTxtAddrx, which emits a new objabi.R_DWTXTADDR_* relocation. The size of the relocation is dependent on the number of functions in the package; we pick a size that is just big enough for the largest func index. In the linker portion of this patch, we now switch over to writing out a version number of 5 (instead of 4) in the compile unit header (this is required if we want to use addrx attributes). In the parallel portion of DWARF gen, within each compilation unit we scan subprogram DIEs to look for R_DWTXTADDR_* relocations, and when we find such a reloc, we assign a slot in the .debug_addr section for the func targeted. After the parallel portion is complete, we then walk through all of the compilation units to assign a value to their DW_AT_addr_base attribute, which points to the portion of the single .debug_addr section containing the text addrs for that compilation unit. Note that once this patch is in, programs built with GOEXPERIMENT=dwarf5 will have broken/damaged DWARF info; in particular, since we've changed only the CU and subprogram DIEs and haven't incorported the other changes mandated by DWARF5 (ex: .debug_ranges => .debug_rnglists) a lot of the variable location info will be missing/incorrect. This will obviously change in subsequent patches. Note also that R_DWTXTADDR_* can't be used effectively for lexical scope DIE hi/lo PC attrs, since there isn't a viable way to encode "addrx + constant" in the attribute value (you would need a new entry for each attr endpoint in .debug_addr, which would defeat the point). Updates #26379. Change-Id: I2dfc45c9a8333e7b2a58f8e3b88fc8701fefd006 Reviewed-on: https://go-review.googlesource.com/c/go/+/635337 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-02-14cmd/asm,cmd/internal/obj/riscv: implement vector configuration setting ↵Joel Sing
instructions Implement vector configuration setting instructions (VSETVLI, VSETIVLI, VSETL). These allow the vector length (vl) and vector type (vtype) CSRs to be configured via a single instruction. Unfortunately each instruction has its own dedicated encoding. In the case of VSETVLI/VSETIVLI, the vector type is specified via a series of special operands, which specify the selected element width (E8, E16, E32, E64), the vector register group multiplier (M1, M2, M4, M8, MF2, MF4, MF8), the vector tail policy (TU, TA) and vector mask policy (MU, MA). Note that the order of these special operands matches non-Go assemblers. Partially based on work by Pengcheng Wang <wangpengcheng.pp@bytedance.com>. Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64 Change-Id: I431f59c1e048a3e84754f0643a963da473a741fe Reviewed-on: https://go-review.googlesource.com/c/go/+/631936 Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-02-10cmd/compile: avoid ifaceeq call if we know the interface is directKeith Randall
We can just use == if the interface is direct. Fixes #70738 Change-Id: Ia9a644791a370fec969c04c42d28a9b58f16911f Reviewed-on: https://go-review.googlesource.com/c/go/+/635435 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-13cmd/internal/obj/loong64: add support of VMOVQ and XVMOVQGuoqi Chen
This CL refers to the implementation of ARM64 and adds support for the following types of SIMD instructions: 1. Move general-purpose register to a vector element, e.g.: VMOVQ Rj, <Vd>.<T>[index] <T> can have the following values: B, H, W, V 2. Move vector element to general-purpose register, e.g.: VMOVQ <Vj>.<T>[index], Rd <T> can have the following values: B, BU, H, HU, W, WU, VU 3. Duplicate general-purpose register to vector, e.g.: VMOVQ Rj, <Vd>.<T> <T> can have the following values: B16, H8, W4, V2, B32, H16, W8, V4 4. Move vector, e.g.: XVMOVQ Xj, <Xd>.<T> <T> can have the following values: B16, H8, W4, V2, Q1 5. Move vector element to scalar, e.g.: XVMOVQ Xj, <Xd>.<T>[index] XVMOVQ Xj.<T>[index], Xd <T> can have the following values: W, V 6. Move vector element to vector register, e.g.: VMOVQ <Vn>.<T>[index], Vn.<T> <T> can have the following values: B, H, W, V This CL only adds syntax and doesn't break any assembly that already exists. Change-Id: I7656efac6def54da6c5ae182f39c2a21bfdf92bb Reviewed-on: https://go-review.googlesource.com/c/go/+/616258 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-11cmd/compile: allow more types for wasmimport/wasmexport parameters and resultsCherry Mui
As proposed on #66984, this CL allows more types to be used as wasmimport/wasmexport function parameters and results. Specifically, bool, string, and uintptr are now allowed, and also pointer types that point to allowed element types. Allowed element types includes sized integer and floating point types (including small integer types like uint8 which are not directly allowed as a parameter type), bool, array whose element type is allowed, and struct whose fields are allowed element type and also include a struct.HostLayout field. For #66984. Change-Id: Ie5452a1eda21c089780dfb4d4246de6008655c84 Reviewed-on: https://go-review.googlesource.com/c/go/+/626615 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-07cmd/internal/obj: replace obj.Addrel func with LSym.AddRel methodRuss Cox
The old API was to do r := obj.AddRel(sym) r.Type = this r.Off = that etc The new API is: sym.AddRel(ctxt, obj.Reloc{Type: this: Off: that, etc}) This new API is more idiomatic and avoids ever having relocations that are only partially constructed. Most importantly, it sets up for sym.AddRel being able to check relocation validity in the future. (Passing ctxt is for use in validity checking.) Passes golang.org/x/tools/cmd/toolstash/buildall. Change-Id: I042ea76e61bb3bf6402f98ca11291a13f4799972 Reviewed-on: https://go-review.googlesource.com/c/go/+/625616 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-10-22cmd/compile: use STP/LDP around morestack on arm64Keith Randall
The spill/restore code around morestack is almost never exectued, so we should make it as small as possible. Using 2-register loads/stores makes sense here. Also, the offsets from SP are pretty small so the offset almost always fits in the (smaller than a normal load/store) offset field of the instruction. Makes cmd/go 0.6% smaller. Change-Id: I8845283c1b269a259498153924428f6173bda293 Reviewed-on: https://go-review.googlesource.com/c/go/+/621556 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-08-09cmd/compile: add basic wasmexport supportCherry Mui
This CL adds a compiler directive go:wasmexport, which applies to a Go function and makes it an exported function of the Wasm module being built, so it can be called directly from the host. As proposed in #65199, parameter and result types are limited to 32-bit and 64-bit integers and floats, and there can be at most one result. As the Go and Wasm calling conventions are different, for a wasmexport function we generate a wrapper function does the ABI conversion at compile time. Currently this CL only adds basic support. In particular, - it only supports executable mode, i.e. the Go wasm module calls into the host via wasmimport, which then calls back to Go via wasmexport. Library (c-shared) mode is not implemented yet. - only supports wasip1, not js. - if the exported function unwinds stacks (goroutine switch, stack growth, etc.), it probably doesn't work. TODO: support stack unwinding, c-shared mode, js. For #65199. Change-Id: Id1777c2d44f7d51942c1caed3173c0a82f120cc4 Reviewed-on: https://go-review.googlesource.com/c/go/+/603055 Reviewed-by: Than McIntosh <thanm@golang.org> Reviewed-by: Randy Reddig <randy.reddig@fastly.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-08-06cmd/internal/obj: minor refactor of wasmimport codeCherry Mui
This CL does some minor refactoring of the code handling wasmimport. - Put the WasmImport aux reading and writing code together for symmetry. - Define WasmFuncType, embedded in WasmImport. WasmFuncType could also be used (later) for wasmexport. - Move code generation code to a separate function. The containing function is already pretty large. - Simplify linker code a little bit. The loader convention is to return the 0 Sym for nonexistent symbol, instead of a separate boolean. No change in generated code. Passes toolstash -cmp (GOARCH=wasm GOOS=wasip1 go build -toolexec "toolstash -cmp" -a std cmd). Change-Id: Idc2514f84a08621333841ae4034b81130e0ce411 Reviewed-on: https://go-review.googlesource.com/c/go/+/603135 Reviewed-by: Than McIntosh <thanm@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2024-05-15cmd/link: disallow pull-only linknamesCherry Mui
As mentioned in CL 584598, linkname is a mechanism that, when abused, can break API integrity and even safety of Go programs. CL 584598 is a first step to restrict the use of linknames, by implementing a blocklist. This CL takes a step further, tightening up the restriction by allowing linkname references ("pull") only when the definition side explicitly opts into it, by having a linkname on the definition (possibly to itself). This way, it is at least clear on the definition side that the symbol, despite being unexported, is accessed outside of the package. Unexported symbols without linkname can now be actually private. This is similar to the symbol visibility rule used by gccgo for years (which defines unexported non-linknamed symbols as C static symbols). As there can be pull-only linknames in the wild that may be broken by this change, we currently only enforce this rule for symbols defined in the standard library. Push linknames are added in the standard library to allow things build. Linkname references to external (non-Go) symbols are still allowed, as their visibility is controlled by the C symbol visibility rules and enforced by the C (static or dynamic) linker. Assembly symbols are treated similar to linknamed symbols. This is controlled by -checklinkname linker flag, currently not enabled by default. A follow-up CL will enable it by default. Change-Id: I07344f5c7a02124dbbef0fbc8fec3b666a4b2b0e Reviewed-on: https://go-review.googlesource.com/c/go/+/585358 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
2024-05-15cmd/compile, cmd/internal: fine-grained fiddling with loop alignmentDavid Chase
This appears to be useful only on amd64, and was specifically benchmarked on Apple Silicon and did not produce any benefit there. This CL adds the assembly instruction `PCALIGNMAX align,amount` which aligns to `align` if that can be achieved with `amount` or fewer bytes of padding. (0 means never, but will align the enclosing function.) Specifically, if low-order-address-bits + amount are greater than or equal to align; thus, `PCALIGNMAX 64,63` is the same as `PCALIGN 64` and `PCALIGNMAX 64,0` will never emit any alignment, but will still cause the function itself to be aligned to (at least) 64 bytes. Change-Id: Id51a056f1672f8095e8f755e01f72836c9686aa3 Reviewed-on: https://go-review.googlesource.com/c/go/+/577935 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-05-15cmd/internal/obj/x86: make SEH symbols content-addressableCherry Mui
Currently, the SEH symbol is defined as an aux symbol of the function symbol, without adding to ctxt.Data. Each function has its own SEH symbol. As there are a lot of duplications of the SEH symbol contents, currently a Go object file may contain many copies of identical SEH symbols. They are deduplicated at link time. But it does make the linker do redundant work, and make it hard to reason about the SEH symbol writing in the object file writer, and its resolution in the linker. In fact, in the object file writer, the same SEH symbol may be added to the ctxt.defs multiple times (as it is the aux of multiple function symbols), which is not expected. In fact, "aux symbol" is just a mechanism to associate auxiliary data to another symbol. The auxiliary data symbol itself can be an ordinary data symbol, even a content-addressable symbol. Define the SEH symbol as a conntent-addressable symbol and add it to ctxt.Data. This way there is only one definition of each unique SEH symbol, which can be the aux of many functions. While here, add a check to ensure that we add a symbol at most once to the defs list. Change-Id: Ie7a0cf02ca114060423e025931b30de97ca330fe Reviewed-on: https://go-review.googlesource.com/c/go/+/585656 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
2024-05-10cmd/compile, cmd/link: disallow linkname of some newly added internal functionsCherry Mui
Go API is defined through exported symbols. When a package is imported, the compiler ensures that only exported symbols can be accessed, and the go command ensures that internal packages cannot be imported. This ensures API integrity. But there is a hole: using linkname, one can access internal or non-exported symbols. Linkname is a mechanism to give access of a symbol to a package without adding it to the public API. It is intended for coupled packages to share some implementation details, or to break circular dependencies, and both "push" (definition) and "pull" (reference) sides are controlled, so they can be updated in sync. Nevertheless, it is abused as a mechanism to reach into internal details of other packages uncontrolled by the user, notably the runtime. As the other package evolves, the code often breaks, because the linknamed symbol may no longer exist, or change its signature or semantics. This CL adds a mechanism to enforce the integrity of linknames. Generally, "push" linkname is allowed, as the package defining the symbol explicitly opt in for access outside of the package. "Pull" linkname is checked and only allowed in some circumstances. Given that there are existing code that use "pull"-only linkname to access other package's internals, disallowing it completely is too much a change at this point in the release cycle. For a start, implement a hard-coded blocklist, which contains some newly added internal functions that, if used inappropriately, may break memory safety or runtime integrity. All blocked symbols are newly added in Go 1.23. So existing code that builds with Go 1.22 will continue to build. For the implementation, when compiling a package, we mark linknamed symbols in the current package with an attribute. At link time, marked linknamed symbols are checked against the blocklist. Care is taken so it distinguishes a linkname reference in the current package vs. a reference of a linkname from another package and propagated to the current package (e.g. through inlining or instantiation). Symbol references in assembly code are similar to linknames, and are treated similarly. Change-Id: I8067efe29c122740cd4f1effd2dec2d839147d5d Reviewed-on: https://go-review.googlesource.com/c/go/+/584598 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2024-02-21cmd/asm, cmd/internal/obj: enable rounding mode suffix for riscv64Meng Zhuo
This CL adds rounding modes for riscv64 floating point conversion instructions by suffix with 5 modes: RNE, RTZ, RDN, RUP and RMM. For example, for round to nearest (RNE), we can use `FCVTLD.RNE` According to RISCV manual 8.7 and 9.5, we changed these conversion instructions: FCVTWS FCVTLS FCVTWUS FCVTLUS FCVTWD FCVTLD FCVTWUD FCVTLUD Note: Round towards zero (RTZ) by default for all these instructions above. Change-Id: I491e522e14d721e24aa7f528ee0c4640c54c5808 Reviewed-on: https://go-review.googlesource.com/c/go/+/504736 Reviewed-by: Joel Sing <joel@sing.id.au> Run-TryBot: M Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2023-08-29cmd/internal/obj: add Func type to replace "curfn any"Matthew Dempsky
This adds a modicum of type safety to these APIs, which are otherwise quite confusing to follow. Change-Id: I268a9a1a99a47dcfef6dc1e9e5be13673af3fb85 Reviewed-on: https://go-review.googlesource.com/c/go/+/523396 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com>
2023-05-24cmd/asm: refine some APIs related to Prog.RestArgs[]ruinan
Before this CL, we use GetFrom3&SetFrom3 to get or set a source operand which not fit into Prog.Reg. Those APIs operate the first element in Prog.RestArgs without checking the type so they're fragile to break if we have more than one different type of operands in the slice, which will be a common case in Arm64. This CL deprecates & renames some APIs related to Prog.RestArgs to make those APIs more reasonable and robust than before. Change-Id: I70d56edc1f23ccfffbcd6df34844e2cef2288432 Reviewed-on: https://go-review.googlesource.com/c/go/+/493355 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Eric Fang <eric.fang@arm.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Eric Fang <eric.fang@arm.com>
2023-05-19cmd/compile: constant-fold loads from constant dictionaries and typesKeith Randall
Retrying the original CL with a small modification. The original CL did not handle the case of reading an itab out of a dictionary correctly. When we read an itab out of a dictionary, we must treat the type inside that itab as maybe being put in an interface. Original CL: 486895 Revert CL: 490156 Change-Id: Id2dc1699d184cd8c63dac83986a70b60b4e6cbd7 Reviewed-on: https://go-review.googlesource.com/c/go/+/491495 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-05-02cmd/link, cmd/internal/obj: use aux symbol for global variable DWARF infoCherry Mui
Currently, for a global variable, its debug info symbol is a named symbol with the variable's name with a special prefix. And the linker looks it up by name. This CL makes the debug info symbol an aux symbol of the variable symbol. Change-Id: I55614d0ef2af9c53eb40144ad80e09339bf3cbee Reviewed-on: https://go-review.googlesource.com/c/go/+/490816 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2023-04-28Revert "cmd/compile: constant-fold loads from constant dictionaries and types"Chressie Himpel
This reverts CL 486895. Reason for revert: This breaks internal tests at Google, see b/280035614. Change-Id: I48772a44f5f6070a7f06b5704e9f9aa272b5f978 Reviewed-on: https://go-review.googlesource.com/c/go/+/490156 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Stapelberg <stapelberg@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Michael Stapelberg <stapelberg@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-04-27cmd/compile: constant-fold loads from constant dictionaries and typesKeith Randall
Update #59591 Change-Id: Id250a7779c5b53776fff73f3e678fec54d92a8e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/486895 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-04-21internal/abi, runtime, cmd: merge funcFlag_* consts into internal/abiAustin Clements
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>
2023-04-21internal/abi, runtime, cmd: merge funcID_* consts into internal/abiAustin Clements
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>
2023-04-05cmd/internal/obj: generate SEH aux symbols for windows/amd64qmuntal
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>
2023-03-02all: implement wasmimport directiveEvan Phoenix
Go programs can now use the //go:wasmimport module_name function_name directive to import functions from the WebAssembly runtime. For now, the directive is restricted to the runtime and syscall/js packages. * Derived from CL 350737 * Original work modified to work with changes to the IR conversion code. * Modification of CL 350737 changes to fully exist in Unified IR path (emp) * Original work modified to work with changes to the ABI configuration code. * Fixes #38248 Co-authored-by: Vedant Roy <vroy101@gmail.com> Co-authored-by: Richard Musiol <mail@richard-musiol.de> Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Change-Id: I740719735d91c306ac718a435a78e1ee9686bc16 Reviewed-on: https://go-review.googlesource.com/c/go/+/463018 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
2023-02-06cmd/internal/obj: flag init functions in object fileThan McIntosh
Introduce a flag in the object file indicating whether a given function corresponds to a compiler-generated (not user-written) init function, such as "os.init" or "syscall.init". Add code to the compiler to fill in the correct value for the flag, and add support to the loader package in the linker for testing the flag. The new loader API is currently unused, but will be needed in the next CL in this stack. Updates #2559. Updates #36021. Updates #14840. Change-Id: Iea7ad2adda487e4af7a44f062f9817977c53b394 Reviewed-on: https://go-review.googlesource.com/c/go/+/463855 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-01-30cmd/compile,cmd/link: set DW_AT_decl_line for function declarationsMichael Pratt
DW_AT_decl_line provides the line number of function declarations (the line containing the func keyword). This is the equivalent to CL 429638, but provided via DWARF. Note that the file of declarations (DW_AT_decl_file) is already provided for non-inlined functions. It is omitted for inlined functions because those DWARF subprograms may be generated outside of their source compilation unit, where referencing the file table is difficult. Fixes #57308. Change-Id: I3ad12e1f366c4465c2a588297988a5825ef7efec Reviewed-on: https://go-review.googlesource.com/c/go/+/458195 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2022-11-11all: fix problematic commentscui fliter
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>
2022-10-14cmd/compile,cmd/link,runtime: add start line numbers to func metadataMichael Pratt
This adds the function "start line number" to runtime._func and runtime.inlinedCall objects. The "start line number" is the line number of the func keyword or TEXT directive for assembly. Subtracting the start line number from PC line number provides the relative line offset of a PC from the the start of the function. This helps with source stability by allowing code above the function to move without invalidating samples within the function. Encoding start line rather than relative lines directly is convenient because the pprof format already contains a start line field. This CL uses a straightforward encoding of explictly including a start line field in every _func and inlinedCall. It is possible that we could compress this further in the future. e.g., functions with a prologue usually have <line of PC 0> == <start line>. In runtime.test, 95% of functions have <line of PC 0> == <start line>. According to bent, this is geomean +0.83% binary size vs master and -0.31% binary size vs 1.19. Note that //line directives can change the file and line numbers arbitrarily. The encoded start line is as adjusted by //line directives. Since this can change in the middle of a function, `line - start line` offset calculations may not be meaningful if //line directives are in use. For #55022. Change-Id: Iaabbc6dd4f85ffdda294266ef982ae838cc692f6 Reviewed-on: https://go-review.googlesource.com/c/go/+/429638 Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2022-05-16cmd/compile: set LocalPkg.Path to -p flagMatthew Dempsky
Since CL 391014, cmd/compile now requires the -p flag to be set the build system. This CL changes it to initialize LocalPkg.Path to the provided path, rather than relying on writing out `"".` into object files and expecting cmd/link to substitute them. However, this actually involved a rather long tail of fixes. Many have already been submitted, but a few notable ones that have to land simultaneously with changing LocalPkg: 1. When compiling package runtime, there are really two "runtime" packages: types.LocalPkg (the source package itself) and ir.Pkgs.Runtime (the compiler's internal representation, for synthetic references). Previously, these ended up creating separate link symbols (`"".xxx` and `runtime.xxx`, respectively), but now they both end up as `runtime.xxx`, which causes lsym collisions (notably inittask and funcsyms). 2. test/codegen tests need to be updated to expect symbols to be named `command-line-arguments.xxx` rather than `"".foo`. 3. The issue20014 test case is sensitive to the sort order of field tracking symbols. In particular, the local package now sorts to its natural place in the list, rather than to the front. Thanks to David Chase for helping track down all of the fixes needed for this CL. Updates #51734. Change-Id: Iba3041cf7ad967d18c6e17922fa06ba11798b565 Reviewed-on: https://go-review.googlesource.com/c/go/+/393715 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-05-11cmd/internal/obj: add a flag to not write referenced symbol names in object fileCherry Mui
The Go object file references (some of) symbols from other packages by indices, not by names. The linker doesn't need the symbol names to do the linking. The names are included in the object file so it is self-contained and tools (objdump, nm) can read the referenced symbol names. Including the names increases object file size. Add a flag to disable it on demand (off by default). Change-Id: I143a0eb656997497c750b8eb1541341b2aee8f30 Reviewed-on: https://go-review.googlesource.com/c/go/+/404297 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-05-11cmd/internal/obj{,/loong64}: instructions and registers for loong64Xiaodong Liu
Implemented an assembler for LoongArch64(loong64 is short name) - this provides register definitions and instruction encoding as defined in the LoongArch Instruction Set Manual. LoongArch Instruction Set Manual: https://github.com/loongson/LoongArch-Documentation/releases Contributors to the linux/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: I930d2a19246496e3ca36d55539183c0f9f650ad9 Reviewed-on: https://go-review.googlesource.com/c/go/+/342309 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
2022-04-19cmd/compile,cmd/internal/obj: replace Ctxt.FixedFrameSize method with Arch fieldAustin Clements
And delete now-unused FixedFrameSize methods. Change-Id: Id257e1647dbeb4eb4ab866c53744010c4efeb953 Reviewed-on: https://go-review.googlesource.com/c/go/+/400819 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-19internal/sys: add LR and fixed frame size to sys.ArchAustin Clements
Storing this information in the Arch eliminates some code duplication between the compiler and linker. This information is entirely determined by the Arch, so the current approach of attaching it to an entire Ctxt is a little silly. This will also make it easier to use this information from tests. The next CL will be a rote refactoring to eliminate the Ctxt.FixedFrameSize methods. Change-Id: I315c524fa66a0ea99f63ae5a2a6fdc367d843bad Reviewed-on: https://go-review.googlesource.com/c/go/+/400818 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-14cmd/compile: implement jump tablesKeith Randall
Performance is kind of hard to exactly quantify. One big difference between jump tables and the old binary search scheme is that there's only 1 branch statement instead of O(n) of them. That can be both a blessing and a curse, and can make evaluating jump tables very hard to do. The single branch can become a choke point for the hardware branch predictor. A branch table jump must fit all of its state in a single branch predictor entry (technically, a branch target predictor entry). With binary search that predictor state can be spread among lots of entries. In cases where the case selection is repetitive and thus predictable, binary search can perform better. The big win for a jump table is that it doesn't consume so much of the branch predictor's resources. But that benefit is essentially never observed in microbenchmarks, because the branch predictor can easily keep state for all the binary search branches in a microbenchmark. So that benefit is really hard to measure. So predictable switch microbenchmarks are ~useless - they will almost always favor the binary search scheme. Fully unpredictable switch microbenchmarks are better, as they aren't lying to us quite so much. In a perfectly unpredictable situation, a jump table will expect to incur 1-1/N branch mispredicts, where a binary search would incur lg(N)/2 of them. That makes the crossover point at about N=4. But of course switches in real programs are seldom fully unpredictable, so we'll use a higher crossover point. Beyond the branch predictor, jump tables tend to execute more instructions per switch but have no additional instructions per case, which also argues for a larger crossover. As far as code size goes, with this CL cmd/go has a slightly smaller code segment and a slightly larger overall size (from the jump tables themselves which live in the data segment). This is a case where some FDO (feedback-directed optimization) would be really nice to have. #28262 Some large-program benchmarks might help make the case for this CL. Especially if we can turn on branch mispredict counters so we can see how much using jump tables can free up branch prediction resources that can be gainfully used elsewhere in the program. name old time/op new time/op delta Switch8Predictable 1.89ns ± 2% 1.27ns ± 3% -32.58% (p=0.000 n=9+10) Switch8Unpredictable 9.33ns ± 1% 7.50ns ± 1% -19.60% (p=0.000 n=10+9) Switch32Predictable 2.20ns ± 2% 1.64ns ± 1% -25.39% (p=0.000 n=10+9) Switch32Unpredictable 10.0ns ± 2% 7.6ns ± 2% -24.04% (p=0.000 n=10+10) Fixes #5496 Update #34381 Change-Id: I3ff56011d02be53f605ca5fd3fb96b905517c34f Reviewed-on: https://go-review.googlesource.com/c/go/+/357330 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>
2022-04-01cmd/asm: refactor some operands that are not special registers on arm64erifan01
The previous code treats some operands such as EQ, LT, etc. as special registers. However, they are not. This CL adds a new AddrType TYPE_SPOPD and a new class C_SPOPD to support this kind of special operands, and refactors the relevant code. This patch is a copy of CL 260861, contributed by Junchen Li(junchen.li@arm.com). Co-authored-by: Junchen Li(junchen.li@arm.com) Change-Id: I57b28da458ee3332f610602632e7eda03af435f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/302849 Reviewed-by: Cherry Mui <cherryyz@google.com> Trust: Eric Fang <eric.fang@arm.com> Run-TryBot: Eric Fang <eric.fang@arm.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-02-11cmd/compile, runtime: use unwrapped PC for goroutine creation tracingCherry Mui
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>
2021-11-05cmd/{asm,compile,internal/obj}: add "maymorestack" supportAustin Clements
This adds a debugging hook for optionally calling a "maymorestack" function in the prologue of any function that might call morestack (whether it does at run time or not). The maymorestack function will let us improve lock checking and add debugging modes that stress function preemption and stack growth. Passes toolstash-check -all (except on js/wasm, where toolstash appears to be broken) Fixes #48297. Change-Id: I27197947482b329af75dafb9971fc0d3a52eaf31 Reviewed-on: https://go-review.googlesource.com/c/go/+/359795 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-10-27cmd/compile, runtime: track argument stack slot livenessCherry Mui
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>
2021-09-29cmd/internal/goobj, cmd/link: remove funcdataoffCherry Mui
FUNCDATA is always a symbol reference with 0 offset. Assert the offset is 0 and remove funcdataoff. Change-Id: I326815365c9db5aeef6b869df5d78a9957bc16a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/352894 Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2021-09-28cmd/internal/obj: index pcdata symbols in NumberSymsCherry Mui
When writing an object file, most symbols are indexed in NumberSyms. Currently, pcdata symbols are indexed late and separately. This is not really necessary, as pcdata symbols already exist at the time of NumberSyms. Just do it there. As pcdata symbols are laid out in the pclntab in a special way at link time, distinguish them from other symbols in the content hash. (In the old code this was partly achieved by indexing them late.) Change-Id: Ie9e721382b0af2cfb39350d031e2e66d79095a3c Reviewed-on: https://go-review.googlesource.com/c/go/+/352611 Trust: Cherry Mui <cherryyz@google.com> Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2021-09-27cmd/internal/obj: fix wording in a commentDQNEO
Change-Id: I9921ba5c29ada6ff06d147f6d9b46a29101c449c Reviewed-on: https://go-review.googlesource.com/c/go/+/350694 Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: David Chase <drchase@google.com>
2021-09-22cmd/internal/obj: remove ABI aliases from object fileCherry Mui
Change-Id: I8a51f054e017e0116dee4e435b60c08d72e998e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/351331 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>
2021-04-22cmd/compile, runtime: add metadata for argument printing in tracebackCherry Zhang
Currently, when the runtime printing a stack track (at panic, or when runtime.Stack is called), it prints the function arguments as words in memory. With a register-based calling convention, the layout of argument area of the memory changes, so the printing also needs to change. In particular, the memory order and the syntax order of the arguments may differ. To address that, this CL lets the compiler to emit some metadata about the memory layout of the arguments, and the runtime will use this information to print arguments in syntax order. Previously we print the memory contents of the results along with the arguments. The results are likely uninitialized when the traceback is taken, so that information is rarely useful. Also, with a register-based calling convention the results may not have corresponding locations in memory. This CL changes it to not print results. Previously the runtime simply prints the memory contents as pointer-sized words. With a register-based calling convention, as the layout changes, arguments that were packed in one word may no longer be in one word. Also, as the spill slots are not always initialized, it is possible that some part of a word contains useful informationwhile the rest contains garbage. Instead of letting the runtime recreating the ABI0 layout and print them as words, we now print each component separately. Aggregate-typed argument/component is surrounded by "{}". For example, for a function F(int, [3]byte, byte) int when called as F(1, [3]byte{2, 3, 4}, 5), it used to print F(0x1, 0x5040302, 0xXXXXXXXX) // assuming little endian, 0xXXXXXXXX is uninitilized result Now prints F(0x1, {0x2, 0x3, 0x4}, 0x5). Note: the liveness tracking of the spill splots has not been implemented in this CL. Currently the runtime just assumes all the slots are live and print them all. Increase binary sizes by ~1.5%. old new hello (println) 1171328 1187712 (+1.4%) hello (fmt) 1877024 1901600 (+1.3%) cmd/compile 22326928 22662800 (+1.5%) cmd/go 13505024 13726208 (+1.6%) Updates #40724. Change-Id: I351e0bf497f99bdbb3f91df2fb17e3c2c5c316dc Reviewed-on: https://go-review.googlesource.com/c/go/+/304470 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 19:52:07 +0000