go/src/cmd/link/internal/objfile/objfile.go

660 lines
16 KiB
Go
Raw Normal View History

// Copyright 2013 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Package objfile reads Go object files for the Go linker, cmd/link.
//
// This package is similar to cmd/internal/objfile which also reads
// Go object files.
package objfile
import (
"bufio"
"bytes"
"cmd/internal/bio"
"cmd/internal/dwarf"
"cmd/internal/obj"
"cmd/internal/objabi"
"cmd/internal/sys"
"cmd/link/internal/sym"
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
"fmt"
"io"
"log"
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
"os"
"strconv"
"strings"
"unsafe"
)
const (
startmagic = "\x00go114ld"
endmagic = "\xffgo114ld"
)
var emptyPkg = []byte(`"".`)
// objReader reads Go object files.
type objReader struct {
rd *bio.Reader
arch *sys.Arch
syms *sym.Symbols
lib *sym.Library
unit *sym.CompilationUnit
pn string
dupSym *sym.Symbol
localSymVersion int
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
flags int
strictDupMsgs int
dataSize int
// rdBuf is used by readString and readSymName as scratch for reading strings.
rdBuf []byte
// List of symbol references for the file being read.
refs []*sym.Symbol
data []byte
reloc []sym.Reloc
pcdata []sym.Pcdata
funcdata []*sym.Symbol
funcdataoff []int64
file []*sym.Symbol
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
pkgpref string // objabi.PathToPrefix(r.lib.Pkg) + "."
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
roObject []byte // from read-only mmap of object file (may be nil)
roOffset int64 // offset into readonly object data examined so far
dataReadOnly bool // whether data is backed by read-only memory
}
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
// Flags to enable optional behavior during object loading/reading.
const (
NoFlag int = iota
// Sanity-check duplicate symbol contents, issuing warning
// when duplicates have different lengths or contents.
StrictDupsWarnFlag
// Similar to StrictDupsWarnFlag, but issue fatal error.
StrictDupsErrFlag
)
// Load loads an object file f into library lib.
// The symbols loaded are added to syms.
func Load(arch *sys.Arch, syms *sym.Symbols, f *bio.Reader, lib *sym.Library, unit *sym.CompilationUnit, length int64, pn string, flags int) int {
start := f.Offset()
roObject := f.SliceRO(uint64(length))
if roObject != nil {
f.MustSeek(int64(-length), os.SEEK_CUR)
}
r := &objReader{
rd: f,
cmd/link: insert trampolines for too-far jumps on ARM ARM direct CALL/JMP instruction has 24 bit offset, which can only encodes jumps within +/-32M. When the target is too far, the top bits get truncated and the program jumps wild. This CL detects too-far jumps and automatically insert trampolines, currently only internal linking on ARM. It is necessary to make the following changes to the linker: - Resolve direct jump relocs when assigning addresses to functions. this allows trampoline insertion without moving all code that already laid down. - Lay down packages in dependency order, so that when resolving a inter-package direct jump reloc, the target address is already known. Intra-package jumps are assumed never too far. - a linker flag -debugtramp is added for debugging trampolines: "-debugtramp=1 -v" prints trampoline debug message "-debugtramp=2" forces all inter-package jump to use trampolines (currently ARM only) "-debugtramp=2 -v" does both - Some data structures are changed for bookkeeping. On ARM, pseudo DIV/DIVU/MOD/MODU instructions now clobber R8 (unfortunate). In the standard library there is no ARM assembly code that uses these instructions, and the compiler no longer emits them (CL 29390). all.bash passes with -debugtramp=2, except a disassembly test (this is unavoidable as we changed the instruction). TBD: debug info of trampolines? Fixes #17028. Change-Id: Idcce347ea7e0af77c4079041a160b2f6e114b474 Reviewed-on: https://go-review.googlesource.com/29397 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-09-14 14:47:12 -04:00
lib: lib,
unit: unit,
arch: arch,
syms: syms,
pn: pn,
dupSym: &sym.Symbol{Name: ".dup"},
localSymVersion: syms.IncVersion(),
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
flags: flags,
roObject: roObject,
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
pkgpref: objabi.PathToPrefix(lib.Pkg) + ".",
}
r.loadObjFile()
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
if roObject != nil {
if r.roOffset != length {
log.Fatalf("%s: unexpected end at %d, want %d", pn, r.roOffset, start+length)
}
r.rd.MustSeek(int64(length), os.SEEK_CUR)
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
} else if f.Offset() != start+length {
log.Fatalf("%s: unexpected end at %d, want %d", pn, f.Offset(), start+length)
}
return r.strictDupMsgs
}
func (r *objReader) loadObjFile() {
// Magic header
var buf [8]uint8
r.readFull(buf[:])
if string(buf[:]) != startmagic {
log.Fatalf("%s: invalid file start %x %x %x %x %x %x %x %x", r.pn, buf[0], buf[1], buf[2], buf[3], buf[4], buf[5], buf[6], buf[7])
}
// Version
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
c, err := r.readByte()
if err != nil || c != 1 {
log.Fatalf("%s: invalid file version number %d", r.pn, c)
}
// Autolib
for {
lib := r.readString()
if lib == "" {
break
}
r.lib.ImportStrings = append(r.lib.ImportStrings, lib)
}
// DWARF strings
count := r.readInt()
r.unit.DWARFFileTable = make([]string, count)
for i := 0; i < count; i++ {
// TODO: This should probably be a call to mkROString.
r.unit.DWARFFileTable[i] = r.readString()
}
// Symbol references
r.refs = []*sym.Symbol{nil} // zeroth ref is nil
for {
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
c, err := r.peek(1)
if err != nil {
log.Fatalf("%s: peeking: %v", r.pn, err)
}
if c[0] == 0xff {
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
r.readByte()
break
}
r.readRef()
}
// Lengths
r.readSlices()
// Data section
err = r.readDataSection()
if err != nil {
log.Fatalf("%s: error reading %s", r.pn, err)
}
// Defined symbols
for {
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
c, err := r.peek(1)
if err != nil {
log.Fatalf("%s: peeking: %v", r.pn, err)
}
if c[0] == 0xff {
break
}
r.readSym()
}
// Magic footer
buf = [8]uint8{}
r.readFull(buf[:])
if string(buf[:]) != endmagic {
log.Fatalf("%s: invalid file end", r.pn)
}
}
func (r *objReader) readSlices() {
r.dataSize = r.readInt()
n := r.readInt()
r.reloc = make([]sym.Reloc, n)
n = r.readInt()
r.pcdata = make([]sym.Pcdata, n)
_ = r.readInt() // TODO: remove on next object file rev (autom count)
n = r.readInt()
r.funcdata = make([]*sym.Symbol, n)
r.funcdataoff = make([]int64, n)
n = r.readInt()
r.file = make([]*sym.Symbol, n)
}
func (r *objReader) readDataSection() (err error) {
if r.roObject != nil {
r.data, r.dataReadOnly, err =
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
r.roObject[r.roOffset:r.roOffset+int64(r.dataSize)], true, nil
r.roOffset += int64(r.dataSize)
return
}
r.data, r.dataReadOnly, err = r.rd.Slice(uint64(r.dataSize))
return
}
// Symbols are prefixed so their content doesn't get confused with the magic footer.
const symPrefix = 0xfe
func (r *objReader) readSym() {
var c byte
var err error
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
if c, err = r.readByte(); c != symPrefix || err != nil {
log.Fatalln("readSym out of sync")
}
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
if c, err = r.readByte(); err != nil {
log.Fatalln("error reading input: ", err)
}
t := sym.AbiSymKindToSymKind[c]
s := r.readSymIndex()
flags := r.readInt()
dupok := flags&1 != 0
local := flags&2 != 0
makeTypelink := flags&4 != 0
size := r.readInt()
typ := r.readSymIndex()
data := r.readData()
nreloc := r.readInt()
isdup := false
var dup *sym.Symbol
if s.Type != 0 && s.Type != sym.SXREF {
if (t == sym.SDATA || t == sym.SBSS || t == sym.SNOPTRBSS) && len(data) == 0 && nreloc == 0 {
if s.Size < int64(size) {
s.Size = int64(size)
}
if typ != nil && s.Gotype == nil {
s.Gotype = typ
}
return
}
if (s.Type == sym.SDATA || s.Type == sym.SBSS || s.Type == sym.SNOPTRBSS) && len(s.P) == 0 && len(s.R) == 0 {
goto overwrite
}
if s.Type != sym.SBSS && s.Type != sym.SNOPTRBSS && !dupok && !s.Attr.DuplicateOK() {
log.Fatalf("duplicate symbol %s (types %d and %d) in %s and %s", s.Name, s.Type, t, s.File, r.pn)
}
if len(s.P) > 0 {
dup = s
s = r.dupSym
isdup = true
}
}
overwrite:
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
s.File = r.pkgpref[:len(r.pkgpref)-1]
s.Unit = r.unit
if dupok {
s.Attr |= sym.AttrDuplicateOK
}
if t == sym.SXREF {
log.Fatalf("bad sxref")
}
if t == 0 {
log.Fatalf("missing type for %s in %s", s.Name, r.pn)
}
if t == sym.SBSS && (s.Type == sym.SRODATA || s.Type == sym.SNOPTRBSS) {
t = s.Type
}
s.Type = t
if s.Size < int64(size) {
s.Size = int64(size)
}
s.Attr.Set(sym.AttrLocal, local)
s.Attr.Set(sym.AttrMakeTypelink, makeTypelink)
if typ != nil {
s.Gotype = typ
}
if isdup && typ != nil { // if bss sym defined multiple times, take type from any one def
dup.Gotype = typ
}
s.P = data
s.Attr.Set(sym.AttrReadOnly, r.dataReadOnly)
if nreloc > 0 {
s.R = r.reloc[:nreloc:nreloc]
if !isdup {
r.reloc = r.reloc[nreloc:]
}
for i := 0; i < nreloc; i++ {
s.R[i] = sym.Reloc{
Off: r.readInt32(),
Siz: r.readUint8(),
Type: objabi.RelocType(r.readInt32()),
Add: r.readInt64(),
Sym: r.readSymIndex(),
}
}
}
if s.Type == sym.STEXT {
s.FuncInfo = new(sym.FuncInfo)
pc := s.FuncInfo
pc.Args = r.readInt32()
pc.Locals = r.readInt32()
if r.readUint8() != 0 {
s.Attr |= sym.AttrNoSplit
}
flags := r.readInt()
if flags&(1<<2) != 0 {
s.Attr |= sym.AttrReflectMethod
}
if flags&(1<<3) != 0 {
s.Attr |= sym.AttrShared
}
if flags&(1<<4) != 0 {
s.Attr |= sym.AttrTopFrame
}
n := r.readInt()
if n != 0 {
log.Fatalf("stale object file: autom count nonzero")
}
pc.Pcsp.P = r.readData()
pc.Pcfile.P = r.readData()
pc.Pcline.P = r.readData()
cmd/compile,link: generate PC-value tables with inlining information In order to generate accurate tracebacks, the runtime needs to know the inlined call stack for a given PC. This creates two tables per function for this purpose. The first table is the inlining tree (stored in the function's funcdata), which has a node containing the file, line, and function name for every inlined call. The second table is a PC-value table that maps each PC to a node in the inlining tree (or -1 if the PC is not the result of inlining). To give the appearance that inlining hasn't happened, the runtime also needs the original source position information of inlined AST nodes. Previously the compiler plastered over the line numbers of inlined AST nodes with the line number of the call. This meant that the PC-line table mapped each PC to line number of the outermost call in its inlined call stack, with no way to access the innermost line number. Now the compiler retains line numbers of inlined AST nodes and writes the innermost source position information to the PC-line and PC-file tables. Some tools and tests expect to see outermost line numbers, so we provide the OutermostLine function for displaying line info. To keep track of the inlined call stack for an AST node, we extend the src.PosBase type with an index into a global inlining tree. Every time the compiler inlines a call, it creates a node in the global inlining tree for the call, and writes its index to the PosBase of every inlined AST node. The parent of this node is the inlining tree index of the call. -1 signifies no parent. For each function, the compiler creates a local inlining tree and a PC-value table mapping each PC to an index in the local tree. These are written to an object file, which is read by the linker. The linker re-encodes these tables compactly by deduplicating function names and file names. This change increases the size of binaries by 4-5%. For example, this is how the go1 benchmark binary is impacted by this change: section old bytes new bytes delta .text 3.49M ± 0% 3.49M ± 0% +0.06% .rodata 1.12M ± 0% 1.21M ± 0% +8.21% .gopclntab 1.50M ± 0% 1.68M ± 0% +11.89% .debug_line 338k ± 0% 435k ± 0% +28.78% Total 9.21M ± 0% 9.58M ± 0% +4.01% Updates #19348. Change-Id: Ic4f180c3b516018138236b0c35e0218270d957d3 Reviewed-on: https://go-review.googlesource.com/37231 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-02-17 12:28:05 -05:00
pc.Pcinline.P = r.readData()
n = r.readInt()
pc.Pcdata = r.pcdata[:n:n]
if !isdup {
r.pcdata = r.pcdata[n:]
}
for i := 0; i < n; i++ {
pc.Pcdata[i].P = r.readData()
}
n = r.readInt()
pc.Funcdata = r.funcdata[:n:n]
pc.Funcdataoff = r.funcdataoff[:n:n]
if !isdup {
r.funcdata = r.funcdata[n:]
r.funcdataoff = r.funcdataoff[n:]
}
for i := 0; i < n; i++ {
pc.Funcdata[i] = r.readSymIndex()
}
for i := 0; i < n; i++ {
pc.Funcdataoff[i] = r.readInt64()
}
n = r.readInt()
pc.File = r.file[:n:n]
if !isdup {
r.file = r.file[n:]
}
for i := 0; i < n; i++ {
pc.File[i] = r.readSymIndex()
}
cmd/compile,link: generate PC-value tables with inlining information In order to generate accurate tracebacks, the runtime needs to know the inlined call stack for a given PC. This creates two tables per function for this purpose. The first table is the inlining tree (stored in the function's funcdata), which has a node containing the file, line, and function name for every inlined call. The second table is a PC-value table that maps each PC to a node in the inlining tree (or -1 if the PC is not the result of inlining). To give the appearance that inlining hasn't happened, the runtime also needs the original source position information of inlined AST nodes. Previously the compiler plastered over the line numbers of inlined AST nodes with the line number of the call. This meant that the PC-line table mapped each PC to line number of the outermost call in its inlined call stack, with no way to access the innermost line number. Now the compiler retains line numbers of inlined AST nodes and writes the innermost source position information to the PC-line and PC-file tables. Some tools and tests expect to see outermost line numbers, so we provide the OutermostLine function for displaying line info. To keep track of the inlined call stack for an AST node, we extend the src.PosBase type with an index into a global inlining tree. Every time the compiler inlines a call, it creates a node in the global inlining tree for the call, and writes its index to the PosBase of every inlined AST node. The parent of this node is the inlining tree index of the call. -1 signifies no parent. For each function, the compiler creates a local inlining tree and a PC-value table mapping each PC to an index in the local tree. These are written to an object file, which is read by the linker. The linker re-encodes these tables compactly by deduplicating function names and file names. This change increases the size of binaries by 4-5%. For example, this is how the go1 benchmark binary is impacted by this change: section old bytes new bytes delta .text 3.49M ± 0% 3.49M ± 0% +0.06% .rodata 1.12M ± 0% 1.21M ± 0% +8.21% .gopclntab 1.50M ± 0% 1.68M ± 0% +11.89% .debug_line 338k ± 0% 435k ± 0% +28.78% Total 9.21M ± 0% 9.58M ± 0% +4.01% Updates #19348. Change-Id: Ic4f180c3b516018138236b0c35e0218270d957d3 Reviewed-on: https://go-review.googlesource.com/37231 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-02-17 12:28:05 -05:00
n = r.readInt()
pc.InlTree = make([]sym.InlinedCall, n)
cmd/compile,link: generate PC-value tables with inlining information In order to generate accurate tracebacks, the runtime needs to know the inlined call stack for a given PC. This creates two tables per function for this purpose. The first table is the inlining tree (stored in the function's funcdata), which has a node containing the file, line, and function name for every inlined call. The second table is a PC-value table that maps each PC to a node in the inlining tree (or -1 if the PC is not the result of inlining). To give the appearance that inlining hasn't happened, the runtime also needs the original source position information of inlined AST nodes. Previously the compiler plastered over the line numbers of inlined AST nodes with the line number of the call. This meant that the PC-line table mapped each PC to line number of the outermost call in its inlined call stack, with no way to access the innermost line number. Now the compiler retains line numbers of inlined AST nodes and writes the innermost source position information to the PC-line and PC-file tables. Some tools and tests expect to see outermost line numbers, so we provide the OutermostLine function for displaying line info. To keep track of the inlined call stack for an AST node, we extend the src.PosBase type with an index into a global inlining tree. Every time the compiler inlines a call, it creates a node in the global inlining tree for the call, and writes its index to the PosBase of every inlined AST node. The parent of this node is the inlining tree index of the call. -1 signifies no parent. For each function, the compiler creates a local inlining tree and a PC-value table mapping each PC to an index in the local tree. These are written to an object file, which is read by the linker. The linker re-encodes these tables compactly by deduplicating function names and file names. This change increases the size of binaries by 4-5%. For example, this is how the go1 benchmark binary is impacted by this change: section old bytes new bytes delta .text 3.49M ± 0% 3.49M ± 0% +0.06% .rodata 1.12M ± 0% 1.21M ± 0% +8.21% .gopclntab 1.50M ± 0% 1.68M ± 0% +11.89% .debug_line 338k ± 0% 435k ± 0% +28.78% Total 9.21M ± 0% 9.58M ± 0% +4.01% Updates #19348. Change-Id: Ic4f180c3b516018138236b0c35e0218270d957d3 Reviewed-on: https://go-review.googlesource.com/37231 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-02-17 12:28:05 -05:00
for i := 0; i < n; i++ {
pc.InlTree[i].Parent = r.readInt32()
pc.InlTree[i].File = r.readSymIndex()
pc.InlTree[i].Line = r.readInt32()
pc.InlTree[i].Func = r.readSymIndex().Name
pc.InlTree[i].ParentPC = r.readInt32()
cmd/compile,link: generate PC-value tables with inlining information In order to generate accurate tracebacks, the runtime needs to know the inlined call stack for a given PC. This creates two tables per function for this purpose. The first table is the inlining tree (stored in the function's funcdata), which has a node containing the file, line, and function name for every inlined call. The second table is a PC-value table that maps each PC to a node in the inlining tree (or -1 if the PC is not the result of inlining). To give the appearance that inlining hasn't happened, the runtime also needs the original source position information of inlined AST nodes. Previously the compiler plastered over the line numbers of inlined AST nodes with the line number of the call. This meant that the PC-line table mapped each PC to line number of the outermost call in its inlined call stack, with no way to access the innermost line number. Now the compiler retains line numbers of inlined AST nodes and writes the innermost source position information to the PC-line and PC-file tables. Some tools and tests expect to see outermost line numbers, so we provide the OutermostLine function for displaying line info. To keep track of the inlined call stack for an AST node, we extend the src.PosBase type with an index into a global inlining tree. Every time the compiler inlines a call, it creates a node in the global inlining tree for the call, and writes its index to the PosBase of every inlined AST node. The parent of this node is the inlining tree index of the call. -1 signifies no parent. For each function, the compiler creates a local inlining tree and a PC-value table mapping each PC to an index in the local tree. These are written to an object file, which is read by the linker. The linker re-encodes these tables compactly by deduplicating function names and file names. This change increases the size of binaries by 4-5%. For example, this is how the go1 benchmark binary is impacted by this change: section old bytes new bytes delta .text 3.49M ± 0% 3.49M ± 0% +0.06% .rodata 1.12M ± 0% 1.21M ± 0% +8.21% .gopclntab 1.50M ± 0% 1.68M ± 0% +11.89% .debug_line 338k ± 0% 435k ± 0% +28.78% Total 9.21M ± 0% 9.58M ± 0% +4.01% Updates #19348. Change-Id: Ic4f180c3b516018138236b0c35e0218270d957d3 Reviewed-on: https://go-review.googlesource.com/37231 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-02-17 12:28:05 -05:00
}
cmd/link: insert trampolines for too-far jumps on ARM ARM direct CALL/JMP instruction has 24 bit offset, which can only encodes jumps within +/-32M. When the target is too far, the top bits get truncated and the program jumps wild. This CL detects too-far jumps and automatically insert trampolines, currently only internal linking on ARM. It is necessary to make the following changes to the linker: - Resolve direct jump relocs when assigning addresses to functions. this allows trampoline insertion without moving all code that already laid down. - Lay down packages in dependency order, so that when resolving a inter-package direct jump reloc, the target address is already known. Intra-package jumps are assumed never too far. - a linker flag -debugtramp is added for debugging trampolines: "-debugtramp=1 -v" prints trampoline debug message "-debugtramp=2" forces all inter-package jump to use trampolines (currently ARM only) "-debugtramp=2 -v" does both - Some data structures are changed for bookkeeping. On ARM, pseudo DIV/DIVU/MOD/MODU instructions now clobber R8 (unfortunate). In the standard library there is no ARM assembly code that uses these instructions, and the compiler no longer emits them (CL 29390). all.bash passes with -debugtramp=2, except a disassembly test (this is unavoidable as we changed the instruction). TBD: debug info of trampolines? Fixes #17028. Change-Id: Idcce347ea7e0af77c4079041a160b2f6e114b474 Reviewed-on: https://go-review.googlesource.com/29397 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-09-14 14:47:12 -04:00
if !dupok {
if s.Attr.OnList() {
log.Fatalf("symbol %s listed multiple times", s.Name)
}
s.Attr |= sym.AttrOnList
r.lib.Textp = append(r.lib.Textp, s)
cmd/link: insert trampolines for too-far jumps on ARM ARM direct CALL/JMP instruction has 24 bit offset, which can only encodes jumps within +/-32M. When the target is too far, the top bits get truncated and the program jumps wild. This CL detects too-far jumps and automatically insert trampolines, currently only internal linking on ARM. It is necessary to make the following changes to the linker: - Resolve direct jump relocs when assigning addresses to functions. this allows trampoline insertion without moving all code that already laid down. - Lay down packages in dependency order, so that when resolving a inter-package direct jump reloc, the target address is already known. Intra-package jumps are assumed never too far. - a linker flag -debugtramp is added for debugging trampolines: "-debugtramp=1 -v" prints trampoline debug message "-debugtramp=2" forces all inter-package jump to use trampolines (currently ARM only) "-debugtramp=2 -v" does both - Some data structures are changed for bookkeeping. On ARM, pseudo DIV/DIVU/MOD/MODU instructions now clobber R8 (unfortunate). In the standard library there is no ARM assembly code that uses these instructions, and the compiler no longer emits them (CL 29390). all.bash passes with -debugtramp=2, except a disassembly test (this is unavoidable as we changed the instruction). TBD: debug info of trampolines? Fixes #17028. Change-Id: Idcce347ea7e0af77c4079041a160b2f6e114b474 Reviewed-on: https://go-review.googlesource.com/29397 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-09-14 14:47:12 -04:00
} else {
// there may ba a dup in another package
// put into a temp list and add to text later
if !isdup {
r.lib.DupTextSyms = append(r.lib.DupTextSyms, s)
cmd/link: insert trampolines for too-far jumps on ARM ARM direct CALL/JMP instruction has 24 bit offset, which can only encodes jumps within +/-32M. When the target is too far, the top bits get truncated and the program jumps wild. This CL detects too-far jumps and automatically insert trampolines, currently only internal linking on ARM. It is necessary to make the following changes to the linker: - Resolve direct jump relocs when assigning addresses to functions. this allows trampoline insertion without moving all code that already laid down. - Lay down packages in dependency order, so that when resolving a inter-package direct jump reloc, the target address is already known. Intra-package jumps are assumed never too far. - a linker flag -debugtramp is added for debugging trampolines: "-debugtramp=1 -v" prints trampoline debug message "-debugtramp=2" forces all inter-package jump to use trampolines (currently ARM only) "-debugtramp=2 -v" does both - Some data structures are changed for bookkeeping. On ARM, pseudo DIV/DIVU/MOD/MODU instructions now clobber R8 (unfortunate). In the standard library there is no ARM assembly code that uses these instructions, and the compiler no longer emits them (CL 29390). all.bash passes with -debugtramp=2, except a disassembly test (this is unavoidable as we changed the instruction). TBD: debug info of trampolines? Fixes #17028. Change-Id: Idcce347ea7e0af77c4079041a160b2f6e114b474 Reviewed-on: https://go-review.googlesource.com/29397 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-09-14 14:47:12 -04:00
} else {
r.lib.DupTextSyms = append(r.lib.DupTextSyms, dup)
cmd/link: insert trampolines for too-far jumps on ARM ARM direct CALL/JMP instruction has 24 bit offset, which can only encodes jumps within +/-32M. When the target is too far, the top bits get truncated and the program jumps wild. This CL detects too-far jumps and automatically insert trampolines, currently only internal linking on ARM. It is necessary to make the following changes to the linker: - Resolve direct jump relocs when assigning addresses to functions. this allows trampoline insertion without moving all code that already laid down. - Lay down packages in dependency order, so that when resolving a inter-package direct jump reloc, the target address is already known. Intra-package jumps are assumed never too far. - a linker flag -debugtramp is added for debugging trampolines: "-debugtramp=1 -v" prints trampoline debug message "-debugtramp=2" forces all inter-package jump to use trampolines (currently ARM only) "-debugtramp=2 -v" does both - Some data structures are changed for bookkeeping. On ARM, pseudo DIV/DIVU/MOD/MODU instructions now clobber R8 (unfortunate). In the standard library there is no ARM assembly code that uses these instructions, and the compiler no longer emits them (CL 29390). all.bash passes with -debugtramp=2, except a disassembly test (this is unavoidable as we changed the instruction). TBD: debug info of trampolines? Fixes #17028. Change-Id: Idcce347ea7e0af77c4079041a160b2f6e114b474 Reviewed-on: https://go-review.googlesource.com/29397 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-09-14 14:47:12 -04:00
}
}
}
if s.Type == sym.SDWARFINFO {
r.patchDWARFName(s)
}
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
if isdup && r.flags&(StrictDupsWarnFlag|StrictDupsErrFlag) != 0 {
// Compare the just-read symbol with the previously read
// symbol of the same name, verifying that they have the same
// payload. If not, issue a warning and possibly an error.
if !bytes.Equal(s.P, dup.P) {
reason := "same length but different contents"
if len(s.P) != len(dup.P) {
reason = fmt.Sprintf("new length %d != old length %d",
len(data), len(dup.P))
}
fmt.Fprintf(os.Stderr, "cmd/link: while reading object for '%v': duplicate symbol '%s', previous def at '%v', with mismatched payload: %s\n", r.lib, dup, dup.Unit.Lib, reason)
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
// For the moment, whitelist DWARF subprogram DIEs for
// auto-generated wrapper functions. What seems to happen
// here is that we get different line numbers on formal
// params; I am guessing that the pos is being inherited
// from the spot where the wrapper is needed.
whitelist := (strings.HasPrefix(dup.Name, "go.info.go.interface") ||
strings.HasPrefix(dup.Name, "go.info.go.builtin") ||
strings.HasPrefix(dup.Name, "go.isstmt.go.builtin") ||
strings.HasPrefix(dup.Name, "go.debuglines"))
if !whitelist {
r.strictDupMsgs++
cmd/link: add optional sanity checking for duplicate symbols Introduce a new linker command line option "-strictdups", which enables sanity checking of "ok to duplicate" symbols, especially DWARF info symbols. Acceptable values are 0 (no checking) 1 (issue warnings) and 2 (issue a fatal error checks fail). Currently if we read a DWARF symbol (such as "go.info.PKG.FUNCTION") from one object file, and then encounter the same symbol later on while reading another object file, we simply discard the second one and move on with the link, since the two should in theory be identical. If as a result of a compiler bug we wind up with symbols that are not identical, this tends to (silently) result in incorrect DWARF generation, which may or may not be discovered depending on who is consuming the DWARF and what's being done with it. When this option is turned on, at the point where a duplicate symbol is detected in the object file reader, we check to make sure that the length/contents of the symbol are the same as the previously read symbol, and print a descriptive warning (or error) if not. For the time being this can be used for one-off testing to find problems; at some point it would be nice if we can enable it by default. Updates #30908. Change-Id: I64c4e07c326b4572db674ff17c93307e2eec607c Reviewed-on: https://go-review.googlesource.com/c/go/+/168410 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-03-21 09:20:11 -04:00
}
}
}
}
func (r *objReader) patchDWARFName(s *sym.Symbol) {
// This is kind of ugly. Really the package name should not
// even be included here.
if s.Size < 1 || s.P[0] != dwarf.DW_ABRV_FUNCTION {
return
}
e := bytes.IndexByte(s.P, 0)
if e == -1 {
return
}
p := bytes.Index(s.P[:e], emptyPkg)
if p == -1 {
return
}
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
pkgprefix := []byte(r.pkgpref)
patched := bytes.Replace(s.P[:e], emptyPkg, pkgprefix, -1)
s.P = append(patched, s.P[e:]...)
delta := int64(len(s.P)) - s.Size
s.Size = int64(len(s.P))
for i := range s.R {
r := &s.R[i]
if r.Off > int32(e) {
r.Off += int32(delta)
}
}
}
func (r *objReader) readFull(b []byte) {
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
if r.roObject != nil {
copy(b, r.roObject[r.roOffset:])
r.roOffset += int64(len(b))
return
}
_, err := io.ReadFull(r.rd, b)
if err != nil {
log.Fatalf("%s: error reading %s", r.pn, err)
}
}
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
func (r *objReader) readByte() (byte, error) {
if r.roObject != nil {
b := r.roObject[r.roOffset]
r.roOffset++
return b, nil
}
return r.rd.ReadByte()
}
func (r *objReader) peek(n int) ([]byte, error) {
if r.roObject != nil {
return r.roObject[r.roOffset : r.roOffset+int64(n)], nil
}
return r.rd.Peek(n)
}
func (r *objReader) readRef() {
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
if c, err := r.readByte(); c != symPrefix || err != nil {
log.Fatalf("readSym out of sync")
}
name := r.readSymName()
var v int
if abi := r.readInt(); abi == -1 {
// Static
v = r.localSymVersion
} else if abiver := sym.ABIToVersion(obj.ABI(abi)); abiver != -1 {
// Note that data symbols are "ABI0", which maps to version 0.
v = abiver
} else {
log.Fatalf("invalid symbol ABI for %q: %d", name, abi)
}
s := r.syms.Lookup(name, v)
r.refs = append(r.refs, s)
if s == nil || v == r.localSymVersion {
return
}
if s.Name[0] == '$' && len(s.Name) > 5 && s.Type == 0 && len(s.P) == 0 {
x, err := strconv.ParseUint(s.Name[5:], 16, 64)
if err != nil {
log.Panicf("failed to parse $-symbol %s: %v", s.Name, err)
}
s.Type = sym.SRODATA
s.Attr |= sym.AttrLocal
switch s.Name[:5] {
case "$f32.":
if uint64(uint32(x)) != x {
log.Panicf("$-symbol %s too large: %d", s.Name, x)
}
s.AddUint32(r.arch, uint32(x))
case "$f64.", "$i64.":
s.AddUint64(r.arch, x)
default:
log.Panicf("unrecognized $-symbol: %s", s.Name)
}
s.Attr.Set(sym.AttrReachable, false)
}
if strings.HasPrefix(s.Name, "runtime.gcbits.") {
s.Attr |= sym.AttrLocal
}
}
func (r *objReader) readInt64() int64 {
uv := uint64(0)
for shift := uint(0); ; shift += 7 {
if shift >= 64 {
log.Fatalf("corrupt input")
}
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
c, err := r.readByte()
if err != nil {
log.Fatalln("error reading input: ", err)
}
uv |= uint64(c&0x7F) << shift
if c&0x80 == 0 {
break
}
}
return int64(uv>>1) ^ (int64(uv<<63) >> 63)
}
func (r *objReader) readInt() int {
n := r.readInt64()
if int64(int(n)) != n {
log.Panicf("%v out of range for int", n)
}
return int(n)
}
func (r *objReader) readInt32() int32 {
n := r.readInt64()
if int64(int32(n)) != n {
log.Panicf("%v out of range for int32", n)
}
return int32(n)
}
func (r *objReader) readInt16() int16 {
n := r.readInt64()
if int64(int16(n)) != n {
log.Panicf("%v out of range for int16", n)
}
return int16(n)
}
func (r *objReader) readUint8() uint8 {
n := r.readInt64()
if int64(uint8(n)) != n {
log.Panicf("%v out of range for uint8", n)
}
return uint8(n)
}
func (r *objReader) readString() string {
n := r.readInt()
if cap(r.rdBuf) < n {
r.rdBuf = make([]byte, 2*n)
}
r.readFull(r.rdBuf[:n])
return string(r.rdBuf[:n])
}
func (r *objReader) readData() []byte {
n := r.readInt()
p := r.data[:n:n]
r.data = r.data[n:]
return p
}
type stringHeader struct {
str unsafe.Pointer
len int
}
func mkROString(rodata []byte) string {
if len(rodata) == 0 {
return ""
}
ss := stringHeader{str: unsafe.Pointer(&rodata[0]), len: len(rodata)}
s := *(*string)(unsafe.Pointer(&ss))
return s
}
// readSymName reads a symbol name, replacing all "". with pkg.
func (r *objReader) readSymName() string {
n := r.readInt()
if n == 0 {
r.readInt64()
return ""
}
if cap(r.rdBuf) < n {
r.rdBuf = make([]byte, 2*n)
cmd/link: simplify readSymName, taking advantage of bufio.Reader Now that cmd/link uses bufio.Reader, take advantage of it. I find this new version easier to reason about. Reduces allocations by 1.1% when linking a basic HTTP server. Numbers are stable with each round measuring using: rm prof.mem; go tool link -o foo -memprofile=prof.mem -memprofilerate=1 foo.a Before: 65.36MB of 74.53MB total (87.70%) Dropped 157 nodes (cum <= 0.37MB) Showing top 10 nodes out of 39 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 28.81% 28.81% 21.48MB 28.81% cmd/link/internal/ld.Linklookup 16.04MB 21.52% 50.33% 16.04MB 21.52% cmd/link/internal/ld.(*objReader).readSlices 4.61MB 6.19% 56.52% 4.61MB 6.19% cmd/link/internal/ld.(*objReader).readSymName 4.51MB 6.05% 62.57% 6.32MB 8.48% cmd/link/internal/ld.writelines 4.50MB 6.03% 68.60% 4.50MB 6.03% cmd/link/internal/ld.Symgrow 4.02MB 5.39% 73.99% 4.02MB 5.39% cmd/link/internal/ld.linknew 3.98MB 5.34% 79.33% 3.98MB 5.34% cmd/link/internal/ld.setaddrplus 2.96MB 3.97% 83.30% 28.78MB 38.62% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.43% 85.73% 1.81MB 2.43% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.97% 87.70% 1.47MB 1.97% cmd/link/internal/ld.(*objReader).readSym After: 64.66MB of 73.87MB total (87.53%) Dropped 156 nodes (cum <= 0.37MB) Showing top 10 nodes out of 40 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 29.08% 29.08% 21.48MB 29.08% cmd/link/internal/ld.Linklookup 16.04MB 21.71% 50.79% 16.04MB 21.71% cmd/link/internal/ld.(*objReader).readSlices 4.51MB 6.10% 56.90% 6.32MB 8.56% cmd/link/internal/ld.writelines 4.50MB 6.09% 62.99% 4.50MB 6.09% cmd/link/internal/ld.Symgrow 4.02MB 5.44% 68.42% 4.02MB 5.44% cmd/link/internal/ld.linknew 3.98MB 5.38% 73.81% 3.98MB 5.38% cmd/link/internal/ld.setaddrplus 3.90MB 5.28% 79.09% 3.90MB 5.28% cmd/link/internal/ld.(*objReader).readSymName 2.96MB 4.01% 83.09% 28.08MB 38.01% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.45% 85.55% 1.81MB 2.45% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.99% 87.53% 1.47MB 1.99% cmd/link/internal/ld.(*objReader).readSym Also tested locally with asserts that that the calculated length is always correct and thus the adjName buf never reallocates. Change-Id: I19e3e8bfa6a12bcd8b5216f6232f42c122e4f80e Reviewed-on: https://go-review.googlesource.com/21481 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-04-03 18:27:17 +00:00
}
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
sOffset := r.roOffset
origName, err := r.peek(n)
if err == bufio.ErrBufferFull {
// Long symbol names are rare but exist. One source is type
// symbols for types with long string forms. See #15104.
origName = make([]byte, n)
r.readFull(origName)
} else if err != nil {
log.Fatalf("%s: error reading symbol: %v", r.pn, err)
}
cmd/link: simplify readSymName, taking advantage of bufio.Reader Now that cmd/link uses bufio.Reader, take advantage of it. I find this new version easier to reason about. Reduces allocations by 1.1% when linking a basic HTTP server. Numbers are stable with each round measuring using: rm prof.mem; go tool link -o foo -memprofile=prof.mem -memprofilerate=1 foo.a Before: 65.36MB of 74.53MB total (87.70%) Dropped 157 nodes (cum <= 0.37MB) Showing top 10 nodes out of 39 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 28.81% 28.81% 21.48MB 28.81% cmd/link/internal/ld.Linklookup 16.04MB 21.52% 50.33% 16.04MB 21.52% cmd/link/internal/ld.(*objReader).readSlices 4.61MB 6.19% 56.52% 4.61MB 6.19% cmd/link/internal/ld.(*objReader).readSymName 4.51MB 6.05% 62.57% 6.32MB 8.48% cmd/link/internal/ld.writelines 4.50MB 6.03% 68.60% 4.50MB 6.03% cmd/link/internal/ld.Symgrow 4.02MB 5.39% 73.99% 4.02MB 5.39% cmd/link/internal/ld.linknew 3.98MB 5.34% 79.33% 3.98MB 5.34% cmd/link/internal/ld.setaddrplus 2.96MB 3.97% 83.30% 28.78MB 38.62% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.43% 85.73% 1.81MB 2.43% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.97% 87.70% 1.47MB 1.97% cmd/link/internal/ld.(*objReader).readSym After: 64.66MB of 73.87MB total (87.53%) Dropped 156 nodes (cum <= 0.37MB) Showing top 10 nodes out of 40 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 29.08% 29.08% 21.48MB 29.08% cmd/link/internal/ld.Linklookup 16.04MB 21.71% 50.79% 16.04MB 21.71% cmd/link/internal/ld.(*objReader).readSlices 4.51MB 6.10% 56.90% 6.32MB 8.56% cmd/link/internal/ld.writelines 4.50MB 6.09% 62.99% 4.50MB 6.09% cmd/link/internal/ld.Symgrow 4.02MB 5.44% 68.42% 4.02MB 5.44% cmd/link/internal/ld.linknew 3.98MB 5.38% 73.81% 3.98MB 5.38% cmd/link/internal/ld.setaddrplus 3.90MB 5.28% 79.09% 3.90MB 5.28% cmd/link/internal/ld.(*objReader).readSymName 2.96MB 4.01% 83.09% 28.08MB 38.01% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.45% 85.55% 1.81MB 2.45% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.99% 87.53% 1.47MB 1.99% cmd/link/internal/ld.(*objReader).readSym Also tested locally with asserts that that the calculated length is always correct and thus the adjName buf never reallocates. Change-Id: I19e3e8bfa6a12bcd8b5216f6232f42c122e4f80e Reviewed-on: https://go-review.googlesource.com/21481 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-04-03 18:27:17 +00:00
adjName := r.rdBuf[:0]
nPkgRefs := 0
for {
i := bytes.Index(origName, emptyPkg)
if i == -1 {
var s string
if r.roObject != nil && nPkgRefs == 0 {
s = mkROString(r.roObject[sOffset : sOffset+int64(n)])
} else {
s = string(append(adjName, origName...))
}
cmd/link: simplify readSymName, taking advantage of bufio.Reader Now that cmd/link uses bufio.Reader, take advantage of it. I find this new version easier to reason about. Reduces allocations by 1.1% when linking a basic HTTP server. Numbers are stable with each round measuring using: rm prof.mem; go tool link -o foo -memprofile=prof.mem -memprofilerate=1 foo.a Before: 65.36MB of 74.53MB total (87.70%) Dropped 157 nodes (cum <= 0.37MB) Showing top 10 nodes out of 39 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 28.81% 28.81% 21.48MB 28.81% cmd/link/internal/ld.Linklookup 16.04MB 21.52% 50.33% 16.04MB 21.52% cmd/link/internal/ld.(*objReader).readSlices 4.61MB 6.19% 56.52% 4.61MB 6.19% cmd/link/internal/ld.(*objReader).readSymName 4.51MB 6.05% 62.57% 6.32MB 8.48% cmd/link/internal/ld.writelines 4.50MB 6.03% 68.60% 4.50MB 6.03% cmd/link/internal/ld.Symgrow 4.02MB 5.39% 73.99% 4.02MB 5.39% cmd/link/internal/ld.linknew 3.98MB 5.34% 79.33% 3.98MB 5.34% cmd/link/internal/ld.setaddrplus 2.96MB 3.97% 83.30% 28.78MB 38.62% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.43% 85.73% 1.81MB 2.43% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.97% 87.70% 1.47MB 1.97% cmd/link/internal/ld.(*objReader).readSym After: 64.66MB of 73.87MB total (87.53%) Dropped 156 nodes (cum <= 0.37MB) Showing top 10 nodes out of 40 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 29.08% 29.08% 21.48MB 29.08% cmd/link/internal/ld.Linklookup 16.04MB 21.71% 50.79% 16.04MB 21.71% cmd/link/internal/ld.(*objReader).readSlices 4.51MB 6.10% 56.90% 6.32MB 8.56% cmd/link/internal/ld.writelines 4.50MB 6.09% 62.99% 4.50MB 6.09% cmd/link/internal/ld.Symgrow 4.02MB 5.44% 68.42% 4.02MB 5.44% cmd/link/internal/ld.linknew 3.98MB 5.38% 73.81% 3.98MB 5.38% cmd/link/internal/ld.setaddrplus 3.90MB 5.28% 79.09% 3.90MB 5.28% cmd/link/internal/ld.(*objReader).readSymName 2.96MB 4.01% 83.09% 28.08MB 38.01% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.45% 85.55% 1.81MB 2.45% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.99% 87.53% 1.47MB 1.99% cmd/link/internal/ld.(*objReader).readSym Also tested locally with asserts that that the calculated length is always correct and thus the adjName buf never reallocates. Change-Id: I19e3e8bfa6a12bcd8b5216f6232f42c122e4f80e Reviewed-on: https://go-review.googlesource.com/21481 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-04-03 18:27:17 +00:00
// Read past the peeked origName, now that we're done with it,
// using the rfBuf (also no longer used) as the scratch space.
// TODO: use bufio.Reader.Discard if available instead?
if err == nil {
r.readFull(r.rdBuf[:n])
}
r.rdBuf = adjName[:0] // in case 2*n wasn't enough
cmd/link: simplify readSymName, taking advantage of bufio.Reader Now that cmd/link uses bufio.Reader, take advantage of it. I find this new version easier to reason about. Reduces allocations by 1.1% when linking a basic HTTP server. Numbers are stable with each round measuring using: rm prof.mem; go tool link -o foo -memprofile=prof.mem -memprofilerate=1 foo.a Before: 65.36MB of 74.53MB total (87.70%) Dropped 157 nodes (cum <= 0.37MB) Showing top 10 nodes out of 39 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 28.81% 28.81% 21.48MB 28.81% cmd/link/internal/ld.Linklookup 16.04MB 21.52% 50.33% 16.04MB 21.52% cmd/link/internal/ld.(*objReader).readSlices 4.61MB 6.19% 56.52% 4.61MB 6.19% cmd/link/internal/ld.(*objReader).readSymName 4.51MB 6.05% 62.57% 6.32MB 8.48% cmd/link/internal/ld.writelines 4.50MB 6.03% 68.60% 4.50MB 6.03% cmd/link/internal/ld.Symgrow 4.02MB 5.39% 73.99% 4.02MB 5.39% cmd/link/internal/ld.linknew 3.98MB 5.34% 79.33% 3.98MB 5.34% cmd/link/internal/ld.setaddrplus 2.96MB 3.97% 83.30% 28.78MB 38.62% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.43% 85.73% 1.81MB 2.43% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.97% 87.70% 1.47MB 1.97% cmd/link/internal/ld.(*objReader).readSym After: 64.66MB of 73.87MB total (87.53%) Dropped 156 nodes (cum <= 0.37MB) Showing top 10 nodes out of 40 (cum >= 1.47MB) flat flat% sum% cum cum% 21.48MB 29.08% 29.08% 21.48MB 29.08% cmd/link/internal/ld.Linklookup 16.04MB 21.71% 50.79% 16.04MB 21.71% cmd/link/internal/ld.(*objReader).readSlices 4.51MB 6.10% 56.90% 6.32MB 8.56% cmd/link/internal/ld.writelines 4.50MB 6.09% 62.99% 4.50MB 6.09% cmd/link/internal/ld.Symgrow 4.02MB 5.44% 68.42% 4.02MB 5.44% cmd/link/internal/ld.linknew 3.98MB 5.38% 73.81% 3.98MB 5.38% cmd/link/internal/ld.setaddrplus 3.90MB 5.28% 79.09% 3.90MB 5.28% cmd/link/internal/ld.(*objReader).readSymName 2.96MB 4.01% 83.09% 28.08MB 38.01% cmd/link/internal/ld.(*objReader).readRef 1.81MB 2.45% 85.55% 1.81MB 2.45% cmd/link/internal/ld.newcfaoffsetattr 1.47MB 1.99% 87.53% 1.47MB 1.99% cmd/link/internal/ld.(*objReader).readSym Also tested locally with asserts that that the calculated length is always correct and thus the adjName buf never reallocates. Change-Id: I19e3e8bfa6a12bcd8b5216f6232f42c122e4f80e Reviewed-on: https://go-review.googlesource.com/21481 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-04-03 18:27:17 +00:00
return s
}
nPkgRefs++
adjName = append(adjName, origName[:i]...)
cmd/link: fix link time regression in object file reading In CL 173938, the linker's object file reader was switched over to selectively create strings backed with read-only mmap'd memory. In the process a call to r.rd.Offset() was added to readSymName(), which greatly increased the number of system calls (Offset does a seek system call). This patch changes the object file reader so that all reads are done directly from the mmap'd data if it is present, and adds logic to keep track of the offset within the rodata consumed so far. Doing this gets rid of the calls to r.rd.Offset() and the corresponding seek system calls. Also as part of this change, hoist the calls to objabi.PathToPrefix up into the initial setup code for object reading, and store the result in the reader (since objabi.PathToPrefix was also coming up as hot in the profile). Numbers for this change from compilebench: benchmark old ns/op new ns/op delta BenchmarkTemplate 172053975 170357597 -0.99% BenchmarkUnicode 64564850 64333653 -0.36% BenchmarkGoTypes 627931042 628043673 +0.02% BenchmarkCompiler 2982468893 2924575043 -1.94% BenchmarkSSA 9701681721 9799342557 +1.01% BenchmarkFlate 106847240 107509414 +0.62% BenchmarkGoParser 132082319 130734905 -1.02% BenchmarkReflect 386810586 383036621 -0.98% BenchmarkTar 154360072 152670594 -1.09% BenchmarkXML 217725693 216858727 -0.40% BenchmarkLinkCompiler 908813802 734363234 -19.20% BenchmarkStdCmd 32378532486 31222542974 -3.57% Fixes #31898. Change-Id: Ibf253a52ce9213325f42b1c2b20d0410f5c88c3b Reviewed-on: https://go-review.googlesource.com/c/go/+/176039 Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-05-08 15:44:49 -04:00
adjName = append(adjName, r.pkgpref[:len(r.pkgpref)-1]...)
adjName = append(adjName, '.')
origName = origName[i+len(emptyPkg):]
}
}
// Reads the index of a symbol reference and resolves it to a symbol
func (r *objReader) readSymIndex() *sym.Symbol {
i := r.readInt()
return r.refs[i]
}