| Age | Commit message (Collapse) | Author |
|---|
|
As of CL 247399 we use separate symbols for PCDATA. There is no
more need for writing PCDATA directly into the object file as a
separate block.
Change-Id: I942d1a372540415e0cc07fb2a01f79718a264142
Reviewed-on: https://go-review.googlesource.com/c/go/+/352610
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
|
|
Create constant LocalDictName for the pname/refix for dictionary
parameters or local variables, and constant GlobalDictPrefix for the
prefix for names of global dictionaries. I wanted to make sure these
constants were set up as we add more reference to dictionaries for
debugging, etc.
Change-Id: Ide801f842383300a2699c96943ec06decaecc358
Reviewed-on: https://go-review.googlesource.com/c/go/+/351450
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Generate debug_info entries for types that are only referenced through
dictionaries.
Change-Id: Ic36c2e6d9588ec6746793bb213c2dc0e17a8a850
Reviewed-on: https://go-review.googlesource.com/c/go/+/350532
Run-TryBot: Alessandro Arzilli <alessandro.arzilli@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: David Chase <drchase@google.com>
|
|
Still 1-1 with real types, but now with their own names!
Shape types are implicitly convertible to (and convertible from)
the types they represent.
Change-Id: I0133a8d8fbeb369380574b075a32b3c987e314d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/335170
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
|
|
Currently, relocation type is stored as uint8 in object files, as
Go relocations do not exceed 255. In the linker, however, it is
used as a 16-bit type, because external relocations can exceed
255. The linker has to store the extra byte in a side table. This
complicates many things.
Just store it as uint16 in object files. This simplifies things,
with a small cost of increasing the object file sizes.
before after
hello.o 1672 1678
runtime.a 7927784 8056194
Change-Id: I313cf44ad0b8b3b76e35055ae55d911ff35e3158
Reviewed-on: https://go-review.googlesource.com/c/go/+/268477
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Change-Id: Ib689e5793d9cb372e759c4f34af71f004010c822
GitHub-Last-Rev: d63798388e5dcccb984689b0ae39b87453b97393
GitHub-Pull-Request: golang/go#44259
Reviewed-on: https://go-review.googlesource.com/c/go/+/291949
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
|
|
The runtime traceback code has its own definition of which functions
mark the top frame of a stack, separate from the TOPFRAME bits that
exist in the assembly and are passed along in DWARF information.
It's error-prone and redundant to have two different sources of truth.
This CL provides the actual TOPFRAME bits to the runtime, so that
the runtime can use those bits instead of reinventing its own category.
This CL also adds a new bit, SPWRITE, which marks functions that
write directly to SP (anything but adding and subtracting constants).
Such functions must stop a traceback, because the traceback has no
way to rederive the SP on entry. Again, the runtime has its own definition
which is mostly correct, but also missing some functions. During ordinary
goroutine context switches, such functions do not appear on the stack,
so the incompleteness in the runtime usually doesn't matter.
But profiling signals can arrive at any moment, and the runtime may
crash during traceback if it attempts to unwind an SP-writing frame
and gets out-of-sync with the actual stack. The runtime contains code
to try to detect likely candidates but again it is incomplete.
Deriving the SPWRITE bit automatically from the actual assembly code
provides the complete truth, and passing it to the runtime lets the
runtime use it.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I227f53b23ac5b3dabfcc5e8ee3f00df4e113cf58
Reviewed-on: https://go-review.googlesource.com/c/go/+/288800
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
This commit contains the compiler support for //go:embed lines.
The go command passes to the compiler an "embed config"
that maps literal patterns like *.txt to the set of files to embed.
The compiler then lays out the content of those files as static data
in the form of an embed.Files or string or []byte in the final object file.
The test for this code is the end-to-end test hooking up the
embed, cmd/compile, and cmd/go changes, in the next CL.
For #41191.
Change-Id: I916e57f8cc65871dc0044c13d3f90c252a3fe1bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/243944
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
We never supported symbol larger than 2GB (issue #9862), so the
object file uses 32-bit for symbol sizes. Check and reject too
large symbol before truncating its size.
Fixes #42054.
Change-Id: I0d1d585ebdba9556f2fd3a97043bd4296d5cc9e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/263641
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
This creates space for a different kind of extension field
in LSym without making the struct any larger.
(There are many LSym, so we care about keeping the struct small.)
Change-Id: Ib16edb9e15f54c2a7351c8b875e19684058711e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/243943
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
2 conflicts, that make sense.
src/cmd/internal/obj/objfile.go
src/cmd/link/internal/loader/loader.go
Change-Id: Ib224e2d248cb568fa1e888af79dd908b2f5e05ff
|
|
Type namedata symbols are for type/field/method names and package
paths. We can use content-addressable symbol mechanism for them.
Change-Id: I923fda17b7094c7a0e46aad7c450622eb3826294
Reviewed-on: https://go-review.googlesource.com/c/go/+/257960
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
In CL 255718 the -S=2 assembly output was enhanced to dump symbol
ABIs. This patch fixes a bug in that CL: when dumping the relocations
on a symbol, we were dumping the symbol's ABI as opposed to the
relocation target symbol's ABI.
Change-Id: I134128687757f549fa37b998cff1290765889140
Reviewed-on: https://go-review.googlesource.com/c/go/+/257202
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
When -S=2 is in effect for the compiler/assembler, include symbol ABI
values for defined symbols and relocations. This is intended to help
make it easier to distinguish between a symbol and its ABI wrapper.
Change-Id: Ifbf71372392075f15363b40e882b2132406b7d6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255718
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Switch pcdata over to content addressable symbols. This is the last
step before removing these from pclntab_old.
No meaningful benchmarks changes come from this work.
Change-Id: I3f74f3d6026a278babe437c8010e22992c92bd89
Reviewed-on: https://go-review.googlesource.com/c/go/+/247399
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
While working on deduplicating pcdata, I found that the following hashed
symbols would result in the same:
[] == [0,0,0,0....]
This makes using content addressable symbols untenable for pcdata.
Adding the length to the hash keeps the dream alive.
No difference in binary size (darwin, cmd/compile), spurious
improvements in DWARF phase memory.
Change-Id: I21101f7754a3d870922b0dea39c947cc8509432f
Reviewed-on: https://go-review.googlesource.com/c/go/+/247903
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Combine objfile2.go into objfile.go.
objfile.go has a lot of code for DWARF generation. Move them to
dwarf.go.
Change-Id: I2a27c672e9e9b8eea35d5e0a71433dcc80b7afa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/247918
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Leaving creation of the funcID till the linker requires the linker to
load the function and file names into memory. Moving these into the
compiler/assembler prevents this.
This work is a step towards moving all func metadata into the compiler.
Change-Id: Iebffdc5a909adbd03ac263fde3f4c3d492fb1eac
Reviewed-on: https://go-review.googlesource.com/c/go/+/244024
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
|
|
This change splits the SDWARFINFO symbol type (a generic container of
DWARF content) into separate sub-classes. The new symbol types are
SDWARFCUINFO comp unit DIE, also CU info and CU packagename syms
SDWARFCONST constant DIE
SDWARFFCN subprogram DIE (default and concrete)
SDWARFABSFCN abstract function DIE
SDWARFTYPE type DIE
SDWARFVAR global variable DIE
Advantage of doing this: in the linker there are several places where
we have to iterate over a symbol's relocations to pick out references
to specific classes of DWARF sub-symbols (for example, looking for all
abstract function DIEs referenced by a subprogram DIE, or looking at
all the type DIEs used in a subprogram DIE). By splitting SDWARFINFO
into parts clients can now look only at the relocation target's sym
type as opposed to having to materialize the target sym name, or do a
lookup.
Change-Id: I4e0ee3216d3c8f1a78bec3d296c01e95b3d025b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/234684
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
Change-Id: I85b653b621ad8cb2ef27886210ea2c4b7409b60d
|
|
When the concurrent back end is not enabled, it is possible to have a
scenario where: we compile a specific inlinable non-pointer-receiver
method T.M, then at some point later on in the compilation we visit a
type that triggers generation of a pointer-receiver wrapper (*T).M,
which then results in an inline of T.M into (*T).M. This introduces
subtle differences in the DWARF as compared with when the concurrent
back end is enabled (in the concurrent case, by the time we run the
SSA back end on T.M is is marked as being inlined, whereas in the
non-current case it is not marked inlined).
As a fix, at the point where we would normally compile a given
function in the xtop list right away, if the function is a method AND
is inlinable AND hasn't been inlined, then delay its compilation until
compileFunctions (so as to make sure that when we do compile it, all
possible inlining has been complete). In addition, make sure that
the abstract function symbol for the inlined function gets recorded
correctly.
Fixes #38068.
Change-Id: I57410ab5658bd4ee5b4b80750518e9b20fd6ba52
Reviewed-on: https://go-review.googlesource.com/c/go/+/234178
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
We are not going to merge to master until Go 1.16 cycle. The old
object support can go now.
Change-Id: I93e6f584974c7749d0a0c2e7a96def35134dc566
Reviewed-on: https://go-review.googlesource.com/c/go/+/231918
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
The new object files use indices for symbol references, instead
of names. Fundamental to the design, it requires that the
importing and imported packages have consistent view of symbol
indices. The Go command should already ensure this, when using
"go build". But in case it goes wrong, it could lead to obscure
errors like run-time crashes. It would be better to check the
index consistency at build time.
To do that, we add a fingerprint to each object file, which is
a hash of symbol indices. In the object file it records the
fingerprints of all imported packages, as well as its own
fingerprint. At link time, the linker checks that a package's
fingerprint matches the fingerprint recorded in the importing
packages, and issue an error if they don't match.
This CL does the first part: introducing the fingerprint in the
object file, and propagating fingerprints through
importing/exporting by the compiler. It is not yet used by the
linker. Next CL will do.
Change-Id: I0aa372da652e4afb11f2867cb71689a3e3f9966e
Reviewed-on: https://go-review.googlesource.com/c/go/+/229617
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
Compiling with -S was not implemented with performance in mind.
It allocates profligately. Compiling with -S is ~58% slower,
allocates ~47% more memory, and does ~183% more allocations.
compilecmp now uses -S to do finer-grained comparisons between
compiler versions, so I now care about its performance.
This change picks some of the lowest hanging fruit,
mostly by modifying printing routines to print directly to a writer,
rather than constructing a string first.
I have confirmed that compiling std+cmd with "-gcflags=all=-S -p=1"
and CGO_ENABLED=0 yields identical results before/after this change.
(-p=1 makes package compilation order deterministic. CGO_ENABLED=0
prevents cgo temp workdirs from showing up in filenames.)
Using the -S flag, the compiler performance impact is:
name old time/op new time/op delta
Template 344ms ± 2% 301ms ± 2% -12.45% (p=0.000 n=22+24)
Unicode 136ms ± 3% 121ms ± 3% -11.40% (p=0.000 n=24+25)
GoTypes 1.24s ± 5% 1.09s ± 3% -12.58% (p=0.000 n=25+25)
Compiler 5.66s ± 4% 5.06s ± 2% -10.56% (p=0.000 n=25+20)
SSA 19.9s ± 3% 17.2s ± 4% -13.64% (p=0.000 n=25+25)
Flate 212ms ± 2% 188ms ± 2% -11.33% (p=0.000 n=25+24)
GoParser 278ms ± 3% 242ms ± 1% -12.84% (p=0.000 n=23+24)
Reflect 743ms ± 3% 657ms ± 5% -11.56% (p=0.000 n=24+25)
Tar 295ms ± 2% 263ms ± 2% -10.78% (p=0.000 n=25+25)
XML 409ms ± 2% 360ms ± 3% -12.03% (p=0.000 n=24+25)
[Geo mean] 714ms 629ms -11.92%
name old user-time/op new user-time/op delta
Template 430ms ± 5% 388ms ± 3% -9.76% (p=0.000 n=21+24)
Unicode 202ms ±12% 171ms ± 5% -15.21% (p=0.000 n=25+23)
GoTypes 1.58s ± 3% 1.42s ± 3% -9.58% (p=0.000 n=24+24)
Compiler 7.42s ± 3% 6.68s ± 8% -9.93% (p=0.000 n=25+25)
SSA 26.9s ± 3% 22.9s ± 3% -14.85% (p=0.000 n=25+25)
Flate 260ms ± 6% 234ms ± 3% -9.69% (p=0.000 n=23+25)
GoParser 354ms ± 1% 296ms ± 3% -16.46% (p=0.000 n=23+25)
Reflect 953ms ± 2% 865ms ± 4% -9.14% (p=0.000 n=24+24)
Tar 380ms ± 2% 348ms ± 2% -8.28% (p=0.000 n=25+22)
XML 530ms ± 3% 451ms ± 3% -15.01% (p=0.000 n=24+23)
[Geo mean] 929ms 819ms -11.84%
name old alloc/op new alloc/op delta
Template 54.1MB ± 0% 44.3MB ± 0% -18.24% (p=0.000 n=24+24)
Unicode 33.5MB ± 0% 30.6MB ± 0% -8.57% (p=0.000 n=25+25)
GoTypes 189MB ± 0% 152MB ± 0% -19.55% (p=0.000 n=25+23)
Compiler 875MB ± 0% 703MB ± 0% -19.70% (p=0.000 n=25+25)
SSA 3.19GB ± 0% 2.51GB ± 0% -21.50% (p=0.000 n=25+25)
Flate 32.9MB ± 0% 27.3MB ± 0% -17.04% (p=0.000 n=25+25)
GoParser 43.9MB ± 0% 35.1MB ± 0% -20.19% (p=0.000 n=25+25)
Reflect 117MB ± 0% 96MB ± 0% -18.22% (p=0.000 n=24+23)
Tar 48.6MB ± 0% 40.6MB ± 0% -16.39% (p=0.000 n=25+24)
XML 65.7MB ± 0% 53.9MB ± 0% -17.93% (p=0.000 n=25+23)
[Geo mean] 118MB 97MB -17.80%
name old allocs/op new allocs/op delta
Template 1.07M ± 0% 0.60M ± 0% -43.90% (p=0.000 n=25+24)
Unicode 539k ± 0% 398k ± 0% -26.20% (p=0.000 n=23+25)
GoTypes 3.97M ± 0% 2.19M ± 0% -44.90% (p=0.000 n=25+24)
Compiler 17.6M ± 0% 9.5M ± 0% -46.39% (p=0.000 n=22+23)
SSA 66.1M ± 0% 34.1M ± 0% -48.41% (p=0.000 n=25+22)
Flate 629k ± 0% 365k ± 0% -41.95% (p=0.000 n=25+25)
GoParser 929k ± 0% 500k ± 0% -46.11% (p=0.000 n=25+25)
Reflect 2.49M ± 0% 1.47M ± 0% -41.00% (p=0.000 n=24+25)
Tar 919k ± 0% 534k ± 0% -41.94% (p=0.000 n=25+24)
XML 1.28M ± 0% 0.71M ± 0% -44.72% (p=0.000 n=25+24)
[Geo mean] 2.32M 1.33M -42.82%
This change also speeds up cmd/objdump a modest amount, ~4%.
Change-Id: I7c7aa2b365688bc44b3ef6e1d03bcf934699cabc
Reviewed-on: https://go-review.googlesource.com/c/go/+/216857
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This ports CL 226997 to the dev.link branch.
- The assembler part and old object file writing are unchanged.
- Changes to cmd/link are applied to cmd/oldlink.
- Add alignment field to new object files for the new linker.
Change-Id: Id00f323ae5bdd86b2709a702ee28bcaa9ba962f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/227025
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
When old object file format is used, serialize DWARF symbols in
the old way.
Change-Id: I73a97f10bba367ac29c52f8f3d0f8f3b34a42523
Reviewed-on: https://go-review.googlesource.com/c/go/+/224624
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Add back the newobj flag, renamed to go115newobj, for feature
gating. The flag defaults to true.
This essentially reverts CL 206398 as well as CL 220060.
The old object format isn't working yet. Will fix in followup CLs.
Change-Id: I1ace2a9cbb1a322d2266972670d27bda4e24adbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/224623
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
This patch moves the compiler and linker away from the current scheme
used to generate file references in DWARF subprogram dies.
Up until now the scheme has been to have the compiler emit a special
relocation on a DIE file reference that points to the file symbol in
question. The linker then reads this relocation and updates the addend
to the index of the appropriate file in the line table of the
compilation unit of the DIE (the linker emits the comp unit file
table, so it knows at that point what number use). The drawback of
this scheme is that it requires a lot of relocation processing.
With this patch, we switch to having the compiler emit the file index
directly, and then have the linker use the compiler-generated file
table to emit the line table file section (no renumbering, no
relocations, etc).
Change-Id: Id4fbe67b28a64200a083e3c5ea358dbe091ec917
Reviewed-on: https://go-review.googlesource.com/c/go/+/223318
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Switch the primary subprogram die DWARF symbol emitted by the compiler
from named+dupOK to anonymous aux. This should help performance wise
by not having to add these symbols to the linker's symbol name lookup
tables.
Change-Id: Idf66662b8bf60b3dee9a55e6cd5137b24a9f5ab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/223669
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Convert DWARF .debug_line symbols to anonymous aux syms, so as
to save space in object files and reduce the number of symbols
that have to be added to the linker's lookup tables.
Change-Id: I5b350f036e21a7a7128cb08148ab7c243aaf0d0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/223018
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
For compiler developers interested in seeing DWARF generation details,
this patch provides symbol "debug asm" dumps for DWARF aux symbols
when -S=2 is in effect.
Change-Id: I5a0b6b65ce7b708948cbbf23c6b0d279bd4f8d9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/223017
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
When the compiler emits DWARF for a function F, in addition to the
text symbol for F, it emits a set of sibling or child symbols that
carry the various DWARF bits for F (for example, go.info.F,
go.ranges.F, go.loc.F, and so on).
Prior to the linker modernization work, name lookup was the way you
made your way from a function symbol to one of its child DWARF
symbols. We now have a new mechanism (aux symbols), so there is really
no need for the DWARF sub-symbols to be named or to be dupok.
This patch converts DWARF "range" and "loc" sub-symbols to be pure aux
syms: unnamed, and connected to their parent text symbol only via aux
data. This should presumably have performance benefits in that we add
fewer symbols to the linker lookup tables.
Other related DWARF sub-symbols (ex: go.line.*) will be handled in a
subsequent patch.
Change-Id: Iae3ec2d42452962d4afc1df4a1bd89ccdeadc6e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/222673
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Get rid of of the linker's dwSym struct (which wraps a loader.Loader
and a loader.Sym) in favor of just loader.Sym. This requires some minor
tweaks to the cmd/internal/dwarf interfaces.
Change-Id: Id3ffd7c41b2433ea04417040368700334bb0e611
Reviewed-on: https://go-review.googlesource.com/c/go/+/220982
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
There are more cleanups to do, but I want to keep this CL mostly
a pure deletion.
Change-Id: Icd2ff0a4b648eb4adf3d29386542617e49620818
Reviewed-on: https://go-review.googlesource.com/c/go/+/206398
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
When the compiler's -S flag is specified, it dumps the
disassembly. Add this when writing the new style object file.
Change-Id: I4cf85e57d22d0ceea1fda6d3b59fe363573659e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/200100
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
If -newobj is set, write object file in new format, which uses
indices for symbol references instead of symbol names. The file
format is described at the beginning of
cmd/internal/goobj2/objfile.go.
A new package, cmd/internal/goobj2, is introduced for reading and
writing new object files. (The package name is temporary.) It is
written in a way that trys to make the encoding as regular as
possible, and the reader and writer as symmetric as possible.
This is incomplete, and currently nothing will consume the new
object file.
Change-Id: Ifefedbf6456d760d15a9f40a28af6486c93100fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/196030
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
It is convenient to have a seekable writer. A later CL will make
use of Seek.
Change-Id: Iba0107ce2975d9a451d97f16aa91a318dd4c90e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/196028
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
Don't write Autom records when writing a function to the object file;
we no longer need them in the linker for DWARF processing. So as to
keep the object file format unchanged, write out a zero-length list of
automs to the object, as opposed to removing all references.
Updates #34554.
Change-Id: I42a1d67207ea7114ae4f3a315cf37effba57f190
Reviewed-on: https://go-review.googlesource.com/c/go/+/197499
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
During DWARF processing, keep track of the go type symbols for types
directly or indirectly referenced by auto variables in a function,
and add a set of dummy R_USETYPE relocations to the function's DWARF
subprogram DIE symbol.
This change is not useful on its own, but is part of a series of
changes intended to clean up handling of autom's in the compiler
and linker.
Updates #34554.
Change-Id: I974afa9b7092aa5dba808f74e00aa931249d6fe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/197497
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
As promised in CL 188238, removing the obsolete symbol.
Here are the latest stats. This is baselined at "e53edafb66" with only
these changes applied, run on magna.cam. The linker looks straight
better (in memory and speed).
There is still a change I'm working on walking the progs to generate the
debug_lines data in the compiler. That will likely result in a compiler
speedup.
name old time/op new time/op delta
Template 324ms ± 3% 317ms ± 3% -2.07% (p=0.043 n=10+10)
Unicode 142ms ± 4% 144ms ± 3% ~ (p=0.393 n=10+10)
GoTypes 1.05s ± 2% 1.07s ± 2% +1.59% (p=0.019 n=9+9)
Compiler 4.09s ± 2% 4.11s ± 1% ~ (p=0.218 n=10+10)
SSA 12.5s ± 1% 12.7s ± 1% +1.00% (p=0.035 n=10+10)
Flate 199ms ± 7% 203ms ± 5% ~ (p=0.481 n=10+10)
GoParser 245ms ± 3% 246ms ± 5% ~ (p=0.780 n=9+10)
Reflect 672ms ± 4% 688ms ± 3% +2.42% (p=0.015 n=10+10)
Tar 280ms ± 4% 284ms ± 4% ~ (p=0.123 n=10+10)
XML 379ms ± 4% 381ms ± 2% ~ (p=0.529 n=10+10)
LinkCompiler 1.16s ± 4% 1.12s ± 2% -3.03% (p=0.001 n=10+9)
ExternalLinkCompiler 2.28s ± 3% 2.23s ± 3% -2.51% (p=0.011 n=8+9)
LinkWithoutDebugCompiler 686ms ± 9% 667ms ± 2% ~ (p=0.277 n=9+8)
StdCmd 14.1s ± 1% 14.0s ± 1% ~ (p=0.739 n=10+10)
name old user-time/op new user-time/op delta
Template 604ms ±23% 564ms ± 7% ~ (p=0.661 n=10+9)
Unicode 429ms ±40% 418ms ±37% ~ (p=0.579 n=10+10)
GoTypes 2.43s ±12% 2.51s ± 7% ~ (p=0.393 n=10+10)
Compiler 9.22s ± 3% 9.27s ± 3% ~ (p=0.720 n=9+10)
SSA 26.3s ± 3% 26.6s ± 2% ~ (p=0.579 n=10+10)
Flate 328ms ±19% 333ms ±12% ~ (p=0.842 n=10+9)
GoParser 387ms ± 5% 378ms ± 9% ~ (p=0.356 n=9+10)
Reflect 1.36s ±20% 1.43s ±21% ~ (p=0.631 n=10+10)
Tar 469ms ±12% 471ms ±21% ~ (p=0.497 n=9+10)
XML 685ms ±18% 698ms ±19% ~ (p=0.739 n=10+10)
LinkCompiler 1.86s ±10% 1.87s ±11% ~ (p=0.968 n=10+9)
ExternalLinkCompiler 3.20s ±13% 3.01s ± 8% -5.70% (p=0.046 n=8+9)
LinkWithoutDebugCompiler 1.08s ±15% 1.09s ±20% ~ (p=0.579 n=10+10)
name old alloc/op new alloc/op delta
Template 36.3MB ± 0% 36.4MB ± 0% +0.26% (p=0.000 n=10+10)
Unicode 28.5MB ± 0% 28.5MB ± 0% ~ (p=0.165 n=10+10)
GoTypes 120MB ± 0% 121MB ± 0% +0.29% (p=0.000 n=9+10)
Compiler 546MB ± 0% 548MB ± 0% +0.32% (p=0.000 n=10+10)
SSA 1.84GB ± 0% 1.85GB ± 0% +0.49% (p=0.000 n=10+10)
Flate 22.9MB ± 0% 23.0MB ± 0% +0.25% (p=0.000 n=10+10)
GoParser 27.8MB ± 0% 27.9MB ± 0% +0.25% (p=0.000 n=10+8)
Reflect 77.5MB ± 0% 77.7MB ± 0% +0.27% (p=0.000 n=9+9)
Tar 34.5MB ± 0% 34.6MB ± 0% +0.23% (p=0.000 n=10+10)
XML 44.2MB ± 0% 44.4MB ± 0% +0.32% (p=0.000 n=10+10)
LinkCompiler 239MB ± 0% 230MB ± 0% -3.86% (p=0.000 n=10+10)
ExternalLinkCompiler 243MB ± 0% 243MB ± 0% +0.22% (p=0.000 n=10+10)
LinkWithoutDebugCompiler 164MB ± 0% 155MB ± 0% -5.45% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
Template 371k ± 0% 372k ± 0% +0.44% (p=0.000 n=10+10)
Unicode 340k ± 0% 340k ± 0% +0.05% (p=0.000 n=10+10)
GoTypes 1.32M ± 0% 1.32M ± 0% +0.46% (p=0.000 n=10+10)
Compiler 5.34M ± 0% 5.37M ± 0% +0.59% (p=0.000 n=10+10)
SSA 17.6M ± 0% 17.7M ± 0% +0.63% (p=0.000 n=10+10)
Flate 233k ± 0% 234k ± 0% +0.48% (p=0.000 n=10+10)
GoParser 309k ± 0% 310k ± 0% +0.40% (p=0.000 n=10+10)
Reflect 964k ± 0% 969k ± 0% +0.54% (p=0.000 n=10+10)
Tar 346k ± 0% 348k ± 0% +0.48% (p=0.000 n=10+9)
XML 424k ± 0% 426k ± 0% +0.51% (p=0.000 n=10+10)
LinkCompiler 751k ± 0% 645k ± 0% -14.13% (p=0.000 n=10+10)
ExternalLinkCompiler 1.79M ± 0% 1.69M ± 0% -5.30% (p=0.000 n=10+10)
LinkWithoutDebugCompiler 217k ± 0% 222k ± 0% +2.02% (p=0.000 n=10+10)
name old object-bytes new object-bytes delta
Template 547kB ± 0% 559kB ± 0% +2.17% (p=0.000 n=10+10)
Unicode 215kB ± 0% 216kB ± 0% +0.60% (p=0.000 n=10+10)
GoTypes 1.99MB ± 0% 2.03MB ± 0% +2.02% (p=0.000 n=10+10)
Compiler 7.86MB ± 0% 8.07MB ± 0% +2.73% (p=0.000 n=10+10)
SSA 26.4MB ± 0% 27.2MB ± 0% +3.27% (p=0.000 n=10+10)
Flate 337kB ± 0% 343kB ± 0% +2.02% (p=0.000 n=10+10)
GoParser 432kB ± 0% 441kB ± 0% +2.11% (p=0.000 n=10+10)
Reflect 1.33MB ± 0% 1.36MB ± 0% +1.87% (p=0.000 n=10+10)
Tar 477kB ± 0% 487kB ± 0% +2.24% (p=0.000 n=10+10)
XML 617kB ± 0% 632kB ± 0% +2.33% (p=0.000 n=10+10)
name old export-bytes new export-bytes delta
Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal)
Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal)
GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal)
Compiler 109kB ± 0% 109kB ± 0% +0.09% (p=0.000 n=10+10)
SSA 137kB ± 0% 137kB ± 0% +0.03% (p=0.000 n=10+10)
Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal)
GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal)
Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal)
Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal)
XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal)
name old text-bytes new text-bytes delta
HelloSize 760kB ± 0% 760kB ± 0% ~ (all equal)
CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal)
name old data-bytes new data-bytes delta
HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal)
CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal)
name old bss-bytes new bss-bytes delta
HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal)
CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal)
name old exe-bytes new exe-bytes delta
HelloSize 1.11MB ± 0% 1.13MB ± 0% +1.10% (p=0.000 n=10+10)
CmdGoSize 14.9MB ± 0% 15.0MB ± 0% +0.77% (p=0.000 n=10+10)
Change-Id: I42e6087cd6231dbdcfff5464e46d373474e455e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/192417
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
|
|
In CL 188317, we generate the debug_lines in the compiler, and created a
new symbol to hold the line table. Here we modify the object file format
to output the file table.
Change-Id: Ibee192e80b86ff6af36467a0b1c26ee747dfee37
Reviewed-on: https://go-review.googlesource.com/c/go/+/191167
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This is mostly a copy-paste jobs from the linker to generate the debug
information in the compiler instead of the linker. The new data is
inserted into the debug line numbers symbol defined in CL 188238.
Generating the debug information BEFORE deadcode results in one subtle
difference, and that is that the state machine needs to be reset at the
end of every function's debug line table. The reasoning is that
generating the table AFTER dead code allows the producer and consumer of
the table to agree on the state of the state machine, and since these
blocks will (eventually) be concatenated in the linker, we don't KNOW
the state of the state machine unless we reset it. So,
generateDebugLinesSymbol resets the state machine at the end of every
function.
Right now, we don't do anything with this line information, or the file
table -- we just populate the symbols.
Change-Id: If9103eda6cc5f1f7a11e7e1a97184a060a4ad7fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/188317
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
|
|
This is broken out from: CL 187117
This new symbol will be populated by the compiler and contain debug line
information that's currently generated in the linker. One might say it's
sad to create a new symbol, but this symbol will replace the isStmt
symbols.
Testing: Ran go build -toolexec 'toolstash -cmp'
Change-Id: If8f7ae4b43b7247076605b6429b7d03a1fd239c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/188238
Reviewed-by: Austin Clements <austin@google.com>
|
|
Use the following (suboptimal) script to obtain a list of possible
typos:
#!/usr/bin/env sh
set -x
git ls-files |\
grep -e '\.\(c\|cc\|go\)$' |\
xargs -n 1\
awk\
'/\/\// { gsub(/.*\/\//, ""); print; } /\/\*/, /\*\// { gsub(/.*\/\*/, ""); gsub(/\*\/.*/, ""); }' |\
hunspell -d en_US -l |\
grep '^[[:upper:]]\{0,1\}[[:lower:]]\{1,\}$' |\
grep -v -e '^.\{1,4\}$' -e '^.\{16,\}$' |\
sort -f |\
uniq -c |\
awk '$1 == 1 { print $2; }'
Then, go through the results manually and fix the most obvious typos in
the non-vendored code.
Change-Id: I3cb5830a176850e1a0584b8a40b47bde7b260eae
Reviewed-on: https://go-review.googlesource.com/c/go/+/193848
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
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>
|
|
We compile package sort as part of the compiler bootstrap,
to make sure the compiler uses a consistent sort algorithm
no matter what version of Go it is compiled against.
(This matters for elements that compare "equal" but are distinguishable.)
Package sort was compiled in such a way as to disallow
sort.Slice entirely during bootstrap (at least with some compilers),
while cmd/internal/obj was compiled in such a way as to
make obj.SortSlice available to all compilers, precisely because
sort.Slice was not. This is all highly confusing.
Simplify by making sort.Slice available all the time.
Followup to CL 169137 and #30440
(and also CL 40114 and CL 73951).
Change-Id: I127f4e02d6c71392805d256c3a90ef7c51f9ba0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/174525
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This was originally
Revert "cmd/link: fix up debug_range for dsymutil (revert CL 72371)"
which has the effect of no longer using Base Address Selection
Entries in DWARF. However, the build-time costs of that are
about 2%, so instead the hacky fixup that generated technically
incorrect DWARF was removed from the linker, and the choice
is instead made in the compiler, dependent on platform, but
also under control of a flag so that we can report this bug
against LLDB/dsymutil/dwarfdump (really, the LLVM dwarf
libraries).
This however does not solve #31188; debugging still fails,
but dwarfdump no longer complains. There are at least two
LLDB bugs involved, and this change will at allow us
to report them without them being rejected because our
now-obsolete workaround for the first bug creates
not-quite-DWARF.
Updates #31188.
Change-Id: I5300c51ad202147bab7333329ebe961623d2b47d
Reviewed-on: https://go-review.googlesource.com/c/go/+/170638
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
|
|
This CL adds a new attribute, TOPFRAME, which can be used to mark
functions that should be treated as being at the top of the call
stack. The function `runtime.goexit` has been marked this way on
architectures that use a link register.
This will stop programs that use DWARF to unwind the call stack
from unwinding past `runtime.goexit` on architectures that use a
link register. For example, it eliminates "corrupt stack?"
warnings when generating a backtrace that hits `runtime.goexit`
in GDB on s390x.
Similar code should be added for non-link-register architectures
(i.e. amd64, 386). They mark the top of the call stack slightly
differently to link register architectures so I haven't added
that code (they need to mark "rip" as undefined).
Fixes #24385.
Change-Id: I15b4c69ac75b491daa0acf0d981cb80eb06488de
Reviewed-on: https://go-review.googlesource.com/c/go/+/169726
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Change-Id: Ieb0ae01cf393c4983e809ce95fedeaa854d19a99
GitHub-Last-Rev: 908f7565183c1cd19a3fbc47f406d53ad388fb97
GitHub-Pull-Request: golang/go#30004
Reviewed-on: https://go-review.googlesource.com/c/160428
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Work involved in getting a stack trace is divided between
runtime.Callers and runtime.CallersFrames.
Before this CL, runtime.Callers returns a pc per runtime frame.
runtime.CallersFrames is responsible for expanding a runtime frame
into potentially multiple user frames.
After this CL, runtime.Callers returns a pc per user frame.
runtime.CallersFrames just maps those to user frame info.
Entries in the result of runtime.Callers are now pcs
of the calls (or of the inline marks), not of the instruction
just after the call.
Fixes #29007
Fixes #28640
Update #26320
Change-Id: I1c9567596ff73dc73271311005097a9188c3406f
Reviewed-on: https://go-review.googlesource.com/c/152537
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
