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>
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>
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>
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 -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>
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>
When building for macOS with external linking, we currently use
"xcrun" to invoke "dsymutil" and "strip" tools. That doesn't work
well for cross compilation. Use "CC --print-prog-name" to find the
tool path instead.
Fixes#47316.
Change-Id: Ib30c6494c48bfb6a505dc26fe644ef543d777076
Reviewed-on: https://go-review.googlesource.com/c/go/+/336769
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>
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>
It is now gone.
Change-Id: I59f68b324af706476695de2f291dd3aa5734e192
Reviewed-on: https://go-review.googlesource.com/c/go/+/351332
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In the past we introduced ABI aliases, in preparation for ABI
wrappers. Now that we have ABI wrappers implemented, we don't
need ABI aliases. If ABI wrappers are not enabled, ABI0 and
ABIInternal are actually identical, so we can resolve symbol
references without distinguish them. This CL does so by
normalizing ABIInternal to ABI0 at link time. This way, we no
longer need to generate ABI aliases.
This CL doesn't clean up everything related to ABI aliases, which
will be done in followup CLs.
Change-Id: I5b5db43370d29b8ad153078c70a853e3263ae6f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/351271
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>
Setup .TOC. to point to the same place for all objects. Today, the linker
assumes all call relocations can use the local function entry point of
imported object files. This requires a consistent pointer across all
objects.
This intentionally computes the .TOC. pointer in all linking configurations.
In some cases the .TOC. is not used today (e.g linking position-dependent go
only code). It is harmless and simple to compute in all cases, so just
do it for easier maintenance.
Notably, .TOC. is used in some cases when static linking is requested on
ppc64le/linux:
* Position-independent C code using a PC-rel relocation against .TOC.. cgo
generated C object files are usually compiled PIC even if the go binary
itself is not.
* Anything which causes PLT stub generation. The stubs always generate
a .TOC. relative relocation.
* The race detector. Today, this links in an externally compiled archive which
contains position-independent object files.
Similarly, position-independent linking is always punted to the external
linker on ppc64 today.
Updates #21961Fixes#15409
Change-Id: Ifd8294b9249e16ba8b92eaf876d15d162f9c61fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/304458
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
The CC and CXX environment variables now support spaces and quotes
(both double and single). This fixes two issues: first, if CC is a
single path that contains spaces (like 'c:\Program
Files\gcc\bin\gcc.exe'), that should now work if the space is quoted
or escaped (#41400). Second, if CC or CXX has multiple arguments (like
'gcc -O2'), they are now split correctly, and the arguments are passed
before other arguments when invoking the C compiler. Previously,
strings.Fields was used to split arguments, and the arguments were
placed later in the command line. (#43078).
Fixesgolang/go#41400Fixesgolang/go#43078
NOTE: This change also includes a fix (CL 341929) for a test that was
broken by the original CL. Commit message for the fix is below.
[dev.cmdgo] cmd/link: fix TestBuildForTvOS
This test was broken in CL 334732 on darwin.
The test invokes 'go build' with a CC containing the arguments
-framework CoreFoundation. Previously, the go command split CC on
whitespace, and inserted the arguments after the command line when
running CC directly. Those arguments weren't passed to cgo though,
so cgo ran CC without -framework CoreFoundation (or any of the other
flags).
In CL 334732, we pass CC through to cgo, and cgo splits arguments
using str.SplitQuotedFields. So -framework CoreFoundation actually
gets passed to the C compiler. It appears that -framework flags are
only meant to be used in linking operations, so when cgo invokes clang
with -E (run preprocessor only), clang emits an error that -framework
is unused.
This change fixes the test by moving -framework CoreFoundation out of
CC and into CGO_LDFLAGS.
Change-Id: I2d5d89ddb19c94adef65982a8137b01f037d5c11
Reviewed-on: https://go-review.googlesource.com/c/go/+/334732
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/341936
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When external linking, we are creating an object file, instead of
a executable. The absolute address is irrelevant. The external
linker will set it up. Start at address 0.
Change-Id: I3a2e0b8087b328d5c3144f29ca8ba6311aa39cba
Reviewed-on: https://go-review.googlesource.com/c/go/+/319830
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 now accepts unrecognized object files in external linking mode.
These objects will simply be passed to the external linker.
This permits using -flto which can generate pure byte code objects,
whose symbol table the linker does not know how to read.
The cgo tool now passes -fno-lto when generating objects whose symbols
it needs to read. The cgo tool now emits matching types in different
objects, so that the lto linker does not report a mismatch.
This is based on https://golang.org/cl/293290 by Derek Parker.
For #43505Fixes#43830Fixes#46295
Change-Id: I6787de213417466784ddef5af8899e453b4ae1ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/322614
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Currently we have two code paths of writing the text segment. They
are semantically the same:
- if we split text sections, we write all ".text" sections as
text and the the rest as data.
- if we do not split text sections, we write the first section
as text and the rest as data. The first section is named ".text"
and is the only one in this case.
Unify the code.
Change-Id: Ic639eed625615be3c8a8d41f5b47e901552f587a
Reviewed-on: https://go-review.googlesource.com/c/go/+/316049
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, when ABI wrappers are used, we don't use ABI aliases.
One exception is shared linkage. When loading a shared library, if
a symbol has only one ABI, and the name is not mangled, we don't
know what ABI it is, so we have to use ABI aliases.
This CL makes it always mangle ABIInternal function name in shared
linkage, so we know what ABI to choose when loading a shared
library. And we now can fully stop using ABI aliases when ABI
wrappers are used.
Change-Id: Id15d9cd72a59f391f54574710ebba7dc44cb6e23
Reviewed-on: https://go-review.googlesource.com/c/go/+/315869
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently in the linker, for trampoline insertion it does a one-pass
approach, where it assigns addresses for each function and inserts
trampolines on the go. For this to work and not to emit too many
unnecessary trampolines, the functions need to be laid out in
dependency order, so a direct call's target is always as a known
address (or known to be not too far).
This mostly works, but there are a few exceptions:
- linkname can break dependency tree and cause cycles.
- in internal linking mode, on some platforms, some calls are turned
into calls via PLT, but the PLT stubs are inserted rather late.
Also, this is expensive in that it has to investigate all CALL
relocations.
This CL changes it to use a two-pass approach. The first pass is
just to assign addresses without inserting any trampolines, assuming
the program is not too big. If this succeeds, no extra work needs to
be done. If this fails, start over and insert trampolines for too-
far targets as well as targets with unknown addresses. This should
make it faster for small programs (most cases) and generate fewer
conservative trampolines.
Change-Id: Ib13e01f38ec6dfbef1cd446b06da33ee17bded5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314450
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
As with -rdynamic, clang will pass -Wl,--dynamic-linker to the linker
even when linking statically. When using lld this will produce a statically
linked executable with a dynamic interpreter, which will crash at runtime.
This CL changes the linker to drop -Wl,--dynamic-linker when using -static,
as it already does with -rdynamic.
This has become more important since CL 310349, which changes the linker
to always pass a -Wl,--dynamic-linker option if the Go linker is invoked
with a -I option.
Change-Id: I68ed431064f02c70018bc0547585e5b0ebd20a41
Reviewed-on: https://go-review.googlesource.com/c/go/+/314412
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Functional plugin support requires cgo to be enabled. Disable
it if the environment has disabled cgo.
This prevents unexpected linker failures when linking large
binaries with cgo disabled which use the plugin package.
Fixes#45564
Change-Id: Ib71f0e089f7373b7b3e3cd53da3612291e7bc473
Reviewed-on: https://go-review.googlesource.com/c/go/+/314449
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
The cmd/link check of the objabi header was a bit lax because
historically the assembler has not included the full version string.
And the assembler didn't do that because it didn't have access to it:
that was buried inside the compiler.
But now that we have cmd/internal/objabi, all the tools have full
access to the expected string, and they can use it, which simplifies
the cmd/link consistency check.
Do that.
Change-Id: I33bd2f9d36c373cc3c32ff02ec6368365088b011
Reviewed-on: https://go-review.googlesource.com/c/go/+/312030
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#22446
Change-Id: Id5b3fbc9cd3a7d6c4bf4e28428b8cb6d45a9ca92
Reviewed-on: https://go-review.googlesource.com/c/go/+/310349
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The go/build package needs access to this configuration,
so move it into a new package available to the standard library.
Change-Id: I868a94148b52350c76116451f4ad9191246adcff
Reviewed-on: https://go-review.googlesource.com/c/go/+/310731
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Currently, setCgoAttr populates the cgo_export_{static,dynamic} maps
with symbol names of exported symbols, which are then re-looked-up by
deadcode and setupdynexp, which in turn puts the re-looked-up symbols
in ctxt.dynexp. setCgoAttr already looked up the Syms, so simplify all
of this by making setCgoAttr populate ctxt.dynexp directly and
eliminating the cgo_export_{static,dynamic} maps. Recording Syms
directly also sets us up to use correct symbol versions for these
exports, rather than just assuming version 0 for all lookups.
Since setupdynexp doesn't really do any "setting up" of dynexp any
more with this change, we fold the remaining logic from setupdynexp
directly into addexport, where it has better context anyway. This also
eliminates a sorting step, since we no longer do a non-deterministic
map iteration to build the dynexp slice.
For #40724.
Change-Id: I3e1a65165268da8c2bf50d7485f2624133433260
Reviewed-on: https://go-review.googlesource.com/c/go/+/309340
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
setCgoAttr takes a lookup function, but there's only a single call and
setCgoAttr already has access to the lookup function passed at that
call. Simplify setCgoAttr by eliminating the lookup parameter and
calling the lookup function directly.
For #40724.
Change-Id: Ib27c0fa2b88c387e30423365f7757e3ba02cf7d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/309338
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When compiling with the race detector using modern mingw, this prevents:
libgcc(.text): relocation target ___chkstk_ms not defined
Change-Id: I2095ad09a535505b54f9ff2d3075fd20ac85e515
Reviewed-on: https://go-review.googlesource.com/c/go/+/295910
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
A non-trivial Cgo program may need to use callbacks and interact with
go objects per goroutine. Because of the rules for passing pointers
between Go and C, such a program needs to store handles to associated
Go values. This often causes much extra effort to figure out a way to
correctly deal with: 1) map collision; 2) identifying leaks and 3)
concurrency.
This CL implements a Handle representation in runtime/cgo package, and
related methods such as Value, Delete, etc. which allows Go users can
use a standard way to handle the above difficulties.
In addition, the CL allows a Go value to have multiple handles, and the
NewHandle always returns a different handle compare to the previously
returned handles. In comparison, CL 294670 implements a different
behavior of NewHandle that returns a unique handle when the Go value is
referring to the same object.
Benchmark:
name time/op
Handle/non-concurrent-16 487ns ± 1%
Handle/concurrent-16 674ns ± 1%
Fixes#37033
Change-Id: I0eadb9d44332fffef8fb567c745246a49dd6d4c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/295369
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Rather than checking the linker name or its path for the string "clang",
use linkerFlagSupported to determine whether the -Qunused-arguments flag
may be passed to the linker.
Fixes#45241
Change-Id: I4c1e4d4ecba4cf5823e8f39cfda5d20404ebf513
Reviewed-on: https://go-review.googlesource.com/c/go/+/304692
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When converting a type T to a non-empty interface I, we build the
itab which contains the code pointers of the methods. Currently,
this brings those methods live (if the itab is live), even if the
interface method is never used. This CL changes the itab to use
weak references, so the methods can be pruned if not otherwise
live.
Fixes#42421.
Change-Id: Iee5de2ba11d603c5a102a2ba60440d839a7f9702
Reviewed-on: https://go-review.googlesource.com/c/go/+/268479
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
PPC64 needs to preserve bits when applying some relocations. DS form
relocations must preserve the lower two bits, and thus needs to inspect
the section data as it streams out.
Similarly, the overflow checking requires inspecting the primary
opcode to see if the value is sign or zero extended.
The existing PPC64 code no longer works as the slice returned by
(loader*).Data is cleared as we layout the symbol and process
relocations. This data is always the section undergoing relocation,
thus we can directly inspect the contents to preserve bits or
check for overflows.
Change-Id: I239211f7e5e96208673663b6553b3017adae7e01
Reviewed-on: https://go-review.googlesource.com/c/go/+/300555
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This separates GOEXPERIMENT=regabi into five sub-experiments:
regabiwrappers, regabig, regabireflect, regabidefer, and regabiargs.
Setting GOEXPERIMENT=regabi now implies the working subset of these
(currently, regabiwrappers, regabig, and regabireflect).
This simplifies testing, helps derisk the register ABI project,
and will also help with performance comparisons.
This replaces the -abiwrap flag to the compiler and linker with
the regabiwrappers experiment.
As part of this, regabiargs now enables registers for all calls
in the compiler. Previously, this was statically disabled in
regabiEnabledForAllCompilation, but now that we can control it
independently, this isn't necessary.
For #40724.
Change-Id: I5171e60cda6789031f2ef034cc2e7c5d62459122
Reviewed-on: https://go-review.googlesource.com/c/go/+/302070
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
When the stack bound check fails, print the call chain with
symbol versions (along with the names). Now that we have ABI
wrappers and wrappers do consume stack space, it is clearer to
distinguish the wrappers vs. the underlying functions.
Change-Id: Id1d922e3e7934b31317f233aff3d9667b6ac90c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/302869
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
If runtime.MemProfile is unreachable, default to not collecting any
memory profiling samples, to save memory on the hash table.
Fixes#42347
Change-Id: I9a4894a5fc77035fe59b1842e1ec77a1182e70c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/299671
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Keith Randall <khr@golang.org>
For now, this only add a single relocation type, which is sufficient for
Windows resources. Later we'll see if we need more for cgo.
In order to ensure these code paths are actually tested, this expands
the rsrc tests to include all the architectures of PE objects that we
need to be recognizing, and splits things more clearly between binutils
and llvm objects, which have a slightly different layout, so that we
test both.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ia1ee840265e9d12c0b12dd1c5d0810f8b300e557
Reviewed-on: https://go-review.googlesource.com/c/go/+/289429
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This is only a valid option on ELF. Binutils accepts it, but LLVM
rejects it, so for Windows, it's best to just omit it.
Updates #44250.
Updates #39326.
Updates #38755.
Updates #36439.
Updates #43800.
Change-Id: Iffd2345d757f23dd737e63bd464cd412527077c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/291632
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
If ABI wrappers are enabled, we should not see ABI aliases at
link time. Stop resolving them. One exception is shared linkage,
where we still use ABI aliases as we don't always know the ABI
for symbols from shared libraries.
Change-Id: Ia89a788094382adeb4c4ef9b0312aa6e8c2f79ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/290032
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
In shared build mode and linkage, currently we assume all
function symbols are ABI0 (except for generated type algorithm
functions), and alias them to ABIInternal. When the two ABIs
actually differ (as it is now), this is not actually correct.
This CL resolves symbol ABI based on their mangled names.
If the symbol's name has a ".abi0" or ".abiinternal" suffix, it
is of the corresponding ABI. The symbol without the suffix is
the other ABI. For functions without ABI wrapper generated,
only one ABI exists but we don't know what it is, so we still
use alias (for now).
Change-Id: I2165f149bc83d513e81eb1eb4ee95464335b0e75
Reviewed-on: https://go-review.googlesource.com/c/go/+/289289
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Introduces a wrapper around os/exec, internal/execabs, for use in
all commands. This wrapper prevents exec.LookPath and exec.Command from
running executables in the current directory.
All imports of os/exec in non-test files in cmd/ are replaced with
imports of internal/execabs.
This issue was reported by RyotaK.
Fixes CVE-2021-3115
Fixes#43783
Change-Id: I0423451a6e27ec1e1d6f3fe929ab1ef69145c08f
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/955304
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/284783
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
This switches openbsd/amd64 to thread creation via pthreads, rather than doing
direct system calls.
Update #36435
Change-Id: I1105d5c392aa3e4c445d99c8cb80b927712e3529
Reviewed-on: https://go-review.googlesource.com/c/go/+/250180
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 Zhang <cherryyz@google.com>
On Apple Silicon Mac, the C compiler has an annoying default
target selection, depending on the ancestor processes'
architecture. In particular, if the shell or IDE is x86, when
running "go build" even with a native ARM64 Go toolchain, the C
compiler defaults to x86, causing build failures. We pass "-arch"
flag explicitly to avoid this situation.
Fixes#43692.
Fixes#43476.
Updates golang/vscode-go#1087.
Change-Id: I80b6a116a114e11e273c6886e377a1cc969fa3f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/283812
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.
However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.
So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.
We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.
Fixes#42866.
Fixes#43182.
Change-Id: I059450021405cdf2ef1c195ddbab3960764ad711
Reviewed-on: https://go-review.googlesource.com/c/go/+/268337
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
When doing external linking on Windows, auto-detect the linker flavor
(bfd vs gold vs lld) and when linking with "lld", avoid the use of
"-T" (linker script), since this option is not supported by lld.
[Note: the Go linker currently employs -T to ensure proper placement
of the .debug_gdb_scripts section, to work around issues in older
versions of binutils; LLD recognizes this section and does place it
properly].
Updates #39326.
Change-Id: I3ea79cdceef2316bf86eccdb60188ac3655264ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/278932
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When testing if a flag (e.g. "-no-pie") is supported by the
external linker, pass arch-specific flags (like "-marm").
In particular, on the ARM builder, if CGO_LDFLAGS=-march=armv6
is set, the C toolchain fails to build if -marm is not passed.
# cc -march=armv6 1.c
1.c: In function 'main':
1.c:3:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
int main() {
^~~
This makes the Go linker think "-no-pie" is not supported when it
actually is.
Passing -marm makes it work.
Fixes#43202.
Change-Id: I4e8b71f08818993cbbcb2494b310c68d812d6b50
Reviewed-on: https://go-review.googlesource.com/c/go/+/278592
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The linker recognizes headers for 386 and amd64 PE objects, but not arm
objects. This is easily overlooked, since its the same as the 386 header
value, except the two nibbles of the first word are swapped. This commit
simply adds the check for this. Without it, .syso objects are rejected,
which means Windows binaries can't have resources built into them. At
the same time, we add comments to better indicate which condition
applies to which arch.
Change-Id: I210411d978504c1a9540e23abc5a180e24f159ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/268237
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
This CL lets the linker code-sign output binaries on
darwin/arm64, as the kernel requires binaries must be signed in
order to run.
This signature will likely be invalidated when we stamp the
buildid after linking. We still do it in the linker, for
- plain "go tool link" works.
- the linker generates the LC_CODE_SIGNATURE load command with
the right size and offset, so we don't need to update it when
stamping the buildid.
Updates #38485, #42684.
Change-Id: Ia306328906d73217221ba31093fe61a935a46122
Reviewed-on: https://go-review.googlesource.com/c/go/+/272256
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This reverts CL 252478.
Reason for revert: debug/Elfhdr has no Flags fields, some other CLs has removed it.
Change-Id: Ie199ac29f382c56aaf37a2e8338f2dafe6e79297
Reviewed-on: https://go-review.googlesource.com/c/go/+/265317
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
