This is a pre requesite of CL 21722 and removes a lot of unidiomatic
boilerplate in the linker.
Change-Id: If7491b88212b2be7b0c8c588e9c196839131f8ad
Reviewed-on: https://go-review.googlesource.com/21780
Run-TryBot: Dave Cheney <dave@cheney.net>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
API could still be made more Go-ey.
Updates #15165.
Change-Id: I514ffceffa43c293ae5d7e5f1e9193fda0098865
Reviewed-on: https://go-review.googlesource.com/21644
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Information about CPU architectures (e.g., name, family, byte
ordering, pointer and register size) is currently redundantly
scattered around the source tree. Instead consolidate the basic
information into a single new package cmd/internal/sys.
Also, introduce new sys.I386, sys.AMD64, etc. names for the constants
'8', '6', etc. and replace most uses of the latter. The notable
exceptions are a couple of error messages that still refer to the old
char-based toolchain names and function reltype in cmd/link.
Passes toolstash/buildall.
Change-Id: I8a6f0cbd49577ec1672a98addebc45f767e36461
Reviewed-on: https://go-review.googlesource.com/21623
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It was just a funny way of saying len(Ctxt.Allsym) by now.
Change-Id: Iff75e73c9f7ec4ba26cfef479bbd05d7dcd172f5
Reviewed-on: https://go-review.googlesource.com/20973
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Today the linker keeps all methods of reachable types. This is
necessary if a program uses reflect.Value.Call. But while use of
reflection is widespread in Go for encoders and decoders, using
it to call a method is rare.
This CL looks for the use of reflect.Value.Call in a program, and
if it is absent, adopts a (reasonably conservative) method pruning
strategy as part of dead code elimination. Any method that is
directly called is kept, and any method that matches a used
interface's method signature is kept.
Whether or not a method body is kept is determined by the relocation
from its receiver's *rtype to its *rtype. A small change in the
compiler marks these relocations as R_METHOD so they can be easily
collected and manipulated by the linker.
As a bonus, this technique removes the text segment of methods that
have been inlined. Looking at the output of building cmd/objdump with
-ldflags=-v=2 shows that inlined methods like
runtime.(*traceAllocBlockPtr).ptr are removed from the program.
Relatively little work is necessary to do this. Linking two
examples, jujud and cmd/objdump show no more than +2% link time.
Binaries that do not use reflect.Call.Value drop 4 - 20% in size:
addr2line: -793KB (18%)
asm: -346KB (8%)
cgo: -490KB (10%)
compile: -564KB (4%)
dist: -736KB (17%)
fix: -404KB (12%)
link: -328KB (7%)
nm: -827KB (19%)
objdump: -712KB (16%)
pack: -327KB (14%)
yacc: -350KB (10%)
Binaries that do use reflect.Call.Value see a modest size decrease
of 2 - 6% thanks to pruning of unexported methods:
api: -151KB (3%)
cover: -222KB (4%)
doc: -106KB (2.5%)
pprof: -314KB (3%)
trace: -357KB (4%)
vet: -187KB (2.7%)
jujud: -4.4MB (5.8%)
cmd/go: -384KB (3.4%)
The trivial Hello example program goes from 2MB to 1.68MB:
package main
import "fmt"
func main() {
fmt.Println("Hello, 世界")
}
Method pruning also helps when building small binaries with
"-ldflags=-s -w". The above program goes from 1.43MB to 1.2MB.
Unfortunately the linker can only tell if reflect.Value.Call has been
statically linked, not if it is dynamically used. And while use is
rare, it is linked into a very common standard library package,
text/template. The result is programs like cmd/go, which don't use
reflect.Value.Call, see limited benefit from this CL. If binary size
is important enough it may be possible to address this in future work.
For #6853.
Change-Id: Iabe90e210e813b08c3f8fd605f841f0458973396
Reviewed-on: https://go-review.googlesource.com/20483
Reviewed-by: Russ Cox <rsc@golang.org>
Deleting the string merging pass makes the linker 30-35% faster
but makes jujud (using the github.com/davecheney/benchjuju snapshot) 2.5% larger.
Two optimizations bring the space overhead down to 0.6%.
First, change the default alignment for string data to 1 byte.
(It was previously defaulting to larger amounts, usually pointer width.)
Second, write out the type string for T (usually a bigger expression) as "*T"[1:],
so that the type strings for T and *T share storage.
Combined, these obtain the bulk of the benefit of string merging
at essentially no cost. The remaining benefit from string merging
is not worth the excessive cost, so delete it.
As penance for making the jujud binary 0.6% larger,
the next CL in this sequence trims the reflect functype
information enough to make the jujud binary overall 0.75% smaller
(that is, that CL has a net -1.35% effect).
For #6853.
Fixes#14648.
Change-Id: I3fdd74c85410930c36bb66160ca4174ed540fc6e
Reviewed-on: https://go-review.googlesource.com/20334
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
They were only used for rtype.ptrToThis which David Crawshaw removed a couple
of weeks ago. Removes two traversals of Ctxt.Allsym from the linker but it
doesn't seem to make much difference to performance.
Change-Id: I5c305e0180186f643221d57822d301de4aa18827
Reviewed-on: https://go-review.googlesource.com/20287
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL introduces a mergestrings pass after the reachability
analysis to combine all reachable go.string."..." character data
symbols into a single symbol.
Shrinks juju by 1.2mb (1.5%).
Shrinks cmd/go by 0.5% when building without DWARF.
No noticable effect on linker speed.
Change-Id: I2ba3e60bf418f65766bda257f6ca9eea26d895b6
Reviewed-on: https://go-review.googlesource.com/20165
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It looks like the compiler still uses the Cfunc flag for functions
marked as //go:systemstack, but if I'm reading this right, that
doesn't apply here and the linker no longer needs Cfunc.
Change-Id: I63b9192c2f52f41401263c29dc8dfd8be8a901a1
Reviewed-on: https://go-review.googlesource.com/20105
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The Go 1.6 release notes say we'll remove the “-X name value” form
(in favor of the “-X name=value” form) in Go 1.7.
Do that.
Also establish the doc/go1.7.txt file.
Change-Id: Ie4565a6bc5dbcf155181754d8d92bfbb23c75338
Reviewed-on: https://go-review.googlesource.com/19614
Reviewed-by: Ian Lance Taylor <iant@golang.org>
People who want to use -buildmode=c-archive in unusual cross-compilation
setups will need something like this. It could also be done via (yet
another) environment variable but I use -extar by analogy with the
existing -extld.
Change-Id: I354cfabc4c470603affd13cd946997b3a24c0e6c
Reviewed-on: https://go-review.googlesource.com/18913
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
An internal link may need the C compiler support library, libgcc.a. Add
a -libgcc option to set the name of the compiler support library. If
-libgcc is not used, run the compiler to find it. Permit -libgcc=none
to skip using libgcc at all and hope for the best.
Change cmd/dist to not copy libgcc into the distribution. Add tests to
ensure that all the standard packages that use cgo can be linked in
internal mode without using libgcc. This ensures that somebody with a
Go installation without a C compiler can build programs.
Change-Id: I8ba35fb87ab0dd20e5cc0166b5f4145b04ce52a4
Reviewed-on: https://go-review.googlesource.com/16993
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
The -msan option causes the linker to link against the runtime/msan
package in order to use the C/C++ memory sanitizer.
This CL passes tests but is not usable by itself. The actual
runtime/msan package, and support for -msan in the go tool and the
compiler, and tests, are in separate CLs.
Change-Id: I02c097393b98c5b80e40ee3dbc167a8b4d23efe0
Reviewed-on: https://go-review.googlesource.com/16161
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The -W option has not worked since Go 1.3. It is not documented. When
it did work, it generated useful output, but it was for human viewing;
there was no reason to write a script that passes the -W option, so it's
unlikely that anybody is using it today.
Change-Id: I4769f1ffd308a48324a866592eb7fd79a4cdee54
Reviewed-on: https://go-review.googlesource.com/15701
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also fix the interaction between -buildmode and -shared.
It's okay for -shared to change the default build mode,
but it's not okay for it to silently override an explicit -buildmode=exe.
Change-Id: Id40f93d140cddf75b19e262b3ba4856ee09a07ba
Reviewed-on: https://go-review.googlesource.com/10315
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
People invoking the linker directly already have to change their scripts
to use the new "go tool link", so this is a good time to make the -X flag
behave like all other Go flags and take just a single argument.
The old syntax will continue to be accepted (it is rewritten into the new
syntax before flag parsing). Maybe some day we will be able to retire it.
Even if we never retire the old syntax, having the new syntax at least
makes the rewriting much less of a kludge.
Change-Id: I91e8df94f4c22b2186e81d7f1016b8767d777eac
Reviewed-on: https://go-review.googlesource.com/10310
Reviewed-by: Rob Pike <r@golang.org>
Non-ELF binary formats are much less flexible and typically do not
have a good place to store the build ID.
We store it as raw bytes at the beginning of the text segment.
The only system I know of that will be upset about this is NaCl,
and NaCl is an ELF system and does not use this.
For #11048.
Change-Id: Iaa7ace703c4cf36392e752eea9b55e2ce49e9826
Reviewed-on: https://go-review.googlesource.com/10708
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Other binary formats to follow.
Using our own note instead of the GNU build ID note because
we are not the GNU project, and I can't guarantee that the semantics
of our note and the semantics of the GNU note will match forever.
(Also they don't match today.)
For #11048.
Change-Id: Iec7e5a2e49d52b6d3a51b0aface2de7c77a45491
Reviewed-on: https://go-review.googlesource.com/10706
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL removes the remaining visible uses of the "architecture letter" concept.
(They are no longer in tool names nor in source directory names.)
Because the architecture letter concept is now gone, delete GOCHAR
from "go env" output, and change go/build.ArchChar to return an
error always.
The architecture letter is still used in the compiler and linker sources
as a clumsy architecture enumeration, but that use is not visible to
Go users and can be cleaned up separately.
Change-Id: I4d97a38f372003fb610c9c5241bea440d9dbeb8d
Reviewed-on: https://go-review.googlesource.com/10289
Reviewed-by: Rob Pike <r@golang.org>
Trivial merging of 5g, 6g, ... into go tool compile,
and similarlly 5l, 6l, ... into go tool link.
The files compile/main.go and link/main.go are new.
Everything else in those directories is a move followed by
change of imports and package name.
This CL breaks the build. Manual fixups are in the next CL.
See golang-dev thread titled "go tool compile, etc" for background.
Change-Id: Id35ff5a5859ad9037c61275d637b1bd51df6828b
Reviewed-on: https://go-review.googlesource.com/10287
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Rob Pike <r@golang.org>
