Same information is provided from the fields of the embedded
goobj.Reader, and are accessed through it. Delete the flags field.
Change-Id: I7a4f5dca054e567443d719b2931fceff231d6efc
Reviewed-on: https://go-review.googlesource.com/c/go/+/394216
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>
Also change the relevant test to be tested on the linux-arm64 platform
as well.
Fixes#49789
Change-Id: Id2eac7a45279f037957442862f8ed63838b8e929
Reviewed-on: https://go-review.googlesource.com/c/go/+/366855
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The ELF compression header(Chdr) has Addralign field that is set to the
alignment of the uncompressed section which makes section able to have
a different alignment than the decompressed section. However `file` and
other tools require both Chdr.Addralign and Addralign to be equal.
Ref https://sourceware.org/bugzilla/show_bug.cgi?id=23919
Related #42136Fixes#51769
Change-Id: I3cf99dbd2359932576420a3c0d342c7e91b99227
Reviewed-on: https://go-review.googlesource.com/c/go/+/393916
Trust: mzh <mzh@golangcn.org>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Fangrui Song <maskray@google.com>
This fixes many (but not all) of the tests that currently fail
(due to a bogus path reported by runtime.GOROOT) when run with
'go test -trimpath std cmd'.
Updates #51461
Change-Id: Ia2cc05705529c4859e7928f32eeceed647f2e986
Reviewed-on: https://go-review.googlesource.com/c/go/+/391806
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously, runtime.GOROOT() would return the string "go" in a binary
build with -trimpath. This change stamps the empty string instead,
using a sentinel value passed from cmd/go that looks like the GOROOT
environment variable (either "$GOROOT" or "%GOROOT%", depending on the
platform).
Fixes#51461
Change-Id: I1f10ef2435016a7b6213bd8c547df911f7feeae7
Reviewed-on: https://go-review.googlesource.com/c/go/+/390024
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the beginning the Go compiler was in C, and C had a function
'getgoroot' that returned GOROOT from either the environment or a
generated constant. 'getgoroot' was mechanically converted to Go
(as obj.Getgoroot) in CL 3046.
obj.Getgoroot begat obj.GOROOT. obj.GOROOT begat objabi.GOROOT,
which begat buildcfg.GOROOT.
As far as I can tell, today's buildcfg.GOROOT is functionally
identical to runtime.GOROOT(). Let's reduce some complexity by
defining it in those terms.
While we're thinking about buildcfg.GOROOT, also check whether it is
non-empty: if the toolchain is built with -trimpath, the value of
GOROOT might not be valid or meaningful if the user invokes
cmd/compile or cmd/link directly, or via a build tool other than
cmd/go that doesn't care as much about GOROOT. (As of CL 390024,
runtime.GOROOT will return the empty string instead of a bogus one
when built with -trimpath.)
For #51461.
Change-Id: I9fec020d5fa65d4aff0dd39b805f5ca93f86c36e
Reviewed-on: https://go-review.googlesource.com/c/go/+/393155
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/go/internal/cfg duplicates many of the fields of
internal/buildcfg, but initializes them from a Go environment file in
addition to the usual process environment.
internal/buildcfg doesn't (and shouldn't) know or care about that
environment file, but prior to this CL it exposed hooks for
cmd/go/internal/cfg to write data back to internal/buildcfg to
incorporate information from the file. It also produced quirky
GOEXPERIMENT strings when a non-trivial default was overridden,
seemingly so that 'go env' would produce those same quirky strings in
edge-cases where they are needed.
This change reverses that information flow: internal/buildcfg now
exports a structured type with methods — instead of top-level
functions communicating through global state — so that cmd/go can
utilize its marshaling and unmarshaling functionality without also
needing to write results back into buildcfg package state.
The quirks specific to 'go env' have been eliminated by distinguishing
between the raw GOEXPERIMENT value set by the user (which is what we
should report from 'go env') and the cleaned, canonical equivalent
(which is what we should use in the build cache key).
For #51461.
Change-Id: I4ef5b7c58b1fb3468497649a6d2fb6c19aa06c70
Reviewed-on: https://go-review.googlesource.com/c/go/+/393574
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When plugin is used, we already mark all exported methods
reachable. However, when the plugin and the host program share
a common package, an unexported method could also be reachable
from both the plugin and the host via interfaces. We need to mark
them as well.
Fixes#51621.
Change-Id: I1a70d3f96b66b803f2d0ab14d00ed0df276ea500
Reviewed-on: https://go-review.googlesource.com/c/go/+/393365
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>
The -p flag specifies the import path of the package being compiled.
This CL makes it required when invoking the compiler and
adjusts tests that invoke the compiler directly to conform to this
new requirement. The go command already passes the flag, so it
is unmodified in this CL. It is expected that any other Go build systems
also already pass -p, or else they will need to arrange to do so before
updating to Go 1.19. Of particular note, Bazel already does for rules
with an importpath= attribute, which includes all Gazelle-generated rules.
There is more cleanup possible now in cmd/compile, cmd/link,
and other consumers of Go object files, but that is left to future CLs.
Additional historical background follows but can be ignored.
Long ago, before the go command, or modules, or any kind of
versioning, symbols in Go archive files were named using just the
package name, so that for example func F in math/rand and func F in
crypto/rand would both be the object file symbol 'rand.F'. This led to
collisions even in small source trees, which made certain packages
unusable in the presence of other packages and generally was a problem
for Go's goal of scaling to very large source trees.
Fixing this problem required changing from package names to import
paths in symbol names, which was mostly straightforward. One wrinkle,
though, is that the compiler did not know the import path of the
package being compiled; it only knew the package name. At the time,
there was no go command, just Makefiles that people had invoking 6g
(now “go tool compile”) and then copying the resulting object file to
an importable location. That is, everyone had a custom build setup for
Go, because there was no standard one. So it was not particularly
attractive to change how the compiler was invoked, since that would
break approximately every Go user at the time. Instead, we arranged
for the compiler to emit, and other tools reading object files to
recognize, a special import path (the empty string, it turned out)
denoting “the import path of this object file”. This worked well
enough at the time and maintained complete command-line compatibility
with existing Go usage.
The changes implementing this transition can be found by searching
the Git history for “package global name space”, which is what they
eliminated. In particular, CL 190076 (a6736fa4), CL 186263 (758f2bc5),
CL 193080 (1cecac81), CL 194053 (19126320), and CL 194071 (531e6b77)
did the bulk of this transformation in January 2010.
Later, in September 2011, we added the -p flag to the compiler for
diagnostic purposes. The problem was that it was easy to create import
cycles, especially in tests, and these could not be diagnosed until
link time. You'd really want the compiler to diagnose these, for
example if the compilation of package sort noticed it was importing a
package that itself imported "sort". But the compilation of package
sort didn't know its own import path, and so it could not tell whether
it had found itself as a transitive dependency. Adding the -p flag
solved this problem, and its use was optional, since the linker would
still diagnose the import cycle in builds that had not updated to
start passing -p. This was CL 4972057 (1e480cd1).
There was still no go command at this point, but when we introduced
the go command we made it pass -p, which it has for many years at this
point.
Over time, parts of the compiler began to depend on the presence of
the -p flag for various reasonable purposes. For example:
In CL 6497074 (041fc8bf; Oct 2012), the race detector used -p to
detect packages that should not have race annotations, such as
runtime/race and sync/atomic.
In CL 13367052 (7276c02b; Sep 2013), a bug fix used -p to detect the
compilation of package reflect.
In CL 30539 (8aadcc55; Oct 2016), the compiler started using -p to
identify package math, to be able to intrinsify calls to Sqrt inside
that package.
In CL 61019 (9daee931; Sep 2017), CL 71430 (2c1d2e06; Oct 2017), and
later related CLs, the compiler started using the -p value when
creating various DWARF debugging information.
In CL 174657 (cc5eaf93; May 2019), the compiler started writing
symbols without the magic empty string whenever -p was used, to reduce
the amount of work required in the linker.
In CL 179861 (dde7c770; Jun 2019), the compiler made the second
argument to //go:linkname optional when -p is used, because in that
case the compiler can derive an appropriate default.
There are more examples. Today it is impossible to compile the Go
standard library without using -p, and DWARF debug information is
incomplete without using -p.
All known Go build systems pass -p. In particular, the go command
does, which is what nearly all Go developers invoke to build Go code.
And Bazel does, for go_library rules that set the importpath
attribute, which is all rules generated by Gazelle.
Gccgo has an equivalent of -p and has required its use in order to
disambiguate packages with the same name but different import paths
since 2010.
On top of all this, various parts of code generation for generics
are made more complicated by needing to cope with the case where -p
is not specified, even though it's essentially always specified.
In summary, the current state is:
- Use of the -p flag with cmd/compile is required for building
the standard library, and for complete DWARF information,
and to enable certain linker speedups.
- The go command and Bazel, which we expect account for just
about 100% of Go builds, both invoke cmd/compile with -p.
- The code in cmd/compile to support builds without -p is
complex and has become more complex with generics, but it is
almost always dead code and therefore not worth maintaining.
- Gccgo already requires its equivalent of -p in any build
where two packages have the same name.
All this supports the change in this CL, which makes -p required
and adjusts tests that invoke cmd/compile to add -p appropriately.
Future CLs will be able to remove all the code dealing with the
possibility of -p not having been specified.
Change-Id: I6b95b9d4cffe59c7bac82eb273ef6c4a67bb0e43
Reviewed-on: https://go-review.googlesource.com/c/go/+/391014
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
cmd/compile uses "noalg.struct {...}" as type name when hash and eq algorithm generation of this struct type is suppressed. This should be treated as normal struct type, that is, link shouldn't generate DW_TAG_typedef DIE for it.
Change-Id: Ifada8a818bcfa2e5615f85ead9582cead923b86c
GitHub-Last-Rev: 15de3e4a84
GitHub-Pull-Request: golang/go#50237
Reviewed-on: https://go-review.googlesource.com/c/go/+/373054
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
When building/using plugins on darwin, we need to use flat
namespace so the same symbol from the main executable and the
plugin can be resolved to the same address. Apparently, when using
flat namespace the dynamic linker can hang at forkExec when
resolving a lazy binding. Work around it by forcing early bindings.
Fixes#38824.
Change-Id: I983aa0a0960b15bf3f7871382e8231ee244655f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/372798
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reading the version information to date has required evaluating
two pointers to strings (which themselves contain pointers to data),
which means applying relocations, which can be very system-dependent.
To simplify the lookup, inline the string data into the build info blob.
This makes go version work on binaries built with external linking
on darwin/arm64.
Also test that at least the very basics work on a trivial binary,
even in short mode.
Change-Id: I463088c19e837ae0ce57e1278c7b72e74a80b2c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369977
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The ld from binutils merges note sections into one PT_NOTE
segment.
We should do that for consistency with binutils.
Change-Id: I45703525c720972d49c36c4f10ac47d1628b5698
Reviewed-on: https://go-review.googlesource.com/c/go/+/265957
Trust: Meng Zhuo <mzh@golangcn.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On platforms where we use libc for syscalls, we dynamically link
with libc and therefore dynamic linking cannot be disabled. Exit
early when -d is specified.
Update #42459.
Change-Id: I05abfe111df723b5ee512ceafef734e3804dd0a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/365658
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>
The linker DWARF test includes an "examiner" helper type (with
associated methods) that is used to help linker DWARF tests read DWARF
info in a higher level and more structured way than just raw
debug/dwarf operations. This patch extracts out "examiner" and
relocates it to a separate package, so that it can be used in other
package tests as well, if need be.
Change-Id: Iec66061e2719ee698c12d8fa17b11698442b336d
Reviewed-on: https://go-review.googlesource.com/c/go/+/364036
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When the link exits on error it currently calls Out.Close, which
will munmap the output buffer and close the file. This may be
called in concurrent phase where other goroutines may be writing
to the output buffer. The munmap can race with the write, causing
it to write to unmapped memory and crash. This CL changes it to
just close the file without unmapping. We're exiting on error
anyway so no need to unmap.
Fixes#47816.
Change-Id: I0e89aca991bdada3d017b7d5c8efc29e46308c03
Reviewed-on: https://go-review.googlesource.com/c/go/+/363357
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>
During the register ABI work, a change was made in CL 302071 to
"stackframe" to treat register-resident output parameter (PARAMOUT)
variables that same as locals, which meant that if they were unused,
we'd delete them from the "Dcl" slice. This has the effect of making
them invisible to DWARF generation later on in the pipeline, meaning
that we don't get DIEs for them in the debug info. This patch fixes
the problem by capturing these params prior to optimization and then
adding them back in for consideration when we're processing the
params/locals of a function during DWARF generation.
Fixes#48573.
Change-Id: I2b32882911c18f91c3e3d009486517522d262685
Reviewed-on: https://go-review.googlesource.com/c/go/+/362618
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently it's quite hard to debug these error messages about ignored symbols
because there are only some numbers and no symbol name. Add symbol name. Before:
135029: sym#952: ignoring symbol in section 11 (type 0)
After:
135029: sym#952 (_ZN11__sanitizer9SpinMutexC5Ev): ignoring symbol in section 11 (type 0)
Change-Id: I7fec50b5798068c74827376613be529803838c5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363034
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitry Vyukov <dvyukov@google.com>
Since GCC version 11, the 64-bit version of GCC starting files are
now suffixed by "_64" instead of being stored without suffix under
"ppc64" multilib directory.
Change-Id: Ibe53521ed24d36e5f6282e3574849b9ae11a1e9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/362594
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
The amd64/arm64 relocation processing is used as a template
and updated for ppc64le.
This requires updating the TOC relocation handling code to
support linux type TOC relocations too (note, AIX uses
TOC-indirect accesses).
Noteably, the shared flag of go functions is used as a proxy
for the local entry point offset encoded in elf objects. Functions
in go ppc64le shared objects always[1] insert 2 instructions to
regenerate the TOC pointer.
[1] excepting a couple special runtime functions, see preprocess
in obj9.go for specific details of this behavior.
Change-Id: I3646e6dc8a0a0ffe712771a976983315eae5c418
Reviewed-on: https://go-review.googlesource.com/c/go/+/352829
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes#47557.
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
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>
This provides the runtime glue (_rt0_riscv64_linux_lib) for c-archive and c-shared
support, along with enabling both of these buildmodes on linux/riscv64.
Both misc/cgo/testcarchive and misc/cgo/testcshared now pass on this platform.
Fixes#47100
Change-Id: I7ad75b23ae1d592dbac60d15bba557668287711f
Reviewed-on: https://go-review.googlesource.com/c/go/+/334872
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This code is only generated when linking cgo internally with fixed
position code. This feature of the internal linker is only supported
on ppc64le/linux targets. This moves ppc64le/linux a little closer
to supporting PIE when internal linking.
This is more similar to the implementation suggested in the power
architecture elfv2 supplement, and works with both PIE and static
code.
Change-Id: I0b64e1c22b9e07b5151378d2ab19ee0e50405fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/357332
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, for stack traces (e.g. at panic or when runtime.Stack
is called), we print argument values from the stack. With register
ABI, we may never store the argument to stack therefore the
argument value on stack may be meaningless. This causes confusion.
This CL makes the compiler keep trace of which argument stack
slots are meaningful. If it is meaningful, it will be printed in
stack traces as before. If it may not be meaningful, it will be
printed as the stack value with a question mark ("?"). In general,
the value could be meaningful on some code paths but not others
depending on the execution, and the compiler couldn't know
statically, so we still print the stack value, instead of not
printing it at all. Also note that if the argument variable is
updated in the function body the printed value may be stale (like
before register ABI) but still considered meaningful.
Arguments passed on stack are always meaningful therefore always
printed without a question mark. Results are never printed, as
before.
(Due to a bug in the compiler we sometimes don't spill args into
their dedicated spill slots (as we should), causing it having
fewer meaningful values than it should be.)
This increases binary sizes a bit:
old new
hello 1129760 1142080 +1.09%
cmd/go 13932320 14088016 +1.12%
cmd/link 6267696 6329168 +0.98%
Fixes#45728.
Change-Id: I308a0402e5c5ab94ca0953f8bd85a56acd28f58c
Reviewed-on: https://go-review.googlesource.com/c/go/+/352057
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
cmd/go is not subject to all the same restrictions as most of cmd.
In particular it need not be buildable with the bootstrap toolchain.
So it is better to keep as little code shared between cmd/go and
cmd/compile, cmd/link, cmd/cgo as possible.
cmd/internal/str started as cmd/go/internal/str but was moved
to cmd/internal in order to make use of the quoted string code.
Move that code to cmd/internal/quoted and then move the rest of
cmd/internal/str back to cmd/go/internal/str.
Change-Id: I3a98f754d545cc3af7e9a32c2b77a5a035ea7b9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/355010
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Generic function symbols sometimes have % in them, like:
main.B2[%2eshape.string_0].m2·f
Which confuses this code because it doesn't esacpe % when
using this string as a format string, instead of a format argument.
Or could we get rid of the . -> %2e rewrite somehow?
I think it comes from LinkString.
Change-Id: I3275501f44cf30485e9d4577e0dfa77996d4939e
Reviewed-on: https://go-review.googlesource.com/c/go/+/357837
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
To capture the fact that a method was called on a generic interface,
so we can make sure the linker doesn't throw away any implementations
that might be the method called.
See the comment in reflect.go for details.
Fixes#49049
Change-Id: I0be74b6e727c1ecefedae072b149f59d539dc1e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/357835
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
On wasm, the wasm_exec.js helper passes the command line arguments and
environment variables via a reserved space in the wasm linear memory.
Increase this reserved space from 4096 to 8192 bytes so more environment
variables can fit into the limit.
Later, after https://golang.org/cl/350737 landed, we can switch to the
WASI interface for getting the arguments and environment. This would
remove the limit entirely.
Fixes#49011
Change-Id: I48a6e952a97d33404ed692c98e9b49c5cd6b269b
Reviewed-on: https://go-review.googlesource.com/c/go/+/358194
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The -asan option causes the linker to link against the runtime/asan
package in order to use the C/C++ address sanitizer.
This CL passes tests but is not usable by itself. The actual
runtime/asan package, and support for -asan in the go tool and the
compiler, and tests, are in separate CLs.
Updates #44853.
Change-Id: Ifc6046c1f75ba52777cbb3d937a4b66e91d5798d
Reviewed-on: https://go-review.googlesource.com/c/go/+/298610
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before the 1.12 release the use of linkname did not prevent a compiler
error for an empty function body (see #23311). Add some build tags so
that cmd/link will build with earlier releases.
It's true that we currently require Go 1.16 as the bootstrap compiler (#44505).
But for this simple case keep things working with older compilers for now.
Change-Id: I67fe021406096c64c01d6e2c9adbcc4388988a6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/355690
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When build with "-linkshared", we can't tell if the interface method will be used or not. It can be used in shared library.
Fixes#47873
Change-Id: Iba12812f199b7679cf2fd41a304268d6d6dd03c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/350189
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Direct syscalls are no longer supported on darwin. Instead, use libc
fcntl go:linkname'd from the syscall package.
Change-Id: Ieeec64810452455faedd200f661a8b5839ca1fa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/255260
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
With multiple text sections, there may be holes (non-Go code) in
the PC range of Go code and covered by the functab. Previously, we
use a linear search with actual PCs to find the functab entry. We
need to use special entries to mark holes, so a PC in the hole can
be distinguished from the previous function.
Now, with the previous CL we find if the PC is in between of the
sections upfront in textOff. There is no need to mark holes in the
functab.
Change-Id: I22ff27279422bfc855c2ca35ba0fdfb63234c113
Reviewed-on: https://go-review.googlesource.com/c/go/+/354874
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
A stack object record may refer to the object's type's GC mask or
GC program (for very large types). For the latter, currently the GC
program symbol is named "type..gcprog.XXX" which is then laid out
along with type symbols at link time. When relro is used, the type
symbols end up in a different section.
As we now use relative addressing for stack object records to refer
to GC masks or GC programs, it is important that it is laid out in
the rodata section (not rodata.rel.ro). Move GC program symbols to
be along with GC masks, as they are similar and accessed the same
way. They don't have relocations so they don't need to be laid to a
relro section.
This fixes flaky failures like
https://build.golang.org/log/3bdbaaf786ec831b4393a64a959d2130edb5e050
Change-Id: I97aeac1234869da5b0f3a73a3010513d6a3156c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/354793
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>
When we have multiple text sections, we need to mark holes between
the sections in the functab. A hole is marked with an entry with
the end PC of the previous section. As we now use offsets instead
of (relocated) PCs, the end offset of a section may be the same of
the start of the next one. Distinguish it by using the end address
-1.
For #48837.
Change-Id: I121aac53b32a869378632cf151cb1b6f98ad3089
Reviewed-on: https://go-review.googlesource.com/c/go/+/354636
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>
On Wasm, wasm_exec.js puts command line arguments at the beginning
of the linear memory (following the "zero page"). Currently there
is no limit for this, and a very long command line can overwrite
the program's data section. Prevent this by limiting the command
line to 4096 bytes, and in the linker ensuring the data section
starts at a high enough address (8192).
(Arguably our address assignment on Wasm is a bit confusing. This
is the minimum fix I can come up with.)
Thanks to Ben Lubar for reporting this issue.
Fixes#48797
Fixes CVE-2021-38297
Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/354571
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
They're only used in a single place.
Instead of calculating the end every time,
calculate it in the linker.
It'd be nice to recalculate baseaddr-vaddr,
but that generates relocations that are too large.
While we're here, remove some pointless uintptr -> uintptr conversions.
Change-Id: I91758f9bff11b365bc3a63fee172dbdc3d90b966
Reviewed-on: https://go-review.googlesource.com/c/go/+/354089
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
By making off an int64 at the beginning,
the code gets a lot simpler. Cleanup only.
Change-Id: I4a2519f953e2f71081a4ff3032f8fd6da06c7e24
Reviewed-on: https://go-review.googlesource.com/c/go/+/354138
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>
As we use relative addressing for text symbols in functab, it is
important that the offsets we computed stay unchanged by the
external linker, i.e. all symbols in Textp should not be removed
by the external linker. Most of them are actually referenced (our
deadcode pass ensures that), except go.buildid which is generated
late and not used by the program. Keep it alive.
Should fix AIX builder.
Change-Id: Ibc4a8951be997b9d8d870d75c54754977d9b8333
Reviewed-on: https://go-review.googlesource.com/c/go/+/354369
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is like CL 304432 and CL 307229, for XCOFF.
With this, GOEXPERIMENT=regabi works on AIX/PPC64.
Change-Id: I8cf00681df5c93f397913febd78f38099d91e7c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/353972
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>
Every function has associated numbered extra funcdata to another symbol.
Prior to this change, a funcdata pointer was stored as a relocation.
This change alters this to be an offset relative to go.func.* or go.funcrel.*.
This reduces the number of relocations on darwin/arm64 by about 40%.
It also shrinks externally linked binaries. On darwin/arm64:
size before after Δ %
addr2line 3788498 3699730 -88768 -2.343%
api 5100018 4951074 -148944 -2.920%
asm 4855234 4744274 -110960 -2.285%
buildid 2500162 2419986 -80176 -3.207%
cgo 4338258 4218306 -119952 -2.765%
compile 22764418 22132226 -632192 -2.777%
cover 4583186 4432770 -150416 -3.282%
dist 3200962 3094626 -106336 -3.322%
doc 3680402 3583602 -96800 -2.630%
fix 3114914 3023922 -90992 -2.921%
link 6308578 6154786 -153792 -2.438%
nm 3754338 3665826 -88512 -2.358%
objdump 4124738 4015234 -109504 -2.655%
pack 2232626 2155010 -77616 -3.476%
pprof 13497474 13044066 -453408 -3.359%
test2json 2483810 2402146 -81664 -3.288%
trace 10108898 9748802 -360096 -3.562%
vet 6884322 6681314 -203008 -2.949%
total 107320836 104167700 -3153136 -2.938%
relocs before after Δ %
addr2line 33357 25563 -7794 -23.365%
api 31589 18409 -13180 -41.723%
asm 27825 18904 -8921 -32.061%
buildid 15603 9513 -6090 -39.031%
cgo 27809 17103 -10706 -38.498%
compile 114769 64829 -49940 -43.513%
cover 32932 19462 -13470 -40.902%
dist 18797 10796 -8001 -42.565%
doc 22891 13503 -9388 -41.012%
fix 19700 11465 -8235 -41.802%
link 37324 23198 -14126 -37.847%
nm 33226 25480 -7746 -23.313%
objdump 35237 26610 -8627 -24.483%
pack 13535 7951 -5584 -41.256%
pprof 97986 63961 -34025 -34.724%
test2json 15113 8735 -6378 -42.202%
trace 66786 39636 -27150 -40.652%
vet 43328 25971 -17357 -40.060%
total 687806 431088 -256718 -37.324%
It should also incrementally speed up binary launching
and may reduce linker memory use.
This is another step towards removing relocations so
that pages that were previously dirtied by the loader may remain clean,
which will offer memory savings useful in constrained environments like iOS.
Removing the relocations in .stkobj symbols will allow some simplifications.
There will be no references into go.funcrel.*,
so we will no longer need to use the bottom bit to distinguish offset bases.
Change-Id: I83d34c1701d6f3f515b9905941477d522441019d
Reviewed-on: https://go-review.googlesource.com/c/go/+/352110
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>
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>
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>
CALL and JMP on riscv64 are currently implemented as an AUIPC+JALR pair. This means
that every call requires two instructions and makes use of the REG_TMP register,
even when the symbol would be directly reachable via a single JAL instruction.
Add support for call trampolines - CALL and JMP are now implemented as a single JAL
instruction, with the linker generating trampolines in the case where the symbol is
not reachable (more than +/-1MiB from the JAL instruction), is an unknown symbol or
does not yet have an address assigned. Each trampoline contains an AUIPC+JALR pair,
which the relocation is applied to.
Due to the limited reachability of the JAL instruction, combined with the way that
the Go linker currently assigns symbol addresses, there are cases where a call is to
a symbol that has no address currently assigned. In this situation we have to assume
that a trampoline will be required, however we can patch this up during relocation,
potentially calling directly instead. This means that we will end up with trampolines
that are unused. In the case of the Go binary, there are around 3,500 trampolines of
which approximately 2,300 are unused (around 9200 bytes of machine instructions).
Overall, this removes over 72,000 AUIPC instructions from the Go binary.
Change-Id: I2d9ecfb85dfc285c7729a3cd0b3a77b6f6c98be0
Reviewed-on: https://go-review.googlesource.com/c/go/+/345051
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Cherry Mui
Byoungchan Lee
Meng Zhuo
Bryan C. Mills
Russ Cox
MoZhonghua
Ian Lance Taylor
Than McIntosh
Dmitry Vyukov
Clément Chigot
Paul E. Murphy
Joel Sing
Keith Randall
Richard Musiol
fanzha02
zhouguangyuan
Tobias Klauser
Josh Bleecher Snyder