8000 cmd/link: use >4GB base address for 64-bit PE binaries · golang/go@176a215 · GitHub
[go: up one dir, main page]

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Commit 176a215

Browse files
committed
cmd/link: use >4GB base address for 64-bit PE binaries
Windows prefers 64-bit binaries to be loaded at an address above 4GB. Having a preferred base address below this boundary triggers a compatibility mode in Address Space Layout Randomization (ASLR) on recent versions of Windows that reduces the number of locations to which ASLR may relocate the binary. The Go internal linker was using a smaller base address due to an issue with how dynamic cgo symbols were relocated, which has been fixed in this CL. Fixes #73561. Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest Change-Id: Ia8cb35d57d921d9be706a8975fa085af7996f124 Reviewed-on: https://go-review.googlesource.com/c/go/+/671515 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
1 parent e513cd4 commit 176a215

File tree

3 files changed

+16
-12
lines changed

3 files changed

+16
-12
lines changed

src/cmd/link/internal/ld/data.go

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -894,10 +894,15 @@ func windynrelocsym(ctxt *Link, rel *loader.SymbolBuilder, s loader.Sym) error {
894894
rel.AddUint8(0x90)
895895
rel.AddUint8(0x90)
896896
case sys.AMD64:
897+
// The relocation symbol might be at an absolute offset
898+
// higher than 32 bits, but the jump instruction can't
899+
// encode more than 32 bit offsets. We use a jump
900+
// relative to the instruction pointer to get around this
901+
// limitation.
897902
rel.AddUint8(0xff)
898-
rel.AddUint8(0x24)
899903
rel.AddUint8(0x25)
900-
rel.AddAddrPlus4(ctxt.Arch, targ, 0)
904+
rel.AddPCRelPlus(ctxt.Arch, targ, 0)
905+
rel.AddUint8(0x90)
901906
rel.AddUint8(0x90)
902907
}
903908
} else if tplt >= 0 {

src/cmd/link/internal/ld/pe.go

Lines changed: 7 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1097,18 +1097,10 @@ func Peinit(ctxt *Link) {
10971097
if ctxt.Arch.PtrSize == 8 {
10981098
// 64-bit architectures
10991099
pe64 = true
1100-
PEBASE = 1 << 32
1101-
if ctxt.Arch.Family == sys.AMD64 {
1102-
// TODO(rsc): For cgo we currently use 32-bit relocations
1103-
// that fail when PEBASE is too large.
1104-
// We need to fix this, but for now, use a smaller PEBASE.
1105-
PEBASE = 1 << 22
1106-
}
11071100
var oh64 pe.OptionalHeader64
11081101
l = binary.Size(&oh64)
11091102
} else {
11101103
// 32-bit architectures
1111-
PEBASE = 1 << 22
11121104
var oh pe.OptionalHeader32
11131105
l = binary.Size(&oh)
11141106
}
@@ -1122,6 +1114,13 @@ func Peinit(ctxt *Link) {
11221114
PEFILEALIGN = 0
11231115
// We are creating an object file. The absolute address is irrelevant.
11241116
PEBASE = 0
1117+
} else {
1118+
// Use the same base image address as MSVC and LLVM.
1119+
if pe64 {
1120+
PEBASE = 0x140000000
1121+
} else {
1122+
PEBASE = 0x400000
1123+
}
11251124
}
11261125

11271126
var sh [16]pe.SectionHeader32

test/nilptr.go

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,8 @@
77
// Test that the implementation catches nil ptr indirection
88
// in a large address space.
99

10-
// Address space starts at 1<<32 on AIX and on darwin/arm64 and on windows/arm64, so dummy is too far.
11-
//go:build !aix && (!darwin || !arm64) && (!windows || !arm64)
10+
// Address space starts at 1<<32 on AIX and on darwin/arm64 and on windows/[amd64/arm64], so dummy is too far.
11+
//go:build !aix && (!darwin || !arm64) && (!windows || (!amd64 && !arm64))
1212

1313
package main
1414

0 commit comments

Comments
 (0)
0