aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/internal/obj/objfile.go
AgeCommit message (Collapse)Author
2025-02-13cmd: use cmd/internal/hash.New32 and Sum32 onlyRuss Cox
Do not use New16, New20, Sum16, Sum20 anymore. As of CL 641096, these are just wrappers around New32 and Sum32. Change call sites to use them directly. Change-Id: Icea91a77449f6839b903894997057ba404bd04e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/641076 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> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2024-11-07cmd/internal/objabi, cmd/link: introduce SymKind helper methodsRuss Cox
These will be necessary when we start using the new FIPS symbols. Split into a separate CL so that these refactoring changes can be tested separate from any FIPS-specific changes. Passes golang.org/x/tools/cmd/toolstash/buildall. Change-Id: I73e5873fcb677f1f572f0668b4dc6f3951d822bc Reviewed-on: https://go-review.googlesource.com/c/go/+/625996 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Russ Cox <rsc@golang.org>
2024-09-04cmd: use 20 bytes hash when possibleCuong Manh Le
CL 402595 changes all usages of 20 bytes hash to 32 bytes hash by using notsha256. However, since CL 454836, notsha256 is not necessary anymore, so this CL reverts those changes to 20 bytes hash using cmd/internal/hash package. Updates #51940 Updates #64751 Change-Id: Icb08d5a0d8032a3c4d050ff7b2298d31c483b88b Reviewed-on: https://go-review.googlesource.com/c/go/+/610597 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-09-04cmd: do not use notsha256Cuong Manh Le
CL 402595 used notsha256 to prevent the compiler from depending on cgo-based implementations of sha1 and sha256. However, since CL 454836, cmd is built with CGO_ENABLED=0, which will disable boringcrypto. Thus all usages of notsha256 is not necessary anymore. Updates #51940 Updates #64751 Change-Id: I503090f7a2efb5723e8a79523b143dc7cdb4edd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/610596 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-09-03cmd: replace many sort.Interface with slices.Sort and SortFuncZxilly
with slices there's no need to implement sort.Interface Change-Id: I59167e78881cb1df89a71e33d738d6aeca7adb71 GitHub-Last-Rev: 507ba84453f7305b6b2bf6317292111c00c93ffe GitHub-Pull-Request: golang/go#68724 Reviewed-on: https://go-review.googlesource.com/c/go/+/602895 Reviewed-by: Ian Lance Taylor <iant@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@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/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-15cmd/internal/obj: print symbol index at -S=3Cherry Mui
When the compiler or assembler's -S flag is set to 3 or higher, print the symbol index, for debugging. Change-Id: Ia7a42b0c017105ef12fd97b3e52de0e155b0cf2e Reviewed-on: https://go-review.googlesource.com/c/go/+/585655 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.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>
2023-08-29cmd/internal/{dwarf,obj}: stop substituting "" with pkgprefixMatthew Dempsky
cmd/asm and cmd/compile now always create symbols with the appropriate package prefixes, so cmd/internal/dwarf and cmd/internal/obj can stop worrying about qualifying names itself. Change-Id: I9aee5d759bf0d41a61722c777e7f66fce957e79e Reviewed-on: https://go-review.googlesource.com/c/go/+/523338 Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-07-20cmd/internal/obj: print relocation type by name in -S outputCherry Mui
The compiler/assembler's -S output prints relocation type numerically, which is hard to understand. Every time I need to count the relocation type constants to figure out which relocation it actually is. Print the symbolic name instead. Change-Id: I4866873bbae8b3dc0ee212609cb00280f9164243 Reviewed-on: https://go-review.googlesource.com/c/go/+/501856 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com>
2023-07-18all: fix typosJes Cok
Change-Id: I510b0a4bf3472d937393800dd57472c30beef329 GitHub-Last-Rev: 8d289b73a37bd86080936423d981d21e152aaa33 GitHub-Pull-Request: golang/go#60960 Reviewed-on: https://go-review.googlesource.com/c/go/+/505398 Auto-Submit: Robert Findley <rfindley@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
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-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-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-20all: fix typos in go file commentsMarcel Meyer
This is the second round to look for spelling mistakes. This time the manual sifting of the result list was made easier by filtering out capitalized and camelcase words. grep -r --include '*.go' -E '^// .*$' . | aspell list | grep -E -x '[A-Za-z]{1}[a-z]*' | sort | uniq This PR will be imported into Gerrit with the title and first comment (this text) used to generate the subject and body of the Gerrit change. Change-Id: Ie8a2092aaa7e1f051aa90f03dbaf2b9aaf5664a9 GitHub-Last-Rev: fc2bd6e0c51652f13a7588980f1408af8e6080f5 GitHub-Pull-Request: golang/go#57737 Reviewed-on: https://go-review.googlesource.com/c/go/+/461595 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> Reviewed-by: Robert Griesemer <gri@google.com>
2022-11-10cmd/internal/obj: reduce allocations in object file writingCherry Mui
Some object file writer functions are structured like, having a local variable, setting fields, then passing it to a Write method which eventually calls io.Writer.Write. As the Write call is an interface call it escapes the parameter, which in turn causes the local variable to be heap allocated. To reduce allocation, use pre-allocated scratch space instead. Reduce number of allocations in the compiler: name old allocs/op new allocs/op delta Template 679k ± 0% 644k ± 0% -5.17% (p=0.000 n=20+20) Unicode 603k ± 0% 581k ± 0% -3.67% (p=0.000 n=20+20) GoTypes 3.83M ± 0% 3.63M ± 0% -5.30% (p=0.000 n=20+20) Compiler 353k ± 0% 342k ± 0% -3.09% (p=0.000 n=18+19) SSA 31.4M ± 0% 30.4M ± 0% -3.02% (p=0.000 n=20+20) Flate 397k ± 0% 373k ± 0% -5.92% (p=0.000 n=20+18) GoParser 777k ± 0% 735k ± 0% -5.37% (p=0.000 n=20+20) Reflect 2.07M ± 0% 1.90M ± 0% -7.89% (p=0.000 n=18+20) Tar 605k ± 0% 568k ± 0% -6.26% (p=0.000 n=19+16) XML 801k ± 0% 766k ± 0% -4.36% (p=0.000 n=20+20) [Geo mean] 1.18M 1.12M -5.02% Change-Id: I9d02a72e459e645527196ac54b6ee643a5ea6bd3 Reviewed-on: https://go-review.googlesource.com/c/go/+/449637 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com>
2022-10-31cmd/internal/obj: cleanup linkgetlineFromPosMichael Pratt
Make linkgetlineFromPos and getFileIndexAndLine methods on Link, and give the former a more descriptive name. The docs are expanded to make it more clear that these are final file/line visible in programs. In getFileSymbolAndLine use ctxt.InnermostPos instead of ctxt.PosTable direct, which makes it more clear that we want the semantics of InnermostPos. Change-Id: I7c3d344dec60407fa54b191be8a09c117cb87dd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/446301 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
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-08-16runtime: process ptr bitmaps one word at a timeKeith Randall
[This is a retry of CL 407036 + its revert CL 422394. The only content change is the 1-line change in cmd/internal/obj/objfile.go.] Read the bitmaps one uintptr at a time instead of one byte at a time. Performance so far: Allocation heavy, no retention: ~30% faster in heapBitsSetType Scan heavy, ~no allocation: ~even in scanobject Change-Id: I04d899e1dbd23e989e9f552cdc1880318779c14c Reviewed-on: https://go-review.googlesource.com/c/go/+/422635 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-08-15cmd/internal/obj: remove redundant code in genFuncInfoSymsxiongwy12
The length of slice hashedsyms is always 0, because it's not used after defined Change-Id: Iba8e263aedfa403d5688678a1b37c2be3119eb7f GitHub-Last-Rev: c236c4a48268ef1cdd9daa1e62c7004a7bde1d27 GitHub-Pull-Request: golang/go#53450 Reviewed-on: https://go-review.googlesource.com/c/go/+/413234 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: guangyuan zhou <zhouguangyuan@golangcn.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com>
2022-08-09all: use ":" for compiler generated symbolsCuong Manh Le
As it can't appear in user package paths. There is a hack for handling "go:buildid" and "type:*" on windows/386. Previously, windows/386 requires underscore prefix on external symbols, but that's only applied for SHOSTOBJ/SUNDEFEXT or cgo export symbols. "go.buildid" is STEXT, "type.*" is STYPE, thus they are not prefixed with underscore. In external linking mode, the external linker can't resolve them as external symbols. But we are lucky that they have "." in their name, so the external linker see them as Forwarder RVA exports. See: - https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#export-address-table - https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/pe-dll.c;h=e7b82ba6ffadf74dc1b9ee71dc13d48336941e51;hb=HEAD#l972) This CL changes "." to ":" in symbols name, so theses symbols can not be found by external linker anymore. So a hacky way is adding the underscore prefix for these 2 symbols. I don't have enough knowledge to verify whether adding the underscore for all STEXT/STYPE symbols are fine, even if it could be, that would be done in future CL. Fixes #37762 Change-Id: I92eaaf24c0820926a36e0530fdb07b07af1fcc35 Reviewed-on: https://go-review.googlesource.com/c/go/+/317917 Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-05-11cmd/asm: require -p flagCherry Mui
CL 391014 requires the compiler to be invoked with the -p flag, to specify the package path. Later, CL 394217 makes the compiler to produce an unlinkable object file, so "go tool compile x.go" can still be used on the command line. This CL does the same for the assembler, requiring -p, otherwise generating an unlinkable object. No special case for the main package, as the main package cannot be only assembly code, and there is no way to tell if it is the main package from an assembly file. Now we guarantee that we always have an expanded package path in the object file. A later CL will delete the name expansion code in the linker. Change-Id: I8c10661aaea2ff794614924ead958d80e7e2487d Reviewed-on: https://go-review.googlesource.com/c/go/+/404298 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.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-04-29[dev.boringcrypto] cmd: use notsha256 instead of md5, sha1, sha256Russ Cox
When we add GOEXPERIMENT=boringcrypto, the bootstrap process will not converge if the compiler itself depends on the boringcrypto cgo-based implementations of sha1 and sha256. Using notsha256 avoids boringcrypto and makes bootstrap converge. Removing md5 is not strictly necessary but it seemed worthwhile to be consistent. For #51940. Change-Id: Iba649507e0964d1a49a1d16e463dd23c4e348f14 Reviewed-on: https://go-review.googlesource.com/c/go/+/402595 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-25cmd/compile: fix the missing size for FuncInfoSymzhouguangyuan
Change-Id: I46543e188bf25384e529a9d5a3095033ac618bbd Reviewed-on: https://go-review.googlesource.com/c/go/+/402057 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2022-04-11all: gofmt main repoRuss Cox
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2022-04-01all: fix various doc comment formatting nitsRuss Cox
A run of lines that are indented with any number of spaces or tabs format as a <pre> block. This commit fixes various doc comments that format badly according to that (standard) rule. For example, consider: // - List item. // Second line. // - Another item. Because the - lines are unindented, this is actually two paragraphs separated by a one-line <pre> block. This CL rewrites it to: // - List item. // Second line. // - Another item. Today, that will format as a single <pre> block. In a future release, we hope to format it as a bulleted list. Various other minor fixes as well, all in preparation for reformatting. For #51082. Change-Id: I95cf06040d4186830e571cd50148be3bf8daf189 Reviewed-on: https://go-review.googlesource.com/c/go/+/384257 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>
2022-03-28cmd/internal/obj: sort relocationsCherry Mui
At least on some platforms (e.g. PE dynamic loader) relocations need to be sorted in address order. Currently we don't always emit relocations in address order: e.g. for array literal with out-of- order element initializers, or out-of-order DATA instructions in assembly code. Sort them. No test for now as I can't reproduce the failure for #51923. Fixes #51923. Change-Id: Ifec5d3476e027bb927bcefd6e45c40ebeccee4ba Reviewed-on: https://go-review.googlesource.com/c/go/+/396195 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2022-03-22cmd/compile, cmd/link: produce unlinkable object when compile without -pCherry Mui
CL 391014 requires the compiler to be invoked with the -p flag, to specify the package path. People are used to run "go tool compile" from the command line with the -p flag. This is mostly for simple testing, or debugging the compiler. The produced object file is almost never intended to be linked. This CL makes the compiler allow "go tool compile" without the -p flag again. It will produce an unlinkable object. If the linker sees such an object it will error out. Change-Id: I7bdb162c3cad61dadd5c456d903b92493a3df20f Reviewed-on: https://go-review.googlesource.com/c/go/+/394217 Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cherry Mui <cherryyz@google.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-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-10-12cmd/internal/obj/ppc64: support alignment of prefixed insnPaul E. Murphy
Insert machine NOPs when a prefixed instruction crosses a 64B boundary. ISA 3.1 prohibits prefixed instructions being placed across them. Such instructions generate SIGILL if executed. Likewise, adjust the function alignment to guarantee such instructions can never cross one. And, don't pad the PC based on alignment. The linker can fit these more optimally. Likewise, include the function alignment when printing function debug information. This is needed to verify function alignment happens. Updates #44549 Change-Id: I434fb0ee4e984ca00dc4566f7569c3bcdf93f910 Reviewed-on: https://go-review.googlesource.com/c/go/+/347050 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
2021-10-06cmd/internal/obj: allow more gcbits content addressabilityJosh Bleecher Snyder
Follow-up to feedback on CL 352189. Change-Id: I3d9fa87878a74a5a725812c7852050c02c433fa3 Reviewed-on: https://go-review.googlesource.com/c/go/+/354137 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>
2021-10-05cmd/link: move all FUNCDATA refs into go.func.*Josh Bleecher Snyder
This change moves all symbols referred to by FUNCDATA into go.func.* and go.funcrel.*. Surprisingly (because it inhibits some content-addressability), it shrinks binaries by a little bit, about 0.1%. This paves the way for a subsequent change to change FUNCDATA relocations to offsets. Change-Id: I70e487205073699f442192b0791cc92da5663057 Reviewed-on: https://go-review.googlesource.com/c/go/+/352189 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>
2021-10-04cmd/internal/obj: reduce alignment for gcbitsCherry Mui
runtime.gcbits symbols are pointer masks, which are just bytes. Change-Id: I6e86359451c7da69da435e1928e55712dd904047 Reviewed-on: https://go-review.googlesource.com/c/go/+/353571 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-10-04cmd/internal/obj, cmd/link: move symbol alignment logic to object file writerCherry Mui
Change-Id: I827a9702dfa01b712b88331668434f8db94df249 Reviewed-on: https://go-review.googlesource.com/c/go/+/353569 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-10-04cmd, runtime: mark assembly routines in FuncFlagsJosh Bleecher Snyder
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>
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-29cmd/link: access pcdata via aux symbolsCherry Mui
Pcdata are now separate aux symbols. Read them from aux, instead of using funcinfo. Now we can remove pcdata fields from funcinfo. Change-Id: Ie65e3962edecc0f39127a5f6963dc59d1f141e67 Reviewed-on: https://go-review.googlesource.com/c/go/+/352893 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-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-28cmd/internal/obj: refactor code to separate content-addressable symbols by ↵Josh Bleecher Snyder
section The goal of this change is to improve the documentation and make it easier to keep Link.NumberSyms and writer.contentHash aligned. No functional changes. A subsequent change will add conditions to contentHashSection. Change-Id: I0a274f6974459d34d5a8553081f33ea4cd87f248 Reviewed-on: https://go-review.googlesource.com/c/go/+/352669 Trust: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-09-28cmd/internal/goobj: remove Pcdata from object fileCherry Mui
As of CL 247399 we use separate symbols for PCDATA. There is no more need for writing PCDATA directly into the object file as a separate block. Change-Id: I942d1a372540415e0cc07fb2a01f79718a264142 Reviewed-on: https://go-review.googlesource.com/c/go/+/352610 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-22cmd/compile: break out constants for local and global dictionary prefixesDan Scales
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>
2021-09-20cmd/link: generate DIE for types referenced only through dictionariesAlessandro Arzilli
Generate debug_info entries for types that are only referenced through dictionaries. Change-Id: Ic36c2e6d9588ec6746793bb213c2dc0e17a8a850 Reviewed-on: https://go-review.googlesource.com/c/go/+/350532 Run-TryBot: Alessandro Arzilli <alessandro.arzilli@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Trust: Dan Scales <danscales@google.com> Trust: David Chase <drchase@google.com>
2021-07-21[dev.typeparams] cmd/compile: introduce named gcshape typesKeith Randall
Still 1-1 with real types, but now with their own names! Shape types are implicitly convertible to (and convertible from) the types they represent. Change-Id: I0133a8d8fbeb369380574b075a32b3c987e314d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/335170 Run-TryBot: Keith Randall <khr@golang.org> Trust: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 12:18:16 +0000