2016-03-01 22:57:46 +00:00
|
|
|
// Copyright 2013 The Go Authors. All rights reserved.
|
2015-01-19 14:34:58 -05:00
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
2015-03-05 13:57:36 -05:00
|
|
|
// Writing of Go object files.
|
|
|
|
|
|
2015-01-19 14:34:58 -05:00
|
|
|
package obj
|
|
|
|
|
|
|
|
|
|
import (
|
2016-03-31 12:59:05 +03:00
|
|
|
"bufio"
|
2016-07-28 13:04:41 -04:00
|
|
|
"cmd/internal/dwarf"
|
2017-04-18 12:53:25 -07:00
|
|
|
"cmd/internal/objabi"
|
2016-04-06 12:01:40 -07:00
|
|
|
"cmd/internal/sys"
|
2015-01-19 14:34:58 -05:00
|
|
|
"fmt"
|
|
|
|
|
"log"
|
|
|
|
|
"path/filepath"
|
2016-03-13 10:13:03 -07:00
|
|
|
"sort"
|
cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object
file, it uses "". for the package path of the package being
compiled. This is then expanded in the linker to the actual
package path.
With CL 173938, it does not need an allocation if the symbol name
does not need expansion. In many cases, the compiler actually
knows the package path (through the -p flag), so we could just
write it out in compile time, without fixing it up in the linker.
This reduces allocations in the linker.
In case that the package path is not known (compiler's -p flag is
missing, or the object file is generated by the assembler), the
linker still does the expansion.
This reduces ~100MB allocations (~10% inuse_space) in linking
k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64.
Also makes the linker a little faster: linking cmd/go on
Linux/AMD64:
Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10)
User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10)
Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10)
The caveat is that the object files get slightly bigger. On
Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa
(which has a longer import path) gets 2.8% bigger.
This reveals that when building an unnamed plugin (e.g.
go build -buildmode=plugin x.go), the go command passes different
package paths to the compiler and to the linker. Before this CL
there seems nothing obviously broken, but given that the compiler
already emits the package's import path in various places (e.g.
debug info), I guess it is possible that this leads to some
unexpected behavior. Now that the compiler writes the package
path in more places, this disagreement actually leads to
unresolved symbols. Adjust the go command to use the same package
path for both compiling and linking.
Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/174657
Reviewed-by: Austin Clements <austin@google.com>
2019-04-30 20:47:48 -04:00
|
|
|
"strings"
|
2017-10-06 11:32:28 -04:00
|
|
|
"sync"
|
2015-01-19 14:34:58 -05:00
|
|
|
)
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// objWriter writes Go object files.
|
|
|
|
|
type objWriter struct {
|
|
|
|
|
wr *bufio.Writer
|
|
|
|
|
ctxt *Link
|
|
|
|
|
// Temporary buffer for zigzag int writing.
|
|
|
|
|
varintbuf [10]uint8
|
|
|
|
|
|
|
|
|
|
// Number of objects written of each type.
|
|
|
|
|
nRefs int
|
|
|
|
|
nData int
|
|
|
|
|
nReloc int
|
|
|
|
|
nPcdata int
|
|
|
|
|
nAutom int
|
|
|
|
|
nFuncdata int
|
|
|
|
|
nFile int
|
cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object
file, it uses "". for the package path of the package being
compiled. This is then expanded in the linker to the actual
package path.
With CL 173938, it does not need an allocation if the symbol name
does not need expansion. In many cases, the compiler actually
knows the package path (through the -p flag), so we could just
write it out in compile time, without fixing it up in the linker.
This reduces allocations in the linker.
In case that the package path is not known (compiler's -p flag is
missing, or the object file is generated by the assembler), the
linker still does the expansion.
This reduces ~100MB allocations (~10% inuse_space) in linking
k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64.
Also makes the linker a little faster: linking cmd/go on
Linux/AMD64:
Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10)
User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10)
Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10)
The caveat is that the object files get slightly bigger. On
Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa
(which has a longer import path) gets 2.8% bigger.
This reveals that when building an unnamed plugin (e.g.
go build -buildmode=plugin x.go), the go command passes different
package paths to the compiler and to the linker. Before this CL
there seems nothing obviously broken, but given that the compiler
already emits the package's import path in various places (e.g.
debug info), I guess it is possible that this leads to some
unexpected behavior. Now that the compiler writes the package
path in more places, this disagreement actually leads to
unresolved symbols. Adjust the go command to use the same package
path for both compiling and linking.
Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/174657
Reviewed-by: Austin Clements <austin@google.com>
2019-04-30 20:47:48 -04:00
|
|
|
|
|
|
|
|
pkgpath string // the package import path (escaped), "" if unknown
|
2016-03-23 00:44:07 +02:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) addLengths(s *LSym) {
|
|
|
|
|
w.nData += len(s.P)
|
|
|
|
|
w.nReloc += len(s.R)
|
2016-03-23 00:44:07 +02:00
|
|
|
|
2017-04-18 12:53:25 -07:00
|
|
|
if s.Type != objabi.STEXT {
|
2016-03-23 00:44:07 +02:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-18 10:18:34 -07:00
|
|
|
pc := &s.Func.Pcln
|
2016-03-23 00:44:07 +02:00
|
|
|
|
|
|
|
|
data := 0
|
|
|
|
|
data += len(pc.Pcsp.P)
|
|
|
|
|
data += len(pc.Pcfile.P)
|
|
|
|
|
data += len(pc.Pcline.P)
|
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
|
|
|
data += len(pc.Pcinline.P)
|
2018-04-05 12:11:32 +01:00
|
|
|
for _, pcd := range pc.Pcdata {
|
|
|
|
|
data += len(pcd.P)
|
2016-03-23 00:44:07 +02:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
w.nData += data
|
|
|
|
|
w.nPcdata += len(pc.Pcdata)
|
2016-03-23 00:44:07 +02:00
|
|
|
|
2017-04-18 10:18:34 -07:00
|
|
|
w.nAutom += len(s.Func.Autom)
|
2016-03-31 12:59:05 +03:00
|
|
|
w.nFuncdata += len(pc.Funcdataoff)
|
|
|
|
|
w.nFile += len(pc.File)
|
2016-03-23 00:44:07 +02:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeLengths() {
|
|
|
|
|
w.writeInt(int64(w.nData))
|
|
|
|
|
w.writeInt(int64(w.nReloc))
|
|
|
|
|
w.writeInt(int64(w.nPcdata))
|
|
|
|
|
w.writeInt(int64(w.nAutom))
|
|
|
|
|
w.writeInt(int64(w.nFuncdata))
|
|
|
|
|
w.writeInt(int64(w.nFile))
|
2016-03-23 00:44:07 +02:00
|
|
|
}
|
|
|
|
|
|
cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object
file, it uses "". for the package path of the package being
compiled. This is then expanded in the linker to the actual
package path.
With CL 173938, it does not need an allocation if the symbol name
does not need expansion. In many cases, the compiler actually
knows the package path (through the -p flag), so we could just
write it out in compile time, without fixing it up in the linker.
This reduces allocations in the linker.
In case that the package path is not known (compiler's -p flag is
missing, or the object file is generated by the assembler), the
linker still does the expansion.
This reduces ~100MB allocations (~10% inuse_space) in linking
k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64.
Also makes the linker a little faster: linking cmd/go on
Linux/AMD64:
Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10)
User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10)
Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10)
The caveat is that the object files get slightly bigger. On
Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa
(which has a longer import path) gets 2.8% bigger.
This reveals that when building an unnamed plugin (e.g.
go build -buildmode=plugin x.go), the go command passes different
package paths to the compiler and to the linker. Before this CL
there seems nothing obviously broken, but given that the compiler
already emits the package's import path in various places (e.g.
debug info), I guess it is possible that this leads to some
unexpected behavior. Now that the compiler writes the package
path in more places, this disagreement actually leads to
unresolved symbols. Adjust the go command to use the same package
path for both compiling and linking.
Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/174657
Reviewed-by: Austin Clements <austin@google.com>
2019-04-30 20:47:48 -04:00
|
|
|
func newObjWriter(ctxt *Link, b *bufio.Writer, pkgpath string) *objWriter {
|
2016-03-31 12:59:05 +03:00
|
|
|
return &objWriter{
|
cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object
file, it uses "". for the package path of the package being
compiled. This is then expanded in the linker to the actual
package path.
With CL 173938, it does not need an allocation if the symbol name
does not need expansion. In many cases, the compiler actually
knows the package path (through the -p flag), so we could just
write it out in compile time, without fixing it up in the linker.
This reduces allocations in the linker.
In case that the package path is not known (compiler's -p flag is
missing, or the object file is generated by the assembler), the
linker still does the expansion.
This reduces ~100MB allocations (~10% inuse_space) in linking
k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64.
Also makes the linker a little faster: linking cmd/go on
Linux/AMD64:
Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10)
User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10)
Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10)
The caveat is that the object files get slightly bigger. On
Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa
(which has a longer import path) gets 2.8% bigger.
This reveals that when building an unnamed plugin (e.g.
go build -buildmode=plugin x.go), the go command passes different
package paths to the compiler and to the linker. Before this CL
there seems nothing obviously broken, but given that the compiler
already emits the package's import path in various places (e.g.
debug info), I guess it is possible that this leads to some
unexpected behavior. Now that the compiler writes the package
path in more places, this disagreement actually leads to
unresolved symbols. Adjust the go command to use the same package
path for both compiling and linking.
Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/174657
Reviewed-by: Austin Clements <austin@google.com>
2019-04-30 20:47:48 -04:00
|
|
|
ctxt: ctxt,
|
|
|
|
|
wr: b,
|
|
|
|
|
pkgpath: objabi.PathToPrefix(pkgpath),
|
2016-03-31 12:59:05 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object
file, it uses "". for the package path of the package being
compiled. This is then expanded in the linker to the actual
package path.
With CL 173938, it does not need an allocation if the symbol name
does not need expansion. In many cases, the compiler actually
knows the package path (through the -p flag), so we could just
write it out in compile time, without fixing it up in the linker.
This reduces allocations in the linker.
In case that the package path is not known (compiler's -p flag is
missing, or the object file is generated by the assembler), the
linker still does the expansion.
This reduces ~100MB allocations (~10% inuse_space) in linking
k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64.
Also makes the linker a little faster: linking cmd/go on
Linux/AMD64:
Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10)
User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10)
Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10)
The caveat is that the object files get slightly bigger. On
Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa
(which has a longer import path) gets 2.8% bigger.
This reveals that when building an unnamed plugin (e.g.
go build -buildmode=plugin x.go), the go command passes different
package paths to the compiler and to the linker. Before this CL
there seems nothing obviously broken, but given that the compiler
already emits the package's import path in various places (e.g.
debug info), I guess it is possible that this leads to some
unexpected behavior. Now that the compiler writes the package
path in more places, this disagreement actually leads to
unresolved symbols. Adjust the go command to use the same package
path for both compiling and linking.
Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/174657
Reviewed-by: Austin Clements <austin@google.com>
2019-04-30 20:47:48 -04:00
|
|
|
func WriteObjFile(ctxt *Link, b *bufio.Writer, pkgpath string) {
|
|
|
|
|
w := newObjWriter(ctxt, b, pkgpath)
|
2015-01-19 14:34:58 -05:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Magic header
|
2018-10-26 13:53:02 -04:00
|
|
|
w.wr.WriteString("\x00go112ld")
|
2015-01-19 14:34:58 -05:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Version
|
|
|
|
|
w.wr.WriteByte(1)
|
|
|
|
|
|
|
|
|
|
// Autolib
|
2015-03-08 22:41:48 -04:00
|
|
|
for _, pkg := range ctxt.Imports {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeString(pkg)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeString("")
|
2016-03-23 00:44:07 +02:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Symbol references
|
2016-03-14 21:51:09 -07:00
|
|
|
for _, s := range ctxt.Text {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRefs(s)
|
|
|
|
|
w.addLengths(s)
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
2018-11-23 14:20:19 +01:00
|
|
|
|
|
|
|
|
if ctxt.Headtype == objabi.Haix {
|
|
|
|
|
// Data must be sorted to keep a constant order in TOC symbols.
|
|
|
|
|
// As they are created during Progedit, two symbols can be switched between
|
|
|
|
|
// two different compilations. Therefore, BuildID will be different.
|
|
|
|
|
// TODO: find a better place and optimize to only sort TOC symbols
|
2019-04-30 15:23:14 -04:00
|
|
|
sort.Slice(ctxt.Data, func(i, j int) bool {
|
2018-11-23 14:20:19 +01:00
|
|
|
return ctxt.Data[i].Name < ctxt.Data[j].Name
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-14 21:51:09 -07:00
|
|
|
for _, s := range ctxt.Data {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRefs(s)
|
|
|
|
|
w.addLengths(s)
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
2018-10-26 13:53:02 -04:00
|
|
|
for _, s := range ctxt.ABIAliases {
|
|
|
|
|
w.writeRefs(s)
|
|
|
|
|
w.addLengths(s)
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
// End symbol references
|
|
|
|
|
w.wr.WriteByte(0xff)
|
2016-03-14 22:57:58 +02:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Lengths
|
|
|
|
|
w.writeLengths()
|
2016-03-23 00:44:07 +02:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Data block
|
2016-03-21 10:55:20 +13:00
|
|
|
for _, s := range ctxt.Text {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.wr.Write(s.P)
|
2017-04-18 10:18:34 -07:00
|
|
|
pc := &s.Func.Pcln
|
2016-03-31 12:59:05 +03:00
|
|
|
w.wr.Write(pc.Pcsp.P)
|
|
|
|
|
w.wr.Write(pc.Pcfile.P)
|
|
|
|
|
w.wr.Write(pc.Pcline.P)
|
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
|
|
|
w.wr.Write(pc.Pcinline.P)
|
2018-04-05 12:11:32 +01:00
|
|
|
for _, pcd := range pc.Pcdata {
|
|
|
|
|
w.wr.Write(pcd.P)
|
2016-03-21 10:55:20 +13:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
for _, s := range ctxt.Data {
|
cmd/internal/obj: fix LSym.Type during compilation, not linking
Prior to this CL, the compiler and assembler
were sloppy about the LSym.Type for LSyms
containing static data.
The linker then fixed this up, converting
Sxxx and SBSS to SDATA, and SNOPTRBSS to SNOPTRDATA
if it noticed that the symbol had associated data.
It is preferable to just get this right in cmd/compile
and cmd/asm, because it removes an unnecessary traversal
of the symbol table from the linker (see #14624).
Do this by touching up the LSym.Type fixes in
LSym.prepwrite and Link.Globl.
I have confirmed by instrumenting the linker
that the now-eliminated code paths were unreached.
And an additional check in the object file writing code
will help preserve that invariant.
There was a case in the Windows linker,
with internal linking and cgo,
where we were generating SNOPTRBSS symbols with data.
For now, convert those at the site at which they occur
into SNOPTRDATA, just like they were.
Does not pass toolstash-check,
but does generate identical linked binaries.
No compiler performance changes.
Change-Id: I77b071ab103685ff8e042cee9abb864385488872
Reviewed-on: https://go-review.googlesource.com/40864
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
2017-04-16 08:22:44 -07:00
|
|
|
if len(s.P) > 0 {
|
|
|
|
|
switch s.Type {
|
|
|
|
|
case objabi.SBSS, objabi.SNOPTRBSS, objabi.STLSBSS:
|
|
|
|
|
ctxt.Diag("cannot provide data for %v sym %v", s.Type, s.Name)
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
w.wr.Write(s.P)
|
2016-03-21 10:55:20 +13:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Symbols
|
2016-03-14 21:51:09 -07:00
|
|
|
for _, s := range ctxt.Text {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeSym(s)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-03-14 21:51:09 -07:00
|
|
|
for _, s := range ctxt.Data {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeSym(s)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2018-10-26 13:53:02 -04:00
|
|
|
for _, s := range ctxt.ABIAliases {
|
|
|
|
|
w.writeSym(s)
|
|
|
|
|
}
|
2015-01-19 14:34:58 -05:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Magic footer
|
2018-10-26 13:53:02 -04:00
|
|
|
w.wr.WriteString("\xffgo112ld")
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
// Symbols are prefixed so their content doesn't get confused with the magic footer.
|
|
|
|
|
const symPrefix = 0xfe
|
2016-03-17 13:18:34 +02:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeRef(s *LSym, isPath bool) {
|
2016-03-14 22:57:58 +02:00
|
|
|
if s == nil || s.RefIdx != 0 {
|
|
|
|
|
return
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
w.wr.WriteByte(symPrefix)
|
2016-03-14 22:57:58 +02:00
|
|
|
if isPath {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeString(filepath.ToSlash(s.Name))
|
cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object
file, it uses "". for the package path of the package being
compiled. This is then expanded in the linker to the actual
package path.
With CL 173938, it does not need an allocation if the symbol name
does not need expansion. In many cases, the compiler actually
knows the package path (through the -p flag), so we could just
write it out in compile time, without fixing it up in the linker.
This reduces allocations in the linker.
In case that the package path is not known (compiler's -p flag is
missing, or the object file is generated by the assembler), the
linker still does the expansion.
This reduces ~100MB allocations (~10% inuse_space) in linking
k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64.
Also makes the linker a little faster: linking cmd/go on
Linux/AMD64:
Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10)
User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10)
Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10)
The caveat is that the object files get slightly bigger. On
Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa
(which has a longer import path) gets 2.8% bigger.
This reveals that when building an unnamed plugin (e.g.
go build -buildmode=plugin x.go), the go command passes different
package paths to the compiler and to the linker. Before this CL
there seems nothing obviously broken, but given that the compiler
already emits the package's import path in various places (e.g.
debug info), I guess it is possible that this leads to some
unexpected behavior. Now that the compiler writes the package
path in more places, this disagreement actually leads to
unresolved symbols. Adjust the go command to use the same package
path for both compiling and linking.
Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/174657
Reviewed-by: Austin Clements <austin@google.com>
2019-04-30 20:47:48 -04:00
|
|
|
} else if w.pkgpath != "" {
|
|
|
|
|
// w.pkgpath is already escaped.
|
|
|
|
|
n := strings.Replace(s.Name, "\"\".", w.pkgpath+".", -1)
|
|
|
|
|
w.writeString(n)
|
2016-03-14 22:57:58 +02:00
|
|
|
} else {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeString(s.Name)
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
2018-10-26 13:53:02 -04:00
|
|
|
// Write ABI/static information.
|
|
|
|
|
abi := int64(s.ABI())
|
|
|
|
|
if s.Static() {
|
|
|
|
|
abi = -1
|
|
|
|
|
}
|
|
|
|
|
w.writeInt(abi)
|
2016-03-31 12:59:05 +03:00
|
|
|
w.nRefs++
|
|
|
|
|
s.RefIdx = w.nRefs
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeRefs(s *LSym) {
|
|
|
|
|
w.writeRef(s, false)
|
|
|
|
|
w.writeRef(s.Gotype, false)
|
2018-04-05 12:11:32 +01:00
|
|
|
for _, r := range s.R {
|
|
|
|
|
w.writeRef(r.Sym, false)
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
|
|
|
|
|
2017-04-18 12:53:25 -07:00
|
|
|
if s.Type == objabi.STEXT {
|
2017-04-18 10:18:34 -07:00
|
|
|
for _, a := range s.Func.Autom {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRef(a.Asym, false)
|
|
|
|
|
w.writeRef(a.Gotype, false)
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
2017-04-18 10:18:34 -07:00
|
|
|
pc := &s.Func.Pcln
|
2016-03-14 22:57:58 +02:00
|
|
|
for _, d := range pc.Funcdata {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRef(d, false)
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
|
|
|
|
for _, f := range pc.File {
|
2017-04-20 07:13:02 -07:00
|
|
|
fsym := w.ctxt.Lookup(f)
|
2017-04-03 07:50:56 -07:00
|
|
|
w.writeRef(fsym, true)
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
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 _, call := range pc.InlTree.nodes {
|
|
|
|
|
w.writeRef(call.Func, false)
|
|
|
|
|
f, _ := linkgetlineFromPos(w.ctxt, call.Pos)
|
2017-04-20 07:13:02 -07:00
|
|
|
fsym := w.ctxt.Lookup(f)
|
2017-04-03 07:50:56 -07:00
|
|
|
w.writeRef(fsym, true)
|
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
|
|
|
}
|
2016-03-14 22:57:58 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeSymDebug(s *LSym) {
|
|
|
|
|
ctxt := w.ctxt
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, "%s ", s.Name)
|
|
|
|
|
if s.Type != 0 {
|
2017-04-16 14:48:16 -07:00
|
|
|
fmt.Fprintf(ctxt.Bso, "%v ", s.Type)
|
2016-03-31 12:59:05 +03:00
|
|
|
}
|
2017-04-20 07:13:02 -07:00
|
|
|
if s.Static() {
|
|
|
|
|
fmt.Fprint(ctxt.Bso, "static ")
|
|
|
|
|
}
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.DuplicateOK() {
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, "dupok ")
|
|
|
|
|
}
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.CFunc() {
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, "cfunc ")
|
|
|
|
|
}
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.NoSplit() {
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, "nosplit ")
|
|
|
|
|
}
|
2019-03-28 12:51:30 -04:00
|
|
|
if s.TopFrame() {
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, "topframe ")
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, "size=%d", s.Size)
|
2017-04-18 12:53:25 -07:00
|
|
|
if s.Type == objabi.STEXT {
|
2017-04-18 10:18:34 -07:00
|
|
|
fmt.Fprintf(ctxt.Bso, " args=%#x locals=%#x", uint64(s.Func.Args), uint64(s.Func.Locals))
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.Leaf() {
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, " leaf")
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
}
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, "\n")
|
2017-04-18 12:53:25 -07:00
|
|
|
if s.Type == objabi.STEXT {
|
2017-04-18 10:18:34 -07:00
|
|
|
for p := s.Func.Text; p != nil; p = p.Link {
|
2018-12-07 10:00:36 -08:00
|
|
|
var s string
|
|
|
|
|
if ctxt.Debugasm > 1 {
|
|
|
|
|
s = p.String()
|
|
|
|
|
} else {
|
|
|
|
|
s = p.InnermostString()
|
|
|
|
|
}
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, "\t%#04x %s\n", uint(int(p.Pc)), s)
|
2017-03-03 16:45:21 -08:00
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
}
|
2017-03-03 16:45:21 -08:00
|
|
|
for i := 0; i < len(s.P); i += 16 {
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, "\t%#04x", uint(i))
|
2017-03-03 16:45:21 -08:00
|
|
|
j := i
|
2019-01-30 17:35:18 +00:00
|
|
|
for ; j < i+16 && j < len(s.P); j++ {
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, " %02x", s.P[j])
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
for ; j < i+16; j++ {
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, " ")
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
fmt.Fprintf(ctxt.Bso, " ")
|
|
|
|
|
for j = i; j < i+16 && j < len(s.P); j++ {
|
2017-03-03 16:45:21 -08:00
|
|
|
c := int(s.P[j])
|
2016-03-31 12:59:05 +03:00
|
|
|
if ' ' <= c && c <= 0x7e {
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, "%c", c)
|
|
|
|
|
} else {
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, ".")
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fmt.Fprintf(ctxt.Bso, "\n")
|
2016-03-31 12:59:05 +03:00
|
|
|
}
|
2015-01-19 14:34:58 -05:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
sort.Sort(relocByOff(s.R)) // generate stable output
|
|
|
|
|
for _, r := range s.R {
|
|
|
|
|
name := ""
|
|
|
|
|
if r.Sym != nil {
|
|
|
|
|
name = r.Sym.Name
|
2017-04-18 12:53:25 -07:00
|
|
|
} else if r.Type == objabi.R_TLS_LE {
|
2016-04-04 10:49:55 -07:00
|
|
|
name = "TLS"
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-04-06 12:01:40 -07:00
|
|
|
if ctxt.Arch.InFamily(sys.ARM, sys.PPC64) {
|
2016-04-14 19:04:45 -07:00
|
|
|
fmt.Fprintf(ctxt.Bso, "\trel %d+%d t=%d %s+%x\n", int(r.Off), r.Siz, r.Type, name, uint64(r.Add))
|
2016-03-31 12:59:05 +03:00
|
|
|
} else {
|
2016-04-14 19:04:45 -07:00
|
|
|
fmt.Fprintf(ctxt.Bso, "\trel %d+%d t=%d %s+%d\n", int(r.Off), r.Siz, r.Type, name, r.Add)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
}
|
2015-01-19 14:34:58 -05:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeSym(s *LSym) {
|
|
|
|
|
ctxt := w.ctxt
|
2018-12-07 10:00:36 -08:00
|
|
|
if ctxt.Debugasm > 0 {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeSymDebug(s)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
w.wr.WriteByte(symPrefix)
|
2017-04-28 08:07:56 +12:00
|
|
|
w.wr.WriteByte(byte(s.Type))
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRefIndex(s)
|
2016-03-28 11:34:37 +02:00
|
|
|
flags := int64(0)
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.DuplicateOK() {
|
2016-03-28 11:34:37 +02:00
|
|
|
flags |= 1
|
|
|
|
|
}
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.Local() {
|
2016-03-28 11:34:37 +02:00
|
|
|
flags |= 1 << 1
|
2015-04-18 08:14:08 +12:00
|
|
|
}
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.MakeTypelink() {
|
2016-10-19 07:33:16 +03:00
|
|
|
flags |= 1 << 2
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(flags)
|
|
|
|
|
w.writeInt(s.Size)
|
|
|
|
|
w.writeRefIndex(s.Gotype)
|
|
|
|
|
w.writeInt(int64(len(s.P)))
|
2015-01-19 14:34:58 -05:00
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(int64(len(s.R)))
|
2015-02-23 16:07:24 -05:00
|
|
|
var r *Reloc
|
2018-04-05 12:11:32 +01:00
|
|
|
for i := range s.R {
|
2015-01-19 14:34:58 -05:00
|
|
|
r = &s.R[i]
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(int64(r.Off))
|
|
|
|
|
w.writeInt(int64(r.Siz))
|
|
|
|
|
w.writeInt(int64(r.Type))
|
|
|
|
|
w.writeInt(r.Add)
|
|
|
|
|
w.writeRefIndex(r.Sym)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
|
|
|
|
|
2017-04-18 12:53:25 -07:00
|
|
|
if s.Type != objabi.STEXT {
|
2016-03-31 12:59:05 +03:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-18 10:18:34 -07:00
|
|
|
w.writeInt(int64(s.Func.Args))
|
|
|
|
|
w.writeInt(int64(s.Func.Locals))
|
2018-04-05 12:11:32 +01:00
|
|
|
w.writeBool(s.NoSplit())
|
2016-03-31 12:59:05 +03:00
|
|
|
flags = int64(0)
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.Leaf() {
|
2016-03-31 12:59:05 +03:00
|
|
|
flags |= 1
|
|
|
|
|
}
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.CFunc() {
|
2016-03-31 12:59:05 +03:00
|
|
|
flags |= 1 << 1
|
|
|
|
|
}
|
2016-10-24 23:15:41 +03:00
|
|
|
if s.ReflectMethod() {
|
2016-03-31 12:59:05 +03:00
|
|
|
flags |= 1 << 2
|
|
|
|
|
}
|
2017-05-09 14:34:16 -07:00
|
|
|
if ctxt.Flag_shared {
|
|
|
|
|
flags |= 1 << 3
|
|
|
|
|
}
|
2019-03-28 12:51:30 -04:00
|
|
|
if s.TopFrame() {
|
|
|
|
|
flags |= 1 << 4
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(flags)
|
2017-04-18 10:18:34 -07:00
|
|
|
w.writeInt(int64(len(s.Func.Autom)))
|
|
|
|
|
for _, a := range s.Func.Autom {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRefIndex(a.Asym)
|
|
|
|
|
w.writeInt(int64(a.Aoffset))
|
|
|
|
|
if a.Name == NAME_AUTO {
|
2017-04-18 12:53:25 -07:00
|
|
|
w.writeInt(objabi.A_AUTO)
|
2016-03-31 12:59:05 +03:00
|
|
|
} else if a.Name == NAME_PARAM {
|
2017-04-18 12:53:25 -07:00
|
|
|
w.writeInt(objabi.A_PARAM)
|
2017-12-01 15:23:30 -05:00
|
|
|
} else if a.Name == NAME_DELETED_AUTO {
|
|
|
|
|
w.writeInt(objabi.A_DELETED_AUTO)
|
2016-03-28 11:34:37 +02:00
|
|
|
} else {
|
2016-03-31 12:59:05 +03:00
|
|
|
log.Fatalf("%s: invalid local variable type %d", s.Name, a.Name)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRefIndex(a.Gotype)
|
|
|
|
|
}
|
2015-01-19 14:34:58 -05:00
|
|
|
|
2017-04-18 10:18:34 -07:00
|
|
|
pc := &s.Func.Pcln
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(int64(len(pc.Pcsp.P)))
|
|
|
|
|
w.writeInt(int64(len(pc.Pcfile.P)))
|
|
|
|
|
w.writeInt(int64(len(pc.Pcline.P)))
|
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
|
|
|
w.writeInt(int64(len(pc.Pcinline.P)))
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(int64(len(pc.Pcdata)))
|
2018-04-05 12:11:32 +01:00
|
|
|
for _, pcd := range pc.Pcdata {
|
|
|
|
|
w.writeInt(int64(len(pcd.P)))
|
2016-03-31 12:59:05 +03:00
|
|
|
}
|
|
|
|
|
w.writeInt(int64(len(pc.Funcdataoff)))
|
2018-04-05 12:11:32 +01:00
|
|
|
for i := range pc.Funcdataoff {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeRefIndex(pc.Funcdata[i])
|
|
|
|
|
}
|
2018-04-05 12:11:32 +01:00
|
|
|
for i := range pc.Funcdataoff {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(pc.Funcdataoff[i])
|
|
|
|
|
}
|
|
|
|
|
w.writeInt(int64(len(pc.File)))
|
|
|
|
|
for _, f := range pc.File {
|
2017-04-20 07:13:02 -07:00
|
|
|
fsym := ctxt.Lookup(f)
|
2017-04-03 07:50:56 -07:00
|
|
|
w.writeRefIndex(fsym)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
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
|
|
|
w.writeInt(int64(len(pc.InlTree.nodes)))
|
|
|
|
|
for _, call := range pc.InlTree.nodes {
|
|
|
|
|
w.writeInt(int64(call.Parent))
|
|
|
|
|
f, l := linkgetlineFromPos(w.ctxt, call.Pos)
|
2017-04-20 07:13:02 -07:00
|
|
|
fsym := ctxt.Lookup(f)
|
2017-04-03 07:50:56 -07:00
|
|
|
w.writeRefIndex(fsym)
|
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
|
|
|
w.writeInt(int64(l))
|
|
|
|
|
w.writeRefIndex(call.Func)
|
2018-12-04 07:58:18 -08:00
|
|
|
w.writeInt(int64(call.ParentPC))
|
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
|
|
|
}
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
|
|
|
|
|
2018-04-05 12:11:32 +01:00
|
|
|
func (w *objWriter) writeBool(b bool) {
|
|
|
|
|
if b {
|
|
|
|
|
w.writeInt(1)
|
|
|
|
|
} else {
|
|
|
|
|
w.writeInt(0)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeInt(sval int64) {
|
2015-01-19 14:34:58 -05:00
|
|
|
var v uint64
|
2016-04-14 19:04:45 -07:00
|
|
|
uv := (uint64(sval) << 1) ^ uint64(sval>>63)
|
2016-03-31 12:59:05 +03:00
|
|
|
p := w.varintbuf[:]
|
2015-01-19 14:34:58 -05:00
|
|
|
for v = uv; v >= 0x80; v >>= 7 {
|
|
|
|
|
p[0] = uint8(v | 0x80)
|
|
|
|
|
p = p[1:]
|
|
|
|
|
}
|
|
|
|
|
p[0] = uint8(v)
|
|
|
|
|
p = p[1:]
|
2016-03-31 12:59:05 +03:00
|
|
|
w.wr.Write(w.varintbuf[:len(w.varintbuf)-len(p)])
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeString(s string) {
|
|
|
|
|
w.writeInt(int64(len(s)))
|
|
|
|
|
w.wr.WriteString(s)
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
|
|
|
|
|
2016-03-31 12:59:05 +03:00
|
|
|
func (w *objWriter) writeRefIndex(s *LSym) {
|
2015-01-19 14:34:58 -05:00
|
|
|
if s == nil {
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(0)
|
2015-01-19 14:34:58 -05:00
|
|
|
return
|
|
|
|
|
}
|
2016-03-14 22:57:58 +02:00
|
|
|
if s.RefIdx == 0 {
|
|
|
|
|
log.Fatalln("writing an unreferenced symbol", s.Name)
|
|
|
|
|
}
|
2016-03-31 12:59:05 +03:00
|
|
|
w.writeInt(int64(s.RefIdx))
|
2015-01-19 14:34:58 -05:00
|
|
|
}
|
2016-03-13 10:13:03 -07:00
|
|
|
|
|
|
|
|
// relocByOff sorts relocations by their offsets.
|
|
|
|
|
type relocByOff []Reloc
|
|
|
|
|
|
|
|
|
|
func (x relocByOff) Len() int { return len(x) }
|
|
|
|
|
func (x relocByOff) Less(i, j int) bool { return x[i].Off < x[j].Off }
|
|
|
|
|
func (x relocByOff) Swap(i, j int) { x[i], x[j] = x[j], x[i] }
|
2016-07-28 13:04:41 -04:00
|
|
|
|
|
|
|
|
// implement dwarf.Context
|
|
|
|
|
type dwCtxt struct{ *Link }
|
|
|
|
|
|
|
|
|
|
func (c dwCtxt) PtrSize() int {
|
|
|
|
|
return c.Arch.PtrSize
|
|
|
|
|
}
|
|
|
|
|
func (c dwCtxt) AddInt(s dwarf.Sym, size int, i int64) {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
ls.WriteInt(c.Link, ls.Size, size, i)
|
|
|
|
|
}
|
|
|
|
|
func (c dwCtxt) AddBytes(s dwarf.Sym, b []byte) {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
ls.WriteBytes(c.Link, ls.Size, b)
|
|
|
|
|
}
|
|
|
|
|
func (c dwCtxt) AddString(s dwarf.Sym, v string) {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
ls.WriteString(c.Link, ls.Size, len(v), v)
|
|
|
|
|
ls.WriteInt(c.Link, ls.Size, 1, 0)
|
|
|
|
|
}
|
|
|
|
|
func (c dwCtxt) AddAddress(s dwarf.Sym, data interface{}, value int64) {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
size := c.PtrSize()
|
2017-05-02 16:46:01 +02:00
|
|
|
if data != nil {
|
|
|
|
|
rsym := data.(*LSym)
|
|
|
|
|
ls.WriteAddr(c.Link, ls.Size, size, rsym, value)
|
|
|
|
|
} else {
|
|
|
|
|
ls.WriteInt(c.Link, ls.Size, size, value)
|
|
|
|
|
}
|
2016-07-28 13:04:41 -04:00
|
|
|
}
|
2019-04-02 17:26:49 -04:00
|
|
|
func (c dwCtxt) AddCURelativeAddress(s dwarf.Sym, data interface{}, value int64) {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
rsym := data.(*LSym)
|
|
|
|
|
ls.WriteCURelativeAddr(c.Link, ls.Size, rsym, value)
|
|
|
|
|
}
|
2016-07-28 13:04:41 -04:00
|
|
|
func (c dwCtxt) AddSectionOffset(s dwarf.Sym, size int, t interface{}, ofs int64) {
|
2018-04-12 17:07:14 -04:00
|
|
|
panic("should be used only in the linker")
|
|
|
|
|
}
|
2018-09-28 16:44:30 +02:00
|
|
|
func (c dwCtxt) AddDWARFAddrSectionOffset(s dwarf.Sym, t interface{}, ofs int64) {
|
|
|
|
|
size := 4
|
|
|
|
|
if isDwarf64(c.Link) {
|
|
|
|
|
size = 8
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-28 13:04:41 -04:00
|
|
|
ls := s.(*LSym)
|
|
|
|
|
rsym := t.(*LSym)
|
|
|
|
|
ls.WriteAddr(c.Link, ls.Size, size, rsym, ofs)
|
|
|
|
|
r := &ls.R[len(ls.R)-1]
|
2017-10-24 16:08:46 -04:00
|
|
|
r.Type = objabi.R_DWARFSECREF
|
|
|
|
|
}
|
|
|
|
|
func (c dwCtxt) AddFileRef(s dwarf.Sym, f interface{}) {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
rsym := f.(*LSym)
|
|
|
|
|
ls.WriteAddr(c.Link, ls.Size, 4, rsym, 0)
|
|
|
|
|
r := &ls.R[len(ls.R)-1]
|
|
|
|
|
r.Type = objabi.R_DWARFFILEREF
|
2016-07-28 13:04:41 -04:00
|
|
|
}
|
|
|
|
|
|
2017-10-06 11:32:28 -04:00
|
|
|
func (c dwCtxt) CurrentOffset(s dwarf.Sym) int64 {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
return ls.Size
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Here "from" is a symbol corresponding to an inlined or concrete
|
|
|
|
|
// function, "to" is the symbol for the corresponding abstract
|
|
|
|
|
// function, and "dclIdx" is the index of the symbol of interest with
|
|
|
|
|
// respect to the Dcl slice of the original pre-optimization version
|
|
|
|
|
// of the inlined function.
|
|
|
|
|
func (c dwCtxt) RecordDclReference(from dwarf.Sym, to dwarf.Sym, dclIdx int, inlIndex int) {
|
|
|
|
|
ls := from.(*LSym)
|
|
|
|
|
tls := to.(*LSym)
|
|
|
|
|
ridx := len(ls.R) - 1
|
|
|
|
|
c.Link.DwFixups.ReferenceChildDIE(ls, ridx, tls, dclIdx, inlIndex)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (c dwCtxt) RecordChildDieOffsets(s dwarf.Sym, vars []*dwarf.Var, offsets []int32) {
|
|
|
|
|
ls := s.(*LSym)
|
|
|
|
|
c.Link.DwFixups.RegisterChildDIEOffsets(ls, vars, offsets)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (c dwCtxt) Logf(format string, args ...interface{}) {
|
|
|
|
|
c.Link.Logf(format, args...)
|
|
|
|
|
}
|
|
|
|
|
|
2018-09-28 16:44:30 +02:00
|
|
|
func isDwarf64(ctxt *Link) bool {
|
|
|
|
|
return ctxt.Headtype == objabi.Haix
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-13 17:39:38 -05:00
|
|
|
func (ctxt *Link) dwarfSym(s *LSym) (dwarfInfoSym, dwarfLocSym, dwarfRangesSym, dwarfAbsFnSym, dwarfIsStmtSym *LSym) {
|
2017-04-18 12:53:25 -07:00
|
|
|
if s.Type != objabi.STEXT {
|
2017-04-13 05:57:59 -07:00
|
|
|
ctxt.Diag("dwarfSym of non-TEXT %v", s)
|
|
|
|
|
}
|
[dev.debug] cmd/compile: better DWARF with optimizations on
Debuggers use DWARF information to find local variables on the
stack and in registers. Prior to this CL, the DWARF information for
functions claimed that all variables were on the stack at all times.
That's incorrect when optimizations are enabled, and results in
debuggers showing data that is out of date or complete gibberish.
After this CL, the compiler is capable of representing variable
locations more accurately, and attempts to do so. Due to limitations of
the SSA backend, it's not possible to be completely correct.
There are a number of problems in the current design. One of the easier
to understand is that variable names currently must be attached to an
SSA value, but not all assignments in the source code actually result
in machine code. For example:
type myint int
var a int
b := myint(int)
and
b := (*uint64)(unsafe.Pointer(a))
don't generate machine code because the underlying representation is the
same, so the correct value of b will not be set when the user would
expect.
Generating the more precise debug information is behind a flag,
dwarflocationlists. Because of the issues described above, setting the
flag may not make the debugging experience much better, and may actually
make it worse in cases where the variable actually is on the stack and
the more complicated analysis doesn't realize it.
A number of changes are included:
- Add a new pseudo-instruction, RegKill, which indicates that the value
in the register has been clobbered.
- Adjust regalloc to emit RegKills in the right places. Significantly,
this means that phis are mixed with StoreReg and RegKills after
regalloc.
- Track variable decomposition in ssa.LocalSlots.
- After the SSA backend is done, analyze the result and build location
lists for each LocalSlot.
- After assembly is done, update the location lists with the assembled
PC offsets, recompose variables, and build DWARF location lists. Emit the
list as a new linker symbol, one per function.
- In the linker, aggregate the location lists into a .debug_loc section.
TODO:
- currently disabled for non-X86/AMD64 because there are no data tables.
go build -toolexec 'toolstash -cmp' -a std succeeds.
With -dwarflocationlists false:
before: f02812195637909ff675782c0b46836a8ff01976
after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec
benchstat -geomean /tmp/220352263 /tmp/621364410
completed 15 of 15, estimated time remaining 0s (eta 3:52PM)
name old time/op new time/op delta
Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14)
Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15)
GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14)
Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15)
GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15)
Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13)
Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15)
XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15)
[Geo mean] 206ms 377ms +82.86%
name old user-time/op new user-time/op delta
Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15)
Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14)
GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15)
Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15)
GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15)
Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13)
Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15)
XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15)
[Geo mean] 317ms 583ms +83.72%
name old alloc/op new alloc/op delta
Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15)
Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15)
GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14)
Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15)
GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15)
Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15)
Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15)
XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15)
[Geo mean] 42.1MB 75.0MB +78.05%
name old allocs/op new allocs/op delta
Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15)
Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14)
GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14)
Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15)
GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15)
Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15)
Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15)
XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15)
[Geo mean] 439k 755k +72.01%
name old text-bytes new text-bytes delta
HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15)
name old data-bytes new data-bytes delta
HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal)
name old bss-bytes new bss-bytes delta
HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal)
name old exe-bytes new exe-bytes delta
HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal)
Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8
Reviewed-on: https://go-review.googlesource.com/41770
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
|
|
|
if s.Func.dwarfInfoSym == nil {
|
|
|
|
|
s.Func.dwarfInfoSym = ctxt.LookupDerived(s, dwarf.InfoPrefix+s.Name)
|
|
|
|
|
if ctxt.Flag_locationlists {
|
|
|
|
|
s.Func.dwarfLocSym = ctxt.LookupDerived(s, dwarf.LocPrefix+s.Name)
|
|
|
|
|
}
|
2017-05-02 16:46:01 +02:00
|
|
|
s.Func.dwarfRangesSym = ctxt.LookupDerived(s, dwarf.RangePrefix+s.Name)
|
2017-10-06 11:32:28 -04:00
|
|
|
if s.WasInlined() {
|
|
|
|
|
s.Func.dwarfAbsFnSym = ctxt.DwFixups.AbsFuncDwarfSym(s)
|
|
|
|
|
}
|
2018-02-13 17:39:38 -05:00
|
|
|
s.Func.dwarfIsStmtSym = ctxt.LookupDerived(s, dwarf.IsStmtPrefix+s.Name)
|
2017-10-06 11:32:28 -04:00
|
|
|
|
2017-04-13 08:00:09 -07:00
|
|
|
}
|
2018-02-13 17:39:38 -05:00
|
|
|
return s.Func.dwarfInfoSym, s.Func.dwarfLocSym, s.Func.dwarfRangesSym, s.Func.dwarfAbsFnSym, s.Func.dwarfIsStmtSym
|
2017-04-13 05:57:59 -07:00
|
|
|
}
|
|
|
|
|
|
2017-05-02 16:46:01 +02:00
|
|
|
func (s *LSym) Len() int64 {
|
|
|
|
|
return s.Size
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-24 16:08:46 -04:00
|
|
|
// fileSymbol returns a symbol corresponding to the source file of the
|
|
|
|
|
// first instruction (prog) of the specified function. This will
|
|
|
|
|
// presumably be the file in which the function is defined.
|
|
|
|
|
func (ctxt *Link) fileSymbol(fn *LSym) *LSym {
|
|
|
|
|
p := fn.Func.Text
|
|
|
|
|
if p != nil {
|
|
|
|
|
f, _ := linkgetlineFromPos(ctxt, p.Pos)
|
|
|
|
|
fsym := ctxt.Lookup(f)
|
|
|
|
|
return fsym
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-06 11:32:28 -04:00
|
|
|
// populateDWARF fills in the DWARF Debugging Information Entries for
|
|
|
|
|
// TEXT symbol 's'. The various DWARF symbols must already have been
|
|
|
|
|
// initialized in InitTextSym.
|
|
|
|
|
func (ctxt *Link) populateDWARF(curfn interface{}, s *LSym, myimportpath string) {
|
2018-02-13 17:39:38 -05:00
|
|
|
info, loc, ranges, absfunc, _ := ctxt.dwarfSym(s)
|
[dev.debug] cmd/compile: better DWARF with optimizations on
Debuggers use DWARF information to find local variables on the
stack and in registers. Prior to this CL, the DWARF information for
functions claimed that all variables were on the stack at all times.
That's incorrect when optimizations are enabled, and results in
debuggers showing data that is out of date or complete gibberish.
After this CL, the compiler is capable of representing variable
locations more accurately, and attempts to do so. Due to limitations of
the SSA backend, it's not possible to be completely correct.
There are a number of problems in the current design. One of the easier
to understand is that variable names currently must be attached to an
SSA value, but not all assignments in the source code actually result
in machine code. For example:
type myint int
var a int
b := myint(int)
and
b := (*uint64)(unsafe.Pointer(a))
don't generate machine code because the underlying representation is the
same, so the correct value of b will not be set when the user would
expect.
Generating the more precise debug information is behind a flag,
dwarflocationlists. Because of the issues described above, setting the
flag may not make the debugging experience much better, and may actually
make it worse in cases where the variable actually is on the stack and
the more complicated analysis doesn't realize it.
A number of changes are included:
- Add a new pseudo-instruction, RegKill, which indicates that the value
in the register has been clobbered.
- Adjust regalloc to emit RegKills in the right places. Significantly,
this means that phis are mixed with StoreReg and RegKills after
regalloc.
- Track variable decomposition in ssa.LocalSlots.
- After the SSA backend is done, analyze the result and build location
lists for each LocalSlot.
- After assembly is done, update the location lists with the assembled
PC offsets, recompose variables, and build DWARF location lists. Emit the
list as a new linker symbol, one per function.
- In the linker, aggregate the location lists into a .debug_loc section.
TODO:
- currently disabled for non-X86/AMD64 because there are no data tables.
go build -toolexec 'toolstash -cmp' -a std succeeds.
With -dwarflocationlists false:
before: f02812195637909ff675782c0b46836a8ff01976
after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec
benchstat -geomean /tmp/220352263 /tmp/621364410
completed 15 of 15, estimated time remaining 0s (eta 3:52PM)
name old time/op new time/op delta
Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14)
Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15)
GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14)
Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15)
GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15)
Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13)
Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15)
XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15)
[Geo mean] 206ms 377ms +82.86%
name old user-time/op new user-time/op delta
Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15)
Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14)
GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15)
Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15)
GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15)
Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13)
Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15)
XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15)
[Geo mean] 317ms 583ms +83.72%
name old alloc/op new alloc/op delta
Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15)
Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15)
GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14)
Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15)
GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15)
Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15)
Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15)
XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15)
[Geo mean] 42.1MB 75.0MB +78.05%
name old allocs/op new allocs/op delta
Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15)
Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14)
GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14)
Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15)
GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15)
Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15)
Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15)
XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15)
[Geo mean] 439k 755k +72.01%
name old text-bytes new text-bytes delta
HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15)
name old data-bytes new data-bytes delta
HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal)
name old bss-bytes new bss-bytes delta
HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal)
name old exe-bytes new exe-bytes delta
HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal)
Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8
Reviewed-on: https://go-review.googlesource.com/41770
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
|
|
|
if info.Size != 0 {
|
2017-04-13 05:57:59 -07:00
|
|
|
ctxt.Diag("makeFuncDebugEntry double process %v", s)
|
2017-03-06 07:32:37 -08:00
|
|
|
}
|
2017-05-02 16:46:01 +02:00
|
|
|
var scopes []dwarf.Scope
|
2017-10-06 11:32:28 -04:00
|
|
|
var inlcalls dwarf.InlCalls
|
2017-03-06 07:32:37 -08:00
|
|
|
if ctxt.DebugInfo != nil {
|
2018-02-13 17:39:38 -05:00
|
|
|
stmtData(ctxt, s)
|
2017-10-06 11:32:28 -04:00
|
|
|
scopes, inlcalls = ctxt.DebugInfo(s, curfn)
|
|
|
|
|
}
|
|
|
|
|
var err error
|
|
|
|
|
dwctxt := dwCtxt{ctxt}
|
|
|
|
|
filesym := ctxt.fileSymbol(s)
|
|
|
|
|
fnstate := &dwarf.FnState{
|
2019-04-02 17:26:49 -04:00
|
|
|
Name: s.Name,
|
|
|
|
|
Importpath: myimportpath,
|
|
|
|
|
Info: info,
|
|
|
|
|
Filesym: filesym,
|
|
|
|
|
Loc: loc,
|
|
|
|
|
Ranges: ranges,
|
|
|
|
|
Absfn: absfunc,
|
|
|
|
|
StartPC: s,
|
|
|
|
|
Size: s.Size,
|
|
|
|
|
External: !s.Static(),
|
|
|
|
|
Scopes: scopes,
|
|
|
|
|
InlCalls: inlcalls,
|
|
|
|
|
UseBASEntries: ctxt.UseBASEntries,
|
2017-10-06 11:32:28 -04:00
|
|
|
}
|
|
|
|
|
if absfunc != nil {
|
|
|
|
|
err = dwarf.PutAbstractFunc(dwctxt, fnstate)
|
|
|
|
|
if err != nil {
|
|
|
|
|
ctxt.Diag("emitting DWARF for %s failed: %v", s.Name, err)
|
|
|
|
|
}
|
|
|
|
|
err = dwarf.PutConcreteFunc(dwctxt, fnstate)
|
|
|
|
|
} else {
|
|
|
|
|
err = dwarf.PutDefaultFunc(dwctxt, fnstate)
|
2017-05-02 16:46:01 +02:00
|
|
|
}
|
|
|
|
|
if err != nil {
|
|
|
|
|
ctxt.Diag("emitting DWARF for %s failed: %v", s.Name, err)
|
2016-07-28 13:04:41 -04:00
|
|
|
}
|
|
|
|
|
}
|
2017-09-03 11:59:18 +02:00
|
|
|
|
|
|
|
|
// DwarfIntConst creates a link symbol for an integer constant with the
|
|
|
|
|
// given name, type and value.
|
|
|
|
|
func (ctxt *Link) DwarfIntConst(myimportpath, name, typename string, val int64) {
|
|
|
|
|
if myimportpath == "" {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
s := ctxt.LookupInit(dwarf.ConstInfoPrefix+myimportpath, func(s *LSym) {
|
|
|
|
|
s.Type = objabi.SDWARFINFO
|
|
|
|
|
ctxt.Data = append(ctxt.Data, s)
|
|
|
|
|
})
|
|
|
|
|
dwarf.PutIntConst(dwCtxt{ctxt}, s, ctxt.Lookup(dwarf.InfoPrefix+typename), myimportpath+"."+name, val)
|
|
|
|
|
}
|
2017-10-06 11:32:28 -04:00
|
|
|
|
|
|
|
|
func (ctxt *Link) DwarfAbstractFunc(curfn interface{}, s *LSym, myimportpath string) {
|
|
|
|
|
absfn := ctxt.DwFixups.AbsFuncDwarfSym(s)
|
|
|
|
|
if absfn.Size != 0 {
|
|
|
|
|
ctxt.Diag("internal error: DwarfAbstractFunc double process %v", s)
|
|
|
|
|
}
|
|
|
|
|
if s.Func == nil {
|
|
|
|
|
s.Func = new(FuncInfo)
|
|
|
|
|
}
|
|
|
|
|
scopes, _ := ctxt.DebugInfo(s, curfn)
|
|
|
|
|
dwctxt := dwCtxt{ctxt}
|
|
|
|
|
filesym := ctxt.fileSymbol(s)
|
|
|
|
|
fnstate := dwarf.FnState{
|
2019-04-02 17:26:49 -04:00
|
|
|
Name: s.Name,
|
|
|
|
|
Importpath: myimportpath,
|
|
|
|
|
Info: absfn,
|
|
|
|
|
Filesym: filesym,
|
|
|
|
|
Absfn: absfn,
|
|
|
|
|
External: !s.Static(),
|
|
|
|
|
Scopes: scopes,
|
|
|
|
|
UseBASEntries: ctxt.UseBASEntries,
|
2017-10-06 11:32:28 -04:00
|
|
|
}
|
|
|
|
|
if err := dwarf.PutAbstractFunc(dwctxt, &fnstate); err != nil {
|
|
|
|
|
ctxt.Diag("emitting DWARF for %s failed: %v", s.Name, err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// This table is designed to aid in the creation of references betweeen
|
|
|
|
|
// DWARF subprogram DIEs.
|
|
|
|
|
//
|
|
|
|
|
// In most cases when one DWARF DIE has to refer to another DWARF DIE,
|
|
|
|
|
// the target of the reference has an LSym, which makes it easy to use
|
|
|
|
|
// the existing relocation mechanism. For DWARF inlined routine DIEs,
|
|
|
|
|
// however, the subprogram DIE has to refer to a child
|
|
|
|
|
// parameter/variable DIE of the abstract subprogram. This child DIE
|
|
|
|
|
// doesn't have an LSym, and also of interest is the fact that when
|
|
|
|
|
// DWARF generation is happening for inlined function F within caller
|
|
|
|
|
// G, it's possible that DWARF generation hasn't happened yet for F,
|
|
|
|
|
// so there is no way to know the offset of a child DIE within F's
|
|
|
|
|
// abstract function. Making matters more complex, each inlined
|
|
|
|
|
// instance of F may refer to a subset of the original F's variables
|
|
|
|
|
// (depending on what happens with optimization, some vars may be
|
|
|
|
|
// eliminated).
|
|
|
|
|
//
|
|
|
|
|
// The fixup table below helps overcome this hurdle. At the point
|
|
|
|
|
// where a parameter/variable reference is made (via a call to
|
|
|
|
|
// "ReferenceChildDIE"), a fixup record is generate that records
|
|
|
|
|
// the relocation that is targeting that child variable. At a later
|
|
|
|
|
// point when the abstract function DIE is emitted, there will be
|
|
|
|
|
// a call to "RegisterChildDIEOffsets", at which point the offsets
|
|
|
|
|
// needed to apply fixups are captured. Finally, once the parallel
|
|
|
|
|
// portion of the compilation is done, fixups can actually be applied
|
|
|
|
|
// during the "Finalize" method (this can't be done during the
|
|
|
|
|
// parallel portion of the compile due to the possibility of data
|
|
|
|
|
// races).
|
|
|
|
|
//
|
|
|
|
|
// This table is also used to record the "precursor" function node for
|
|
|
|
|
// each function that is the target of an inline -- child DIE references
|
|
|
|
|
// have to be made with respect to the original pre-optimization
|
|
|
|
|
// version of the function (to allow for the fact that each inlined
|
|
|
|
|
// body may be optimized differently).
|
|
|
|
|
type DwarfFixupTable struct {
|
|
|
|
|
ctxt *Link
|
|
|
|
|
mu sync.Mutex
|
|
|
|
|
symtab map[*LSym]int // maps abstract fn LSYM to index in svec
|
|
|
|
|
svec []symFixups
|
|
|
|
|
precursor map[*LSym]fnState // maps fn Lsym to precursor Node, absfn sym
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type symFixups struct {
|
|
|
|
|
fixups []relFixup
|
|
|
|
|
doffsets []declOffset
|
|
|
|
|
inlIndex int32
|
|
|
|
|
defseen bool
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type declOffset struct {
|
|
|
|
|
// Index of variable within DCL list of pre-optimization function
|
|
|
|
|
dclIdx int32
|
|
|
|
|
// Offset of var's child DIE with respect to containing subprogram DIE
|
|
|
|
|
offset int32
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type relFixup struct {
|
|
|
|
|
refsym *LSym
|
|
|
|
|
relidx int32
|
|
|
|
|
dclidx int32
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type fnState struct {
|
|
|
|
|
// precursor function (really *gc.Node)
|
|
|
|
|
precursor interface{}
|
|
|
|
|
// abstract function symbol
|
|
|
|
|
absfn *LSym
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func NewDwarfFixupTable(ctxt *Link) *DwarfFixupTable {
|
|
|
|
|
return &DwarfFixupTable{
|
|
|
|
|
ctxt: ctxt,
|
|
|
|
|
symtab: make(map[*LSym]int),
|
|
|
|
|
precursor: make(map[*LSym]fnState),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (ft *DwarfFixupTable) GetPrecursorFunc(s *LSym) interface{} {
|
|
|
|
|
if fnstate, found := ft.precursor[s]; found {
|
|
|
|
|
return fnstate.precursor
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (ft *DwarfFixupTable) SetPrecursorFunc(s *LSym, fn interface{}) {
|
|
|
|
|
if _, found := ft.precursor[s]; found {
|
|
|
|
|
ft.ctxt.Diag("internal error: DwarfFixupTable.SetPrecursorFunc double call on %v", s)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// initialize abstract function symbol now. This is done here so
|
|
|
|
|
// as to avoid data races later on during the parallel portion of
|
|
|
|
|
// the back end.
|
|
|
|
|
absfn := ft.ctxt.LookupDerived(s, dwarf.InfoPrefix+s.Name+dwarf.AbstractFuncSuffix)
|
|
|
|
|
absfn.Set(AttrDuplicateOK, true)
|
|
|
|
|
absfn.Type = objabi.SDWARFINFO
|
|
|
|
|
ft.ctxt.Data = append(ft.ctxt.Data, absfn)
|
|
|
|
|
|
|
|
|
|
ft.precursor[s] = fnState{precursor: fn, absfn: absfn}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Make a note of a child DIE reference: relocation 'ridx' within symbol 's'
|
|
|
|
|
// is targeting child 'c' of DIE with symbol 'tgt'.
|
|
|
|
|
func (ft *DwarfFixupTable) ReferenceChildDIE(s *LSym, ridx int, tgt *LSym, dclidx int, inlIndex int) {
|
|
|
|
|
// Protect against concurrent access if multiple backend workers
|
|
|
|
|
ft.mu.Lock()
|
|
|
|
|
defer ft.mu.Unlock()
|
|
|
|
|
|
|
|
|
|
// Create entry for symbol if not already present.
|
|
|
|
|
idx, found := ft.symtab[tgt]
|
|
|
|
|
if !found {
|
|
|
|
|
ft.svec = append(ft.svec, symFixups{inlIndex: int32(inlIndex)})
|
|
|
|
|
idx = len(ft.svec) - 1
|
|
|
|
|
ft.symtab[tgt] = idx
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Do we have child DIE offsets available? If so, then apply them,
|
|
|
|
|
// otherwise create a fixup record.
|
|
|
|
|
sf := &ft.svec[idx]
|
|
|
|
|
if len(sf.doffsets) > 0 {
|
|
|
|
|
found := false
|
|
|
|
|
for _, do := range sf.doffsets {
|
|
|
|
|
if do.dclIdx == int32(dclidx) {
|
|
|
|
|
off := do.offset
|
|
|
|
|
s.R[ridx].Add += int64(off)
|
|
|
|
|
found = true
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if !found {
|
|
|
|
|
ft.ctxt.Diag("internal error: DwarfFixupTable.ReferenceChildDIE unable to locate child DIE offset for dclIdx=%d src=%v tgt=%v", dclidx, s, tgt)
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
sf.fixups = append(sf.fixups, relFixup{s, int32(ridx), int32(dclidx)})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Called once DWARF generation is complete for a given abstract function,
|
|
|
|
|
// whose children might have been referenced via a call above. Stores
|
|
|
|
|
// the offsets for any child DIEs (vars, params) so that they can be
|
|
|
|
|
// consumed later in on DwarfFixupTable.Finalize, which applies any
|
|
|
|
|
// outstanding fixups.
|
|
|
|
|
func (ft *DwarfFixupTable) RegisterChildDIEOffsets(s *LSym, vars []*dwarf.Var, coffsets []int32) {
|
|
|
|
|
// Length of these two slices should agree
|
|
|
|
|
if len(vars) != len(coffsets) {
|
|
|
|
|
ft.ctxt.Diag("internal error: RegisterChildDIEOffsets vars/offsets length mismatch")
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Generate the slice of declOffset's based in vars/coffsets
|
|
|
|
|
doffsets := make([]declOffset, len(coffsets))
|
2018-04-05 12:11:32 +01:00
|
|
|
for i := range coffsets {
|
2017-10-06 11:32:28 -04:00
|
|
|
doffsets[i].dclIdx = vars[i].ChildIndex
|
|
|
|
|
doffsets[i].offset = coffsets[i]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ft.mu.Lock()
|
|
|
|
|
defer ft.mu.Unlock()
|
|
|
|
|
|
|
|
|
|
// Store offsets for this symbol.
|
|
|
|
|
idx, found := ft.symtab[s]
|
|
|
|
|
if !found {
|
|
|
|
|
sf := symFixups{inlIndex: -1, defseen: true, doffsets: doffsets}
|
|
|
|
|
ft.svec = append(ft.svec, sf)
|
|
|
|
|
ft.symtab[s] = len(ft.svec) - 1
|
|
|
|
|
} else {
|
|
|
|
|
sf := &ft.svec[idx]
|
|
|
|
|
sf.doffsets = doffsets
|
|
|
|
|
sf.defseen = true
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (ft *DwarfFixupTable) processFixups(slot int, s *LSym) {
|
|
|
|
|
sf := &ft.svec[slot]
|
|
|
|
|
for _, f := range sf.fixups {
|
|
|
|
|
dfound := false
|
2018-04-05 12:11:32 +01:00
|
|
|
for _, doffset := range sf.doffsets {
|
|
|
|
|
if doffset.dclIdx == f.dclidx {
|
|
|
|
|
f.refsym.R[f.relidx].Add += int64(doffset.offset)
|
2017-10-06 11:32:28 -04:00
|
|
|
dfound = true
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if !dfound {
|
|
|
|
|
ft.ctxt.Diag("internal error: DwarfFixupTable has orphaned fixup on %v targeting %v relidx=%d dclidx=%d", f.refsym, s, f.relidx, f.dclidx)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// return the LSym corresponding to the 'abstract subprogram' DWARF
|
|
|
|
|
// info entry for a function.
|
|
|
|
|
func (ft *DwarfFixupTable) AbsFuncDwarfSym(fnsym *LSym) *LSym {
|
|
|
|
|
// Protect against concurrent access if multiple backend workers
|
|
|
|
|
ft.mu.Lock()
|
|
|
|
|
defer ft.mu.Unlock()
|
|
|
|
|
|
|
|
|
|
if fnstate, found := ft.precursor[fnsym]; found {
|
|
|
|
|
return fnstate.absfn
|
|
|
|
|
}
|
|
|
|
|
ft.ctxt.Diag("internal error: AbsFuncDwarfSym requested for %v, not seen during inlining", fnsym)
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Called after all functions have been compiled; the main job of this
|
|
|
|
|
// function is to identify cases where there are outstanding fixups.
|
|
|
|
|
// This scenario crops up when we have references to variables of an
|
|
|
|
|
// inlined routine, but that routine is defined in some other package.
|
|
|
|
|
// This helper walks through and locate these fixups, then invokes a
|
|
|
|
|
// helper to create an abstract subprogram DIE for each one.
|
|
|
|
|
func (ft *DwarfFixupTable) Finalize(myimportpath string, trace bool) {
|
|
|
|
|
if trace {
|
|
|
|
|
ft.ctxt.Logf("DwarfFixupTable.Finalize invoked for %s\n", myimportpath)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Collect up the keys from the precursor map, then sort the
|
|
|
|
|
// resulting list (don't want to rely on map ordering here).
|
|
|
|
|
fns := make([]*LSym, len(ft.precursor))
|
|
|
|
|
idx := 0
|
2018-04-05 12:11:32 +01:00
|
|
|
for fn := range ft.precursor {
|
2017-10-06 11:32:28 -04:00
|
|
|
fns[idx] = fn
|
|
|
|
|
idx++
|
|
|
|
|
}
|
|
|
|
|
sort.Sort(bySymName(fns))
|
|
|
|
|
|
|
|
|
|
// Should not be called during parallel portion of compilation.
|
|
|
|
|
if ft.ctxt.InParallel {
|
|
|
|
|
ft.ctxt.Diag("internal error: DwarfFixupTable.Finalize call during parallel backend")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Generate any missing abstract functions.
|
2018-04-05 12:11:32 +01:00
|
|
|
for _, s := range fns {
|
2017-10-06 11:32:28 -04:00
|
|
|
absfn := ft.AbsFuncDwarfSym(s)
|
|
|
|
|
slot, found := ft.symtab[absfn]
|
|
|
|
|
if !found || !ft.svec[slot].defseen {
|
|
|
|
|
ft.ctxt.GenAbstractFunc(s)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Apply fixups.
|
2018-04-05 12:11:32 +01:00
|
|
|
for _, s := range fns {
|
2017-10-06 11:32:28 -04:00
|
|
|
absfn := ft.AbsFuncDwarfSym(s)
|
|
|
|
|
slot, found := ft.symtab[absfn]
|
|
|
|
|
if !found {
|
|
|
|
|
ft.ctxt.Diag("internal error: DwarfFixupTable.Finalize orphan abstract function for %v", s)
|
|
|
|
|
} else {
|
|
|
|
|
ft.processFixups(slot, s)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type bySymName []*LSym
|
|
|
|
|
|
|
|
|
|
func (s bySymName) Len() int { return len(s) }
|
|
|
|
|
func (s bySymName) Less(i, j int) bool { return s[i].Name < s[j].Name }
|
|
|
|
|
func (s bySymName) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
|