This CL updates the linker to support
IMAGE_REL_[I386|AMD64|ARM|ARM64]_ADDR32NB relocations via the new
R_PEIMAGEOFF relocation type. This relocation type references symbols
using RVAs instead of VA, so it can use 4-byte offsets to reference
symbols that would normally require 8-byte offsets.
This new relocation is still not used, but will be useful when
generating Structured Exception Handling (SEH) metadata, which
needs to reference functions only using 4-byte addresses, thus
using RVAs instead of VA is of great help.
Updates #57302
Change-Id: I28d73e97d5cb78a3bc7194dc7d2fcb4a03f9f4d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/461737
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Davis Goodin <dagood@microsoft.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Go linker has always used IMAGE_SYM_TYPE_NULL as COFF symbol
type [1] when external linking and array of structs
(IMAGE_SYM_DTYPE_ARRAY<<4+IMAGE_SYM_TYPE_STRUCT) when internal linking.
This behavior seems idiosyncratic, and looking at the git history it
seems that it has probably been cargo culted from earlier toolchains.
This CL updates the Go linker to use IMAGE_SYM_DTYPE_FUNCTION<<4 for
those symbols representing functions, and IMAGE_SYM_TYPE_NULL otherwise.
This new behavior better represents the symbol types, and can help
other tools interpreting the intent of each symbol, e.g. debuggers or
tools extracting debug info from Go binaries. It also mimics what other
toolchains do, i.e. MSVC, LLVM, and GCC.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#type-representation
Change-Id: I6b39b2048e95f0324b2eb90c85802ce42db455d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/475856
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Microsoft's PE documentation is contradictory. It says that the
symbol's complex type [1] is stored in the pesym.Type most significant
byte (MSB), but MSVC, LLVM, and mingw store it in the 4 high bits of
the less significant byte (LSB). dumpbin understands both encoding.
Previous to CL 475355 the Go compiler mixed MSB and LSB encoding.
CL 475355 updated to compiler to use the MSB, but this causes problems
with mingw, which emits a warning when MSB is used.
For reference, LLVM also hit this issue long time ago:
https://github.com/llvm/llvm-project/issues/8692
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#type-representation
Change-Id: I7e750bde9c20e2c4c1c023203d7abd6fb26d9d30
Reviewed-on: https://go-review.googlesource.com/c/go/+/475855
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL updates IMAGE_SYM_DTYPE_FUNCTION and IMAGE_SYM_DTYPE_ARRAY
definition and usage so their value can be set to what's defined in
the Microsoft PE docs [1], fixing a long-standing TODO.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#type-representation
Change-Id: I93c19eb78e8a770e8c72245fe9495647e2c5ae5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/475355
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The previous DOS header placed on Windows binaries was incorrect, as it had e_crlc (number of relocations) set to 4, instead of e_cparhdr (size of header in 16-bit words) set to 4. This resulted in execution starting at the beginning of the file, instead of where the DOS stub code actually exists.
Fixes#57834
Change-Id: I8c5966b65c72b2474b771b85aaadb61cad9f5be6
GitHub-Last-Rev: c715ad290a
GitHub-Pull-Request: golang/go#57835
Reviewed-on: https://go-review.googlesource.com/c/go/+/462054
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
As it can't appear in user package paths.
There is a hack for handling "go:buildid" and "type:*" on windows/386.
Previously, windows/386 requires underscore prefix on external symbols,
but that's only applied for SHOSTOBJ/SUNDEFEXT or cgo export symbols.
"go.buildid" is STEXT, "type.*" is STYPE, thus they are not prefixed
with underscore.
In external linking mode, the external linker can't resolve them as
external symbols. But we are lucky that they have "." in their name,
so the external linker see them as Forwarder RVA exports. See:
- https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#export-address-table
- https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/pe-dll.c;h=e7b82ba6ffadf74dc1b9ee71dc13d48336941e51;hb=HEAD#l972)
This CL changes "." to ":" in symbols name, so theses symbols can not be
found by external linker anymore. So a hacky way is adding the
underscore prefix for these 2 symbols. I don't have enough knowledge to
verify whether adding the underscore for all STEXT/STYPE symbols are
fine, even if it could be, that would be done in future CL.
Fixes#37762
Change-Id: I92eaaf24c0820926a36e0530fdb07b07af1fcc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/317917
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now both the compiler and the assembler require the -p flag and
emit full package path in symbol names, we no longer need to do
the name expansion in the linker. Delete it.
Change-Id: I771d4d97987a0a17414881b52806d600ef4cc351
Reviewed-on: https://go-review.googlesource.com/c/go/+/404300
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@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>
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>
Set the correct section flags to insure that .debug_* sections are
using 1-byte alignment instead of the default. This seems to be
important for later versions of LLVM-mingw on windows (shows up on the
windows/arm64 builder).
Updates #46406.
Change-Id: I023d5208374f867552ba68b45011f7990159868f
Reviewed-on: https://go-review.googlesource.com/c/go/+/324763
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
The clang-mingw toolchain on windows/arm64 expects
.text to NOT be listed as containing initialized data and
.dwarf* to be listed as containing initialized data.
Neither is true today, resulting in the go .text and .dwarf*
not being merged with the system .text and .dwarf*.
Having multiple .text and .dwarf* sections confuses all
kinds of tools.
Change-Id: I1b9832804c5f5d594bf19e8ee0a5ed31bc1d381d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312032
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>
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>
This function is no longer used.
Eliminating this actually fixes several problems:
- It made assumptions about what registers memclrNoHeapPointers would
preserve. Besides being an abstraction violation and lurking
maintenance issue, this actively became a problem for regabi because
the call to memclrNoHeapPointers now happens through an ABI wrapper,
which is generated by the compiler and hence we can't easily control
what registers it clobbers.
- The amd64 implementation (at least), does not interact with the host
ABI correctly. Notably, it doesn't save many of the registers that
are callee-save in the host ABI but caller-save in the Go ABI.
- It interacts strangely with the NOSPLIT checker because it allocates
an entire M and G on its stack. It worked around this on arm64, and
happened to do things the NOSPLIT checker couldn't track on 386 and
amd64, and happened to be *4 bytes* below the limit on arm (so any
addition to the m or g structs would cause a NOSPLIT failure). See
CL 309031 for a more complete explanation.
Fixes#45530.
Updates #40724.
Change-Id: Ic70d4d7e1c17f1d796575b3377b8529449e93576
Reviewed-on: https://go-review.googlesource.com/c/go/+/309634
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This replaces the externalthreadhandler-based implementation of
ctrlhandler with one based on compileCallback. This is a step toward
eliminating externalthreadhandler.
For #45530.
Change-Id: I2de2f2f37777af292db67ccf8057b7566aab81f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/309632
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When ABI wrappers are used, we may end up with two functions
having the same name. On ELF we mangle the name with ABI. Do the
same for PE.
TODO: other platforms?
Change-Id: If89f214a6286bc28c062c1aa1bad78dc353a9231
Reviewed-on: https://go-review.googlesource.com/c/go/+/304432
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>
Without setting these flags, LLVM's LLD ignores the .ctors section when
merging objects.
Updates #44250.
Updates #39326.
Updates #38755.
Updates #36439.
Updates #43800.
Change-Id: I8766104508f7acd832088a590ee7d68afa0d6065
Reviewed-on: https://go-review.googlesource.com/c/go/+/291633
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>
GCC and Clang both set the SizeOfRawData field rather than the
VirtualSize field for communicating the size of the .bss section. As a
consequence, LLD does not look at VirtualSize and collapses the .bss
section into whatever is around it, resulting in runtime crashes. This
commit changes the logic so that if the requested "file size" is 0, then
the SizeOfRawData field is set rather than the VirtualSize field as the
sole length marker.
Fixes#44250.
Fixes#39326.
Updates #38755.
Updates #36439.
Updates #43800.
Change-Id: Ied89ddaa0a717fed840238244c6e4848845aeeb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/291630
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 CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I397c1d238bb18cbe78b3fca00910660cf1d66b8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288822
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
A bunch of places are a bit too picky about the architecture.
Simplify them.
Also use a large PEBASE for 64-bit systems.
This more closely matches what is usually used on Windows x86-64
and is required for Windows arm64.
Unfortunately, we still need a special case for x86-64 because
of some cgo relocations. This may be fixable separately.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I65212d28ad4d8c40e2b70dc29f7fce072babecb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288816
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@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>
Resources are immutable, and all other linkers set this section to be
read-only and not read-write. Fix this oversight by removing the writable
flag.
Change-Id: Ib441bde6620be2000f1685df1ea7bfaebdbe7860
Reviewed-on: https://go-review.googlesource.com/c/go/+/268258
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Rename Reloc2 to Reloc, At2 to At, Aux2 to Aux.
Change-Id: Ic98d83c080e8cd80fbe1837c8f0aa134033508ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/245578
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We have Reloc and Reloc2. Reloc2 is the better approach and most
code uses Reloc2. There are still uses of Reloc. This CL migrates
them to Reloc2, and removes Reloc.
Change-Id: Id5f6a6019e1e044add682d05e70ebb1548ec58d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/245577
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We used to generate all external relocations in memory, then emit
the relocation records at a later pass. The data structures were
chosen so that it takes as little memory as possible. Now we just
stream out external relocations, and ExtReloc is just a local
variable. Change the data structure to avoid repeated read of
some fields. Also get rid of ExtRelocView, as it is no longer
necessary.
Change-Id: I40209bbe4387af231b29788125c3b4ebb0ff4a33
Reviewed-on: https://go-review.googlesource.com/c/go/+/245479
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Do them in the same CL so ARM's archreloc doesn't need to support
both streaming and non-streaming.
TODO: we haven't switched to using mmap to emit external
relocations on Windows.
Change-Id: Ica2ee89c03fc74839efd6b9e26c80585fcdce45c
Reviewed-on: https://go-review.googlesource.com/c/go/+/244357
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Introduce a new loader method "AddInteriorSym" to be used when
establishing container/containee symbol relationships for host object
sub-symbols and GOT/dynamic sub-symbols.
Interior symbols are employed in situations where you have a
"container" or "payload" symbol that has content, and then a series of
"interior" sub-symbols that point into a portion of the container
symbol's content. Each interior symbol will typically have a useful
name / size / value, but no content of its own. From a symbol table
perspective the container symbol is anonymous, but the interior
symbols are added to the output symbol table.
Change-Id: I919ed5dbbfe2ef2c9a76214f7ea9b384a1be6297
Reviewed-on: https://go-review.googlesource.com/c/go/+/240508
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The loader's SymbolBuilder Add*/Set* methods include a call to mark
the underlying symbol as reachable (as a convenience, so that callers
would not have to set it explicitly). This code was carried over from
the corresponding sym.Symbol methods; back in the sym.Symbol world
unreachable symbols were never removed from the AllSyms slice, hence
setting and checking reachability was a good deal more important.
With the advent of the loader and the new deadcode implementation,
there is less of a need for this sort of fallback, and in addition the
implicit attr setting introduces data races in the the loader if there
are SymbolBuilder Add*/Set* method calls in parallel threads, as well
as adding overhead to the methods.
This patch gets rid of the implicit reachability setting, and instead
marks reachability in CreateSymForUpdate, as well as adding a few
explicit SetAttrReachable calls where needed.
Change-Id: I029a0c5a4a24237826a7831f9cbe5180d44cbc40
Reviewed-on: https://go-review.googlesource.com/c/go/+/237678
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Now we no longer do loadlibfull on windows.
Change-Id: Ideb015597c28f27538bd50829e089ea728017162
Reviewed-on: https://go-review.googlesource.com/c/go/+/232979
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
After LoadFull, we'll be using sym.Symbols mostly. We still need
the loader information for symbol index mappings and name
lookups, but not much else. Free some memory.
Linking cmd/compile,
name old time/op new time/op delta
Loadlibfull_GC 44.5M ± 0% 35.8M ± 0% -19.66% (p=0.008 n=5+5)
Archive_GC 46.4M ± 0% 37.6M ± 0% -18.89% (p=0.008 n=5+5)
Linking cmd/compile with external linking,
name old time/op new time/op delta
Loadlibfull_GC 82.5M ± 0% 57.4M ± 0% -30.41% (p=0.008 n=5+5)
Archive_GC 86.8M ± 0% 61.7M ± 0% -28.90% (p=0.008 n=5+5)
Change-Id: I6859d488172ef8968918b86de527fbfed6832ebf
Reviewed-on: https://go-review.googlesource.com/c/go/+/230300
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
None of the users of genasmsym are doing anything with the Gotype
field of sym.Symbol, so remove that param from the callback function.
Change-Id: Ie902c4cdbcc6b68d353daf5ce21a99012161a946
Reviewed-on: https://go-review.googlesource.com/c/go/+/230545
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change linker DWARF generation to move away from emitting a single
giant list of DWARF symbols, and instead emit a list of descriptors,
with each descriptor holding the symbols for a specific DWARF section.
While placing all DWARF symbols in a single lists does come in handy
in certain instances, it also creates a lot of confusion and weird
code in other cases, specifically where we want to perform operations
on a section-by-section basis (resulting in code that tries to
re-discover section boundaries by walking/inspecting the list).
Change-Id: I4dac81bd38cba903c9fd7004d613597e76dfb77a
Reviewed-on: https://go-review.googlesource.com/c/go/+/228780
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The Count field in Relocs type is always equal to len(rs). Unify
them.
Change-Id: Ic77288ea58b61a98482b218e051d81047d0ddd88
Reviewed-on: https://go-review.googlesource.com/c/go/+/226717
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This gives some small speedup:
(linking cmd/compile)
Loadlibfull 77.8ms ± 6% 68.6ms ± 5% -11.88% (p=0.008 n=5+5)
Also convert some Relocs.At to At2, which should have been done
earlier.
Change-Id: I2a66aeb5857234c6e645e1b23380149cffc8221f
Reviewed-on: https://go-review.googlesource.com/c/go/+/226363
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This change moves datap from global space into the link context. Rather
than having it exist in context, we could have it returned from dodata,
and pass it as a parameter, but it is used in awkward places in the
Arch functions. Easiest for now is just keeping it in the context, until
we more formally move it to slices of loader.Sym.
This is a largely non-functional change.
Change-Id: Ica93bd857c39913ad470a61c63bc8d21704d6308
Reviewed-on: https://go-review.googlesource.com/c/go/+/222664
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL copies IMAGE_FILE_*, IMAGE_SUBSYSTEM_* and
IMAGE_DLLCHARACTERISTICS_* consts from cmd/link/internal/ld package.
The consts are also used in cmd/go and debug/pe tests. So avoid the
duplication.
The consts are defined in
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
and might be useful to other Go users.
The CL also adds some related consts.
RELNOTE=yes
Change-Id: Iaa868deaffc7c61051f2273397f3e7e101880a5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/222637
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There is one use of sym.Symbol in Peinit, which is called from
linksetup, which is before loadlibfull. Convert this one.
Change-Id: Iedb8b0e0c5c292bccf5c9bd5d092ee434a4ebdbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/221177
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This CL implements windows version of -buildmode=pie code in both
cmd/go and cmd/link.
Windows executables built with -buildmode=pie set (unlike the one
built with -buildmode=exe) will have extra .reloc PE section, and
will have no IMAGE_FILE_RELOCS_STRIPPED flag set. They will also
have IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag set, and
IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA flag set for windows/amd64.
Both cgo and non-cgo versions are implemented. And TestBuildmodePIE
is extended to test both cgo and non-cgo versions on windows and
linux.
This CL used some code from CLs 152759 and 203602.
RELNOTE=yes
Fixes#27144
Updates #35192
Change-Id: I1249e4ffbd79bd4277efefb56db321c390c0f76f
Reviewed-on: https://go-review.googlesource.com/c/go/+/214397
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>