On FreeBSD 14.1 we fail to link against C code with internal linking.
The symptom is apparently undefined symbols, but explicitly pointing the
linker at compiler-rt for -libgcc fixes the issue. This looks a lot like
the workaround on OpenBSD, but the symptom is different.
--print-libgcc-file-name produces libclang_rt.builtins-x86_64.a which
appears to be an insufficient subset of libcompiler_rt.a.
For #61095.
Change-Id: Iff5affbc923d69c89d671a69d8f4ecaadac42177
Cq-Include-Trybots: luci.golang.try:gotip-freebsd-amd64
Reviewed-on: https://go-review.googlesource.com/c/go/+/632975
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Instead, have the runtime build the gc bitmaps on demand
at runtime.
Change-Id: If7a245bc62e4bce3ce80972410b0ed307d921abe
Reviewed-on: https://go-review.googlesource.com/c/go/+/616255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
The linker knows the types of the global variables. We can use those
types to build the GC programs that describe the data and bss pointer masks.
That way we don't use the GC programs of the constituent types.
This is part of an effort to remove GC programs from the runtime.
There's a major complication in that when we're linking against a
shared library (typically, libstd.so), the relocations we need to
break apart arrays and structs into constituent types are difficult to
find. Load that additional data when linking against shared libraries.
Change-Id: I8516b24a0604479895c7b8a8a358d3cd8d421530
Reviewed-on: https://go-review.googlesource.com/c/go/+/546216
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
For FIPS init-time code+data verification, we need to arrange to
put the FIPS symbols into contiguous regions of the executable
and then record those sections along with the expected checksum.
The cmd/internal/obj changes identify the FIPS symbols and give
them distinguished types, which the linker then places in contiguous
regions. The linker also writes out information to use at run time
to find the FIPS sections, along with the expected hash.
See cmd/internal/obj/fips.go and cmd/link/internal/ld/fips.go
for more details.
The code is disabled in this commit.
CL 625998 and 625999 adds tests.
CL 626000 enables the code.
For #69536.
Change-Id: I48da6db94bc0bea7428c43d4abcf999527bccfcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/625997
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
These will be necessary when we start using the new FIPS symbols.
Split into a separate CL so that these refactoring changes can be
tested separate from any FIPS-specific changes.
Passes golang.org/x/tools/cmd/toolstash/buildall.
Change-Id: I73e5873fcb677f1f572f0668b4dc6f3951d822bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/625996
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
As the comment notes, all calls to Errorf now pass nil,
so remove that argument entirely.
There is a TODO to remove uses of Errorf entirely, but
that seems wrong: sometimes there is no symbol on
which to report the error, and in that situation, Errorf is
appropriate. So clarify that in the docs.
Change-Id: I92b3b6e8e3f61ba8356ace8cd09573d0b55d7869
Reviewed-on: https://go-review.googlesource.com/c/go/+/625617
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On Solaris the default (non-GNU) C linker doesn't support the
--build-id flag (and I'm not aware of any alternative). So check
that the linker supports the flag before passing it.
Updates #41004, #63934.
Cq-Include-Trybots: luci.golang.try:gotip-solaris-amd64
Change-Id: I4379e5bf6eb495154d663ac4ed802ecb11fcf91c
Reviewed-on: https://go-review.googlesource.com/c/go/+/621639
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Flags from CGo directives should be placed before extldflags so that
extldflags get more preference. This is also the order followed by the
final link command.
Fixes#69350
Change-Id: I2cfb22ae4ea7a160cc614440e88ef2eb82ea7399
Reviewed-on: https://go-review.googlesource.com/c/go/+/614275
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
On ELF, default to "-B gobuildid", so it generates GNU build ID
based on Go buildid by default.
Updates #41004.
Fixes#63934.
Fixes#68652.
Change-Id: I5619dfaa4eeb6575c52922ae1de3430b46e31db6
Reviewed-on: https://go-review.googlesource.com/c/go/+/618601
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Currently, on Mach-O, the -B UUID setting is only applied in
internal linking mode, whereas in external linking mode the UUID
is always rewritten to a hash of Go build ID. This CL makes it
apply to external linking as well. This makes the behavior
consistent on both linkmodes, and also consistent with the -B
flag's behavior for GNU build ID on ELF.
Add tests.
Updates #68678.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14,gotip-darwin-arm64_13
Change-Id: I276a5930e231141440cdba16e8812df28ac4237b
Reviewed-on: https://go-review.googlesource.com/c/go/+/618599
Reviewed-by: Than McIntosh <thanm@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: Ib437e272e0eb7d1b0969a4ed94d264ca3aad7c59
Reviewed-on: https://go-review.googlesource.com/c/go/+/612696
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Tim King <taking@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tim King <taking@google.com>
CL 402595 changes all usages of 20 bytes hash to 32 bytes hash by using
notsha256.
However, since CL 454836, notsha256 is not necessary anymore, so this CL
reverts those changes to 20 bytes hash using cmd/internal/hash package.
Updates #51940
Updates #64751
Change-Id: Icb08d5a0d8032a3c4d050ff7b2298d31c483b88b
Reviewed-on: https://go-review.googlesource.com/c/go/+/610597
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
CL 402595 used notsha256 to prevent the compiler from depending on
cgo-based implementations of sha1 and sha256.
However, since CL 454836, cmd is built with CGO_ENABLED=0, which
will disable boringcrypto. Thus all usages of notsha256 is not necessary
anymore.
Updates #51940
Updates #64751
Change-Id: I503090f7a2efb5723e8a79523b143dc7cdb4edd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/610596
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: Id991ec0826a4e2857f00330b4b7ff2b71907b789
Reviewed-on: https://go-review.googlesource.com/c/go/+/606615
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
We have an optimization that if the memory profile is not consumed
anywhere, we set the memory profiling rate to 0 to disable the
"background" low-rate profiling. We detect whether the memory
profile is used by checking whether the runtime.MemProfile function
is reachable at link time. Previously, all APIs that access the
memory profile go through runtime.MemProfile. But the code was
refactored in CL 572396, and now the legacy entry point
WriteHeapProfile uses pprof_memProfileInternal without going
through runtime.MemProfile. In fact, even with the recommended
runtime/pprof.Profile API (pprof.Lookup or pprof.Profiles),
runtime.MemProfile is only (happen to be) reachable through
countHeap.
Change the linker to check runtime.memProfileInternal instead,
which is on all code paths that retrieve the memory profile. Add
a test case for WriteHeapProfile, so we cover all entry points.
Fixes#68136.
Change-Id: I075c8d45c95c81825a1822f032e23107aea4303c
Reviewed-on: https://go-review.googlesource.com/c/go/+/596538
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Even if dsymutil didn't generate a file (which should not happen
with the Apple toolchain with the correct setup), we should not
skip next steps, e.g. code sign. A return statement makes it exit
too early.
Updates #68088.
Change-Id: Ic1271ed1b7fe5bdee5a25cc5d669a105173b389e
Reviewed-on: https://go-review.googlesource.com/c/go/+/593660
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
To work around #59026, where dsymutil may not clean up its temp
directory at exit, we set DSYMUTIL_REPRODUCER_PATH to our temp
directory so it uses that, and we can delete it at the end.
In Xcode 16 beta, dsymutil deletes the DSYMUTIL_REPRODUCER_PATH
directory even if it is not empty. We still need our tmpdir at the
point, so give a subdirectory to dsymutil instead.
For #68088.
Change-Id: I18759cc39512819bbd0511793ce917eae72245d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/593659
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix the "gcc --print-prog-name" output parser to handle "\r\n", not only
"\n". The MinGW compiler on Windows uses "\r\n" as line endings, causing
the existing parser to create paths like
".../x86_64-w64-mingw32/bin/ar.exe\r", which is not correct. By trimming
the "\r\n" cutset, both types of line endings are handled correctly.
Fixes#68121
Change-Id: I04b8bf9b6a5b29a1e59a6aa07fa4faa4c5bdeee6
Reviewed-on: https://go-review.googlesource.com/c/go/+/593916
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
[This is a roll-forward of CL 479775, which had to be rolled back due
to bad interactions with the wrappers used by the ios-arm64-corellium
builder. ios-arm64-corellium is no longer being maintained AFAICT,
meaning that it should be ok to move ahead with this patch again].
When external linking with -buildmode=c-archive, the Go linker
eventually invokes the "ar" tool to create the final archive library.
Prior to this patch, if the '-extar' flag was not in use, we would
just run "ar". This works well in most cases but breaks down if we're
doing cross-compilation targeting Windows (macos system "ar"
apparently doesn't create the windows symdef section correctly). To
fix the problem, capture the output of "cc --print-prog-name ar" and
invoke "ar" using the path returned by that command.
Fixes#59221.
Change-Id: Ie367541b23641266a6f48ac68adf971501bff9fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/592375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When building Go binaries using external linking, rewrite the LC_UUID
Macho load command to replace the content placed there by the external
linker, so as to ensure that we get reproducible builds.
Updates #64947.
Change-Id: I263a89d1a067807404febbc801d4dade33bc3288
Reviewed-on: https://go-review.googlesource.com/c/go/+/586079
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
As mentioned in CL 584598, linkname is a mechanism that, when
abused, can break API integrity and even safety of Go programs.
CL 584598 is a first step to restrict the use of linknames, by
implementing a blocklist. This CL takes a step further, tightening
up the restriction by allowing linkname references ("pull") only
when the definition side explicitly opts into it, by having a
linkname on the definition (possibly to itself). This way, it is at
least clear on the definition side that the symbol, despite being
unexported, is accessed outside of the package. Unexported symbols
without linkname can now be actually private. This is similar to
the symbol visibility rule used by gccgo for years (which defines
unexported non-linknamed symbols as C static symbols).
As there can be pull-only linknames in the wild that may be broken
by this change, we currently only enforce this rule for symbols
defined in the standard library. Push linknames are added in the
standard library to allow things build.
Linkname references to external (non-Go) symbols are still allowed,
as their visibility is controlled by the C symbol visibility rules
and enforced by the C (static or dynamic) linker.
Assembly symbols are treated similar to linknamed symbols.
This is controlled by -checklinkname linker flag, currently not
enabled by default. A follow-up CL will enable it by default.
Change-Id: I07344f5c7a02124dbbef0fbc8fec3b666a4b2b0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/585358
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This patch changes the Go linker to "clean" (reset to Unix epoch) the
timestamps on object files copied to the tmpdir that is presented to
the external linker or archive tool. The intent is to improve build
reproducibility on Darwin, where later versions of xcode seem to want
to incorporate object file timestamps into the hash used for the final
build ID (which precludes the possibility of having reproducible Go
builds). Credit for this idea goes to Cherry (see
https://github.com/golang/go/issues/64947#issuecomment-1887667189).
Updates #64947.
Change-Id: I2eb7dddff538e247122b04fdcf8a57c923f61201
Reviewed-on: https://go-review.googlesource.com/c/go/+/585355
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I940c63c3040035e507428798d50060cfd0d04e16
GitHub-Last-Rev: e27484cd43
GitHub-Pull-Request: golang/go#66706
Reviewed-on: https://go-review.googlesource.com/c/go/+/577055
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
The PIE buildmode works correctly on openbsd/arm64, hence enable it.
Updates #59866
Change-Id: I2f3c2839893659391539fafa12891d64f867e189
Reviewed-on: https://go-review.googlesource.com/c/go/+/570375
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
This is a partial roll-forward of CL 473495, which was subsequently
reverted. The second half of CL 473495 will appear in a future CL.
In this patch we introduce a new Go linker "-bindnow" command line
flag, and update the Go command to permit the use of the -Wl,-z,now
option, to allow users to produce binaries that have immediate
binding.
Updates #45681.
Change-Id: Idd61b0d6597bcd37b16c343714c55a4ef6dfb534
Reviewed-on: https://go-review.googlesource.com/c/go/+/571416
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This reverts https://go.dev/cl/c/go/+/473495.
Reason for revert: breaks some Google-internal tests.
This revert will be temporary until we can gather more info on the
nature of the failures and hopefully develop an upstream test case,
etc.
Updates #45681.
Change-Id: Ib628ddc53bc5489e4f76c0f4ad809b75e899102c
Reviewed-on: https://go-review.googlesource.com/c/go/+/571415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
OpenBSD enables Indirect Branch Tracking (IBT) on amd64 and Branch Target
Identification (BTI) on arm64, where hardware permits. Since Go generated
binaries do not currently support IBT or BTI, temporarily mark them with
PT_OPENBSD_NOBTCFI which prevents branch target CFI from being enforced
on execution. This should be removed as soon asn IBT and BTI support are
available.
Fixes#66040
Updates #66054
Change-Id: I91ac05736e6942c54502bef4b8815eb8740d2d5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/568435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Josh Rickmar <jrick@zettaport.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
-bindnow linker option enables full RELRO on ELF targets.
This options defaults to false and preserves
current behavior - partial relro for buildmode=pie.
Also, the following changes were made to align
internal linker's behavior with external ELF linkers:
- GNU_RELRO segment is marked Read-only
- .dynamic is a relro section for partial and full RELRO
- .got is a relro section for partial and full RELRO
- .got.plt is a relro section for full RELRO only
Supersedes #45681 (golang.org/cl/312509)
Change-Id: I51c4ef07b14beceb7cd6fd989f323e45f89a63ca
GitHub-Last-Rev: bc68264410
GitHub-Pull-Request: golang/go#58869
Reviewed-on: https://go-review.googlesource.com/c/go/+/473495
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When the invocation of the external linker, dsymutil or strip
command fails, print the command we invoked.
For #65292.
Change-Id: Icdb5f9ee942ebda4276f6373c3fbbf5222088d0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/558856
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This change introduces new options to set the floating point
mode on ARM targets. The GOARM version number can optionally be
followed by ',hardfloat' or ',softfloat' to select whether to
use hardware instructions or software emulation for floating
point computations, respectively. For example,
GOARM=7,softfloat.
Previously, software floating point support was limited to
GOARM=5. With these options, software floating point is now
extended to all ARM versions, including GOARM=6 and 7. This
change also extends hardware floating point to GOARM=5.
GOARM=5 defaults to softfloat and GOARM=6 and 7 default to
hardfloat.
For #61588
Change-Id: I23dc86fbd0733b262004a2ed001e1032cf371e94
Reviewed-on: https://go-review.googlesource.com/c/go/+/514907
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The Go linker doesn't currently merge .pdata/.xdata sections from the
host object files generated by the C compiler when using internal
linking. This means that the stack can't be unwind in C -> Go.
This CL fixes that and adds a test to ensure that the stack can be
unwind in C -> Go and Go -> C transitions, which was not well tested.
Updates #57302
Change-Id: Ie86a5e6e30b80978277e66ccc2c48550e51263c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/534555
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
String symbol names could contain weird characters as we put the
string literal into the symbol name. So it may appear to need
mangling. However, as string symbols are grouped into a single
"go:string.*" symbol, the individual symbol names actually don't
matter. So don't mangle them.
Also make the mangling code more defensive in case of weird
symbol names.
Fixes#62098.
Change-Id: I533012567a9fffab69debda934f426421c7abb04
Reviewed-on: https://go-review.googlesource.com/c/go/+/520856
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
ld-prime emits a deprecation warning for -bind_at_load. The flag
is needed for plugins to not deadlock (#38824) when linking with
older darwin linker. It is supposedly not needed with newer linker
when chained fixups are used. For now, we always pass it, and
suppress the warning.
For #61229.
Change-Id: I4b8a6f864a460c40dc38adbb533f664f7fd5343c
Reviewed-on: https://go-review.googlesource.com/c/go/+/508696
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
If -v is specified, print dsymutil and strip commands.
Change-Id: Icaff2b41ab582d8c58a4ec65438c2986d88def9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/506758
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Currently, on Mach-O in external linking mode, the handling of -s
and -w flags are a bit mixed: neither flag disables the symbol
table, and both flags disable DWARF.
This CL makes it do what is documented: -s disables symbol table,
and -w disables DWARF. For the Darwin system linker, the -s flag
(strip symbol table) is obsolete. So we strip it afterwards. We
already use the strip command to strip the debug STAB symbols if
we need to combine DWARF. With this CL we'll use an additional
flag to strip more symbols. And we now also use strip if -s is
specified and we don't need to combine DWARF.
Change-Id: I9bed24fd388f2bd5b0ffa4ec2db46a4a2f6b1016
Reviewed-on: https://go-review.googlesource.com/c/go/+/493136
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently we may pass C linker flags in nondeterministic order,
as on ELf systems we pass --export-dynamic-symbol for symbols from
a map. This is usally not a big problem because even if the flags
are passed in nondeterministic order the resulting binary is
probably still deterministic. This CL makes it pass them in a
deterministic order to be extra sure. This also helps build
systems where e.g. there is a build cache for the C linking action.
Change-Id: I930524dd2c3387f49d62be7ad2cef937cb2c2238
Reviewed-on: https://go-review.googlesource.com/c/go/+/509215
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
In plugin mode, we mangle the type symbol name so it doesn't
contain characters that may confuse the external linker. With
generics, instantiated function name includes type names, so it
may also contain such characters and so also needs to be mangled.
Fixes#58800.
Change-Id: Ibb08c95b89b8a815ccef98193d3a025e9d4756cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/500095
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
The existing way of checking for supported linker flags causes false negatives
when there are relative paths passed to go tool link. This fixes the issue by
calling the external linker in the current working directory, instead of
in a temporary directory.
Fixes#59952
Change-Id: I173bb8b44902f30dacefde1c202586f87667ab70
Reviewed-on: https://go-review.googlesource.com/c/go/+/491796
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, we pass elfsetstring to the loader as a callback, for
a special case of Addstring. This is only used for ELF when adding
strings to the section header string table. Move the logic to the
caller instead, so the loader would not have this special case.
Change-Id: Icfb91f380fe4ba435985c3019681597932f58242
Reviewed-on: https://go-review.googlesource.com/c/go/+/492718
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Some versions of dsymutils, notably the one in clang 14.0.3, which
is shipped in some versions of Xcode, have a bug that it creates a
temporary directory but doesn't clean it up at exit. The temporary
directory is created in DSYMUTIL_REPRODUCER_PATH (if set,
otherwise TMPDIR). Work around the issue by setting
DSYMUTIL_REPRODUCER_PATH to the linker's temporary directory, so
the linker will clean it up at exit anyway.
Fixes#59026.
Change-Id: Ie3e90a2d6a01f90040dc2eac91e8e536ccdda5a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/490818
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This CL adds a .xdata section to the PE file generated by the Go linker.
It is also the first CL of the SEH chain that adds effective support
for unwinding the Go stack, as demonstrated by the newly added tests.
The .xdata section is a standard PE section that contains
an array of unwind data info structures. This structures are used to
record the effects a function has on the stack pointer,
and where the nonvolatile registers are saved on the stack [1].
Note that this CL still does not support unwinding the cgo stack.
Updates #57302
[1] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-unwind_info
Change-Id: I6f305a51ed130b758ff9ca7b90c091e50a109a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/457455
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Davis Goodin <dagood@microsoft.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL adds a .pdata section to the PE file generated by the Go linker.
The .pdata section is a standard section [1] that contains an array of
function table entries that are used for stack unwinding.
The table entries layout is taken from [2].
This CL just generates the table entries without any unwinding
information, which is enough to start doing some E2E tests
between the Go linker and the Win32 APIs.
The goal of the .pdata table is to allow Windows retrieve
unwind information for a function at a given PC. It does so by doing
a binary search on the table, looking for an entry that meets
BeginAddress >= PC < EndAddress.
Each table entry takes 12 bytes and only non-leaf functions with
frame pointer needs an entry on the .pdata table.
The result is that PE binaries will be ~0.7% bigger due to the unwind
information, a reasonable amount considering the benefits in
debuggability.
Updates #57302
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-pdata-section
[2] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-runtime_function
Change-Id: If675d10c64452946dbab76709da20569651e3e9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/461738
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The Go arm64 assembler places constants into the text section of a binary.
OpenBSD 7.3 enabled xonly by default on OpenBSD/arm64. This means that any
externally linked Go binary now segfaults. Disable execute-only when invoking
the external linker on openbsd/arm64, in order to work around this issue.
Updates #59615
Change-Id: I1a291293da3c6e4409b21873d066ea15e9bfe280
Reviewed-on: https://go-review.googlesource.com/c/go/+/484555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Aaron Bieber <deftly@gmail.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Than McIntosh <thanm@google.com>
(This is a retry of CL 462035 which was reverted at 474976.
The only change from that CL is the aix fix SRODATA->SNOPTRDATA
at inittask.go:141)
As described here:
https://github.com/golang/go/issues/31636#issuecomment-493271830
"Find the lexically earliest package that is not initialized yet,
but has had all its dependencies initialized, initialize that package,
and repeat."
Simplify the runtime a bit, by just computing the ordering required
in the linker and giving a list to the runtime.
Update #31636Fixes#57411
RELNOTE=yes
Change-Id: I28c09451d6aa677d7394c179d23c2c02c503fc56
Reviewed-on: https://go-review.googlesource.com/c/go/+/478916
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit https://go-review.git.corp.google.com/c/go/+/479775
Reason for revert: fails with ios-arm64-corellium builder
Change-Id: Iae61b994a39ff6c70af8a302f7a46de0097edf3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/479917
Auto-Submit: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When external linking with -buildmode=c-archive, the Go linker
eventually invokes the "ar" tool to create the final archive library.
Prior to this patch, if the '-extar' flag was not in use, we would
just run "ar". This works well in most cases but breaks down if we're
doing cross-compilation targeting Windows (macos system "ar"
apparently doesn't create the windows symdef section correctly). To
fix the problem, capture the output of "cc --print-prog-name ar" and
invoke "ar" using the path returned by that command.
Fixes#59221.
Change-Id: I9de66e98947c42633b16fde7208c2958d62fe7cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/479775
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch changes the Go command to examine the set of compiler
flags feeding into the C compiler when packages that use cgo are built.
If any of a specific set of strange/dangerous flags are in use,
then the Go command generates a token file ("preferlinkext") and
embeds it into the compiled package's archive.
When the Go linker reads the archives of the packages feeding into the
link and detects a "preferlinkext" token, it will then use external
linking for the program by default (although this default can be
overridden with an explicit "-linkmode" flag).
The intent here is to avoid having to teach the Go linker's host object
reader to grok/understand the various odd symbols/sections/types that
can result from boutique flag use, but rather to just boot the objects
in question over to the C linker instead.
Updates #58619.
Updates #58620.
Updates #58848.
Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/475375
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit ce2a609909.
aka CL 462035
Reason for revert: this CL is causing some problems in some internal Google programs.
Change-Id: I4476b8d8d2c3d7b5703d1d85c93baebb4b4e5d26
Reviewed-on: https://go-review.googlesource.com/c/go/+/474976
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
As described here:
https://github.com/golang/go/issues/31636#issuecomment-493271830
"Find the lexically earliest package that is not initialized yet,
but has had all its dependencies initialized, initialize that package,
and repeat."
Simplify the runtime a bit, by just computing the ordering required
in the linker and giving a list to the runtime.
Update #31636Fixes#57411
RELNOTE=yes
Change-Id: I1e4d3878ebe6e8953527aedb730824971d722cac
Reviewed-on: https://go-review.googlesource.com/c/go/+/462035
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
