Turn off PIE explicitly for windows/amd64 when -race is in effect,
since at the moment the race detector runtime doesn't seem to handle
PIE binaries correctly. Note that newer C compilers on windows
produce PIE binaries by default, so the Go linker needs to explicitly
turn off PIE when invoking the external linker in this case.
Updates #53539.
Change-Id: Ib990621f22cf61a5fa383584bab81d3dfd7552e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/415676
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
As of LLVM rev 41cb504b7c4b18ac15830107431a0c1eec73a6b2, the
race detector runtime now refers to things in the windows
synchronization library, hence when doing windows internal
linking, at that library to the list of host archives that
we visit. The tsan code that makes the reference is here:
41cb504b7c/compiler-rt/lib/sanitizer_common/sanitizer_win.cpp (L48)41cb504b7c/compiler-rt/lib/sanitizer_common/sanitizer_win.cpp (L834)
Note that libsynchronization.a is not guaranteed to be available on
all windows systems, so in the external linking case, check for its
existence before adding "-lsynchronization" to the external linker
args.
Updates #53539.
Change-Id: I433c95c869915693d59e9c1082d5b8a11da1fc8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/413817
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
For a package that uses cgo, the file _cgo_import.go is created to
record information required for internal linking: the non-Go dynamic
symbols and libraries that the package depends on. Generating this
information sometimes fails, because it can require recreating all the
dependencies of all transitively imported packages. And the
information is rarely needed, since by default we use external linking
when there are packages outside of the standard library that use cgo.
With this CL, if generating _cgo_import.go fails, we don't report an
error. Instead, we mark the package as requiring external linking, by
adding an empty file named "dynimportfail" into the generated archive.
If the linker sees a file with that name, it rejects an attempt to use
internal linking.
Fixes#52863
Change-Id: Ie586e6753a5b67e49bb14533cd7603d9defcf0ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/413460
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Both GNU and LLVM linkers de facto accept `-zPARAM`, and Go sometimes
does it. Inconsistently: there are more uses of `-z PARAM` than
`-zPARAM`:
$ git grep -E -- '-Wl,-z[^,]' master | wc -l
4
$ git grep -E -- '-Wl,-z,' master | wc -l
7
However, not adding a space between `-z` and the param is not
documented:
llvm-13:
$ man ld.lld-13 | grep -E -A1 -w -- "^ +-z"
-z option
Linker option extensions.
gnu ld:
$ man ld | grep -E -A1 -w -- "^ +-z"
-z keyword
The recognized keywords are:
--
-z defs
Report unresolved symbol references from regular object files. This is done even if the linker is creating a non-symbolic
--
-z muldefs
Normally when a symbol is defined multiple times, the linker will report a fatal error. These options allow multiple definitions
--
-z
--imagic
... and thus should be avoided.
`zig cc`, when used as the C compiler (`CC="zig cc" go build ...`), will
bark, because `zig cc` accepts only `-z PARAM`, as documented.
Closesziglang/zig#11669
Change-Id: I758054ecaa3ce01a72600bf65d7f7b5c3ec46d09
GitHub-Last-Rev: e068e007da9f2b0441ee0aa8b198a7ba3cd93ed3
GitHub-Pull-Request: golang/go#53030
Reviewed-on: https://go-review.googlesource.com/c/go/+/407834
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
The basic arch-specific hooks are implemented, which
are used for internal and external linker.
Contributors to the loong64 port are:
Weining Lu <luweining@loongson.cn>
Lei Wang <wanglei@loongson.cn>
Lingqin Gong <gonglingqin@loongson.cn>
Xiaolin Zhao <zhaoxiaolin@loongson.cn>
Meidan Li <limeidan@loongson.cn>
Xiaojuan Zhai <zhaixiaojuan@loongson.cn>
Qiyuan Pu <puqiyuan@loongson.cn>
Guoqi Chen <chenguoqi@loongson.cn>
This port has been updated to Go 1.15.6:
https://github.com/loongson/go
Updates #46229
Change-Id: I4680eb0635dd0fa3d6ea8348a2488da9c7e33d3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/349514
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
We added internal/execabs back in January 2021 in order to fix
a security problem caused by os/exec's handling of the current
directory. Now that os/exec has that code, internal/execabs is
superfluous and can be deleted.
This commit rewrites all the imports back to os/exec and
deletes internal/execabs.
For #43724.
Change-Id: Ib9736baf978be2afd42a1225e2ab3fd5d33d19df
Reviewed-on: https://go-review.googlesource.com/c/go/+/381375
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
A plain make.bash in this tree will produce a working,
standard Go toolchain, not a BoringCrypto-enabled one.
The BoringCrypto-enabled one will be created with:
GOEXPERIMENT=boringcrypto ./make.bash
For #51940.
Change-Id: Ia9102ed993242eb1cb7f9b93eca97e81986a27b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/395881
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
The linker performs a global analysis of all nosplit call chains to
check they fit in the stack space ensured by splittable functions.
That analysis has two problems right now:
1. It's inefficient. It performs a top-down analysis, starting with
every nosplit function and the nosplit stack limit and walking *down*
the call graph to compute how much stack remains at every call. As a
result, it visits the same functions over and over, often with
different remaining stack depths. This approach is historical: this
check was originally written in C and this approach avoided the need
for any interesting data structures.
2. If some call chain is over the limit, it only reports a single call
chain. As a result, if the check does fail, you often wind up playing
whack-a-mole by guessing where the problem is in the one chain, trying
to reduce the stack size, and then seeing if the link works or reports
a different path.
This CL completely rewrites the nosplit stack check. It now uses a
bottom-up analysis, computing the maximum stack height required by
every function's call tree. This visits every function exactly once,
making it much more efficient. It uses slightly more heap space for
intermediate storage, but still very little in the scheme of the
overall link. For example, when linking cmd/go, the new algorithm
virtually eliminates the time spent in this pass, and reduces overall
link time:
│ before │ after │
│ sec/op │ sec/op vs base │
Dostkcheck 7.926m ± 4% 1.831m ± 6% -76.90% (p=0.000 n=20)
TotalTime 301.3m ± 1% 296.4m ± 3% -1.62% (p=0.040 n=20)
│ before │ after │
│ B/op │ B/op vs base │
Dostkcheck 40.00Ki ± 0% 212.15Ki ± 0% +430.37% (p=0.000 n=20)
Most of this time is spent analyzing the runtime, so for larger
binaries, the total time saved is roughly the same, and proportionally
less of the overall link.
If the new implementation finds an error, it redoes the analysis,
switching to preferring quality of error reporting over performance.
For error reporting, it computes stack depths top-down (like the old
algorithm), and reports *all* paths that are over the stack limit,
presented as a tree for compactness. For example, this is the output
from a simple test case from test/nosplit with two over-limit paths
from f1:
main.f1: nosplit stack overflow
main.f1
grows 768 bytes, calls main.f2
grows 56 bytes, calls main.f4
grows 48 bytes
80 bytes over limit
grows 768 bytes, calls main.f3
grows 104 bytes
80 bytes over limit
While we're here, we do a few nice cleanups:
- We add a debug output flag, which will be useful for understanding
what our nosplit chains look like and which ones are close to
running over.
- We move the implementation out of the fog of lib.go to its own file.
- The implementation is generally more Go-like and less C-like.
Change-Id: If1ab31197f5215475559b93695c44a01bd16e276
Reviewed-on: https://go-review.googlesource.com/c/go/+/398176
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Storing this information in the Arch eliminates some code duplication
between the compiler and linker. This information is entirely
determined by the Arch, so the current approach of attaching it to an
entire Ctxt is a little silly. This will also make it easier to use
this information from tests.
The next CL will be a rote refactoring to eliminate the
Ctxt.FixedFrameSize methods.
Change-Id: I315c524fa66a0ea99f63ae5a2a6fdc367d843bad
Reviewed-on: https://go-review.googlesource.com/c/go/+/400818
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When doing external linking on windows, the existing Go linker code
assumed that the external linker defaulted to "--no-dynamicbase" (if
no explicit option was given). This assumption doesn't hold for LLD,
which turns on "--dynamicbase" by default for 64-bit apps. Change the
linker to detect whether a more modern toolchain is in use and to
explicitly pass "--dynamicbase" either way , so as to take the
external linker default out of the equation. This also applies to the
"--high-entropy-va" option as well.
Updates #35006.
Change-Id: I3e12cf6d331c9d003e3d2bd566d45de5710588b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/384156
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>
When doing an internal link on Windows, it's possible to see
unresolved references to the symbols "__CTOR_LIST__" and/or
"__DTOR_LIST__" (which are needed in some circumstances). If these are
still unresolved at the point where we're done reading host objects,
then synthesize dummy versions of them.
Updates #35006.
Change-Id: I408bf18499bba05752710cf5a41621123bd84a3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/383836
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>
For Windows internal linking with CGO, when using more modern
LLVM-based compilers, we may need to read in the object file "crt2.o"
so as to have a definition of "atexit" (for example when linking the
runtime/cgo test), and we also need to allow for the possibility that
a given host archive might have to be looked at more than once. The goal
here is to get all.bash working on Windows when using an up to date
mingw C compiler (including those based on clang + LLD).
This patch also adds a new "hostObject" helper routine, similar to
"hostArchive" but specific to individual object files. There is also a
change to hostArchive to modify the pseudo-package name assigned when
reading archive elements: up until this point, a package name of
"libgcc" was used (even when reading a host archive like
"libmingex.a"), which led to very confusing errors messages if symbols
were missing or there were duplicate definitions.
Updates #35006.
Change-Id: I19c17dea9cfffa9e79030fc23064c7c63a612097
Reviewed-on: https://go-review.googlesource.com/c/go/+/382838
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>
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>
There used to be two BoringCrypto-specific behaviors related to cipher
suites in crypto/tls:
1. in FIPS-only mode, only a restricted set of AES ciphers is allowed
2. NOT in FIPS-only mode, AES would be prioritized over ChaCha20 even if
AES hardware was not available
The motivation of (2) is unclear, and BoringSSL doesn't have equivalent
logic. This merge drops (2), and keeps (1). Note that the list of
FIPS-only ciphers does not have priority semantics anymore, but the
default logic still sorts them the same way as they used to be.
Change-Id: I50544011085cfa2b087f323aebf5338c0bd2dd33
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>
