Currently, both asm and compile have a -symabis flag, but in asm it's
a boolean flag that means to generate a symbol ABIs file and in the
compiler its a string flag giving the path of the symbol ABIs file to
consume. I'm worried about this false symmetry biting us in the
future, so rename asm's flag to -gensymabis.
Updates #27539.
Change-Id: I8b9c18a852d2838099718f8989813f19d82e7434
Reviewed-on: https://go-review.googlesource.com/c/149818
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now that the build system has been updated to install x/tools in
$GOPATH (CL 149658), depend on it being there and don't ignore
failures to build the tool.
Update to CL 149097.
Change-Id: I72fde347217533697068b6a6773696cc2b83e9ed
Reviewed-on: https://go-review.googlesource.com/c/150017
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
- Adds 'go vet -json' and 'go vet -c=1' flags
- Removes the pkgfact analyzer, included by mistake.
Change-Id: Id3f1879af479efc567ea0508a1de7a37db5bee89
Reviewed-on: https://go-review.googlesource.com/c/149961
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Go get in mod-enabled packages lets you do go get "pkg@<hash>" or "pkg@<branch>".
Go internally will switch the hash or branch into a pseudo version.
Go mod download should do the same. The bug lay in the fact that the disk cache
was not being written when Go converted the hash/branch into a pseudo version.
Fixes#27947
Change-Id: I94c29a5c95f69ab18a9cd7a2ecade128047c5e36
GitHub-Last-Rev: 668634b3e7
GitHub-Pull-Request: golang/go#28042
Reviewed-on: https://go-review.googlesource.com/c/140257
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This field, which matches the IDs used by go list, will enable all vet
drivers to produce JSON output in a consistent format (a map from
package ID to analysis name to result).
Change-Id: Icac703b944de55df42c996dc2f672005014ad57a
Reviewed-on: https://go-review.googlesource.com/c/149960
Reviewed-by: Russ Cox <rsc@golang.org>
The reason the 386 trybot was happy but 'GOARCH=386 go test cmd/vet'
was not is that CgoEnabled defaults to false in a cross build;
I have no idea why. Now we ask the go command for the effective
value so that the test works in both cases.
Also, remove stale comment.
Fixes#28829
Change-Id: I1210af34da6986f47924059de5c1f08b2824ace9
Reviewed-on: https://go-review.googlesource.com/c/149958
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In general we don't assume that the go command knows the
specific version of the compiler being used, including which
experiments the compiler was built with. Let the compiler tell us,
instead of importing cmd/internal/objabi from cmd/go.
Replacement for CL 128735.
Change-Id: Iaa07f46e19764d0fb14a1c89979bea7bb7139b9c
Reviewed-on: https://go-review.googlesource.com/c/149338
Reviewed-by: Bryan C. Mills <bcmills@google.com>
A bug in the old code was indirectly causing a confusing print,
but CL 131635 fixed the print instead of the surrounding code.
Fix the surrounding code, restore the old print, and test that the
error is actually reported (it was being ignored in a direct go get
but displaying in go build).
Change-Id: I03c21380fce481060c443b0cc820f3617497fdd9
Reviewed-on: https://go-review.googlesource.com/c/149317
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The compiler's Format test verifies that the correct format
strings for the given arguments are used in the compiler
sources. The format strings are fairly specialized which is
why we cannot use go vet; and the mapping is based on a
hard-wired map.
In the past, if that map got out of sync with the compiler
sources, it was necessary to manually update the map. This
change introduces an update mechanism which simply requires
the test to be run with the -u flag.
(Formerly, the -u flag was used to automatically rewrite
format strings; now we use -r for that.)
Change-Id: I9259566a6120a13cf34b143875975ada62697890
Reviewed-on: https://go-review.googlesource.com/c/149460
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Select linux/arm64 for the asm test.
Disable the cgo test for now.
Will fix properly in a follow-up.
Filed Issue 28829 to track it.
Updates #28829
Change-Id: Ic05f619700b06e91c43f8c150b089b8e77d92c85
Reviewed-on: https://go-review.googlesource.com/c/149937
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 129682 removed go mod fix but unfortunately
we hadn't updated the source code hence running
go mod -fix
would suggest
go mod fix
which is a nonexistent command.
This change fixes that to instead suggest
go mod tidy
Change-Id: Ie0d7c90805034e9fe6df24afaa15340c44d4f426
GitHub-Last-Rev: 5ae1340954
GitHub-Pull-Request: golang/go#28402
Reviewed-on: https://go-review.googlesource.com/c/144838
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change deletes the legacy implementation of vet, replacing it
with a short main.go that merely selects the desired analyzers and
calls into the "unitchecker" implementation vendored from
golang.org/x/tools/go/analysis.
Unlike the full vet checker (x/tools/go/analysis/cmd/vet), the 'lite'
unitchecker cannot also be run standalone (as 'go tool vet' or
cmd/vet); it must be invoked by 'go vet'.
This design was chosen to avoid vendoring many
additional dependencies into GOROOT, in particular go/packages. If
go/packages should someday become part of the standard library, there
will be considerable opportunity for simplification.
This change also patches the vendored analysisflag package
(by adding patch.go) so that it fully supports the build
system's -V flag protocol.
Also:
- remove stale internal/unitchecker/ tree
(belonged in https://go-review.googlesource.com/c/149778).
- move vet legacy flags (-all, -v, -source, -tags) into analysisflags
as all drivers will need them, not just unitchecker.
I will upstream this change.
A sampling of tests from the cmd/vet testsuite have been preserved as
a smoke test, to ensure that each analyzer is being run, and for
convenience when evaluating changes. Comprehensive tests for each
analyzer live upstream in x/tools. The tests have been heavily reduced
and reorganized so that they conform to the structure required by 'go
vet'.
Change-Id: I84b38caeef733e65deb95234b3b87b5f61046def
Reviewed-on: https://go-review.googlesource.com/c/149609
Reviewed-by: Russ Cox <rsc@golang.org>
cmd/vet/all applies vet to all packages in the standard tree.
It is run for every configuration using this command:
GO_BUILDER_NAME=misc-vetall go tool dist test
by the misc-vetall builder (see chart at build.golang.org).
Ideally we would switch to 'go vet', but it effectively does a partial
build. This means that its analysis has accurate type information, so
it reports slightly fewer spurious diagnostics. However, it is more
than twice as slow.
Instead, cmd/vet/all builds and runs
golang.org/x/tools/go/analysis/cmd/vet, which uses x/tools/go/packages
to load the entire std lib from source. It takes about 4min to run all
OS/ARCH pairs. An important consequence is that golang.org/x/tools
must be on your $GOPATH to run cmd/vet/all. The test has been
temporarily modified to warn and skip if this is not the case.
This is a preparatory step for switching to the new
cmd/vet based on vet-lite.
Whitelist changes:
- The two "deadcode" diagnostics removed from the whitelist were due
to if-conditions that could now be proven false.
- The asmdecl warnings are now printed with the log.Printf prefix,
so they are discarded by the parser and needn't be whitelisted.
Change-Id: I6486508b0de2cd947c897523af086a408cbaf4a8
Reviewed-on: https://go-review.googlesource.com/c/149097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When CL 147160 introduced function ABIs encoded as symbol versions in
the linker, it became slightly more complicated to look up derived
DWARF symbols. It fixed this by introducing a dwarfFuncSym function to
hide this logic, but missed one derived lookup that was done in the
object reader itself. As a result, we lost the isStmt tables from the
compiler, so every PC was marked as a statement in the DWARF info.
Fix this by moving this derived lookup out of the object reader and
into the DWARF code and calling dwarfFuncSym to get the correctly
versioned symbol.
Should fix the linux-amd64-longtest builder.
Updates #27539.
Change-Id: If40d5ba28bab1918ac4ad18fbb5103666b6d978b
Reviewed-on: https://go-review.googlesource.com/c/149605
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
I've never seen a case where unsafe arithmetic is used to generate a nil.
(Something like var x uintptr; unsafe.Pointer(x - x).)
We can assume that if someone is doing arithmetic with pointers, the
result will be non-nil. Our unsafe rules already forbid this, although
we should be more explicit.
RELNOTE=It is invalid to convert a nil unsafe.Pointer to uintptr and back, with arithmetic.
(This was already invalid, but this statement has been added for clarification.)
Fixes#27180
Change-Id: I1880b7725a9fd99e4613799930fdad9aaa99e8f0
Reviewed-on: https://go-review.googlesource.com/c/146058
Reviewed-by: Austin Clements <austin@google.com>
This allows one to customize which ar to use by fetching its path
from the environment. This way one can swap it out for a
different implementation.
Change-Id: I40d8cbd8a69e97b5254e66081d9bf0b726c10366
GitHub-Last-Rev: 4aa1d631ea
GitHub-Pull-Request: golang/go#28746
Reviewed-on: https://go-review.googlesource.com/c/149117
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current support_XXX variables are specific for the
amd64 and 386 platforms.
Prefix processor capability variables by architecture to have a
consistent naming scheme and avoid reuse of the existing
variables for new platforms.
This also aligns naming of runtime variables closer with internal/cpu
processor capability variable names.
Change-Id: I3eabb29a03874678851376185d3a62e73c1aff1d
Reviewed-on: https://go-review.googlesource.com/c/91435
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Given a nonexistent directory above a wildcard:
go run ./nonexistent/...
Print this error instead of panicking:
go run: no packages loaded from ./nonexistent/...
Fixes#28696.
Change-Id: Iaa3bc5c78b14ef858d931778e1bc55ca626c5571
GitHub-Last-Rev: bb1a80483a
GitHub-Pull-Request: golang/go#28703
Reviewed-on: https://go-review.googlesource.com/c/148821
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
When using soft-float, OMUL might be rewritten to function call
so we should ensure it was evaluated first.
Fixes#28688
Change-Id: I30b87501782fff62d35151f394a1c22b0d490c6c
Reviewed-on: https://go-review.googlesource.com/c/148837
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add GOOS=linux to vet_asm script to avoid errors on OS not working on
amd64 architecture.
Change-Id: Ic3db43618008ae8e8bc08738c95c200dd4e916d7
Reviewed-on: https://go-review.googlesource.com/c/149577
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The bootstrap stage 1 compiler was defaulting to the language version
used by the bootstrap compiler itself, typically 1.4. Normally this
doesn't matter since the bootstrap code has to build with 1.4 anyhow,
but it broke the boringcrypto branch which uses cgo during the
bootstrap, as cgo now generates code that uses type aliases.
Change-Id: I8a8312bb9ca4befaf65c00a8d71a78566075c2f7
Reviewed-on: https://go-review.googlesource.com/c/149459
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Now that vet can rely on go/types, there's no reason to do extra work to
avoid using it. The rewrite lets us get rid of the field list flattening
code, as well as the slight verbosity that comes with go/printer.
While at it, make the testdata/method.go expected errors be more
specific, to make sure that we're not breaking the warnings that are
printed.
Finally, update whitelist/all.txt, since the reported errors now include
qualified types.
Change-Id: I760a1b3b1f60e4a478c9dc43bd7f584a8459593e
Reviewed-on: https://go-review.googlesource.com/c/148919
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Alan Donovan <adonovan@google.com>
When module is enabled, the go tool embeds build information
related to the module in the binary including the dependencies
and the replace information (See
src/cmd/go/internal/modload.PackageBuildInfo).
The newly introduced ReadBuildInfo reads the information and
makes it accessible programmatically.
Update #26404
Change-Id: Ide37022d609b4a8fb6b5ce02afabb73f04fbb532
Reviewed-on: https://go-review.googlesource.com/c/144220
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Changes include:
1. enable compiler option -race for arm64
2. add runtime/race_arm64.s to manage the calls from Go to the compiler-rt runtime
3. change racewalk.go to call racefuncenterfp instead of racefuncenter on arm64 to
allow the caller pc to be obtained in the asm code before calling the tsan version
4. race_linux_arm64.syso comes from compiler-rt which just supports 48bit VA, compiler-rt
is fetched from master branch which latest commit is 3aa2b775d08f903f804246af10b
Fixes#25682
Change-Id: I04364c580b8157fd117deecae74a4656ba16e005
Reviewed-on: https://go-review.googlesource.com/c/138675
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The "gofiles" cache entry has been renamed "srcfiles", and it includes
non-Go files (.s, .c, .cxx) that belong to the package. It does not
include raw cgo files.
Added regression test.
Fixes#27665
Change-Id: I4884fe9b4f823f50705f8c2d357a04a8e567734f
Reviewed-on: https://go-review.googlesource.com/c/148904
Reviewed-by: Bryan C. Mills <bcmills@google.com>
I see no reason Plan 9 should be special cased.
A directory named go.mod is not useful on any system.
Followup to CL 129804.
Change-Id: I9cc91b5934b17650bfdb07370aa73aeae445968c
Reviewed-on: https://go-review.googlesource.com/c/149337
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The code to implement new-style gccgo name mangling had a recipe that
didn't quite match that of the compiler (incorrect handling for '.').
This showed up as a failure in the gotools cgo test if the directory
containing the test run included a "." character.
[This is a copy of https://golang.org/cl/147917].
Change-Id: Ia94728ecead879c8d223eb6cee6c102a8af1c86e
Reviewed-on: https://go-review.googlesource.com/c/147937
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This reverts CL 144137.
Reason for revert: The justification for the original commit
was that golint said so, but golint is wrong. The code reads
more clearly the original way.
Change-Id: I960f286ed66fec67aabd953e7b69993f60b00bca
Reviewed-on: https://go-review.googlesource.com/c/149339
Reviewed-by: Russ Cox <rsc@golang.org>
SSA lowering can create PFUNC ONAME nodes when compiling method calls.
Since we generally initialize the node's Sym to a func when we set its
class to PFUNC, we did this here, too. Unfortunately, since SSA
compilation is concurrent, this can cause a race if two function
compilations try to initialize the same symbol.
Luckily, we don't need to do this at all, since we're actually just
wrapping an ONAME node around an existing Sym that's already marked as
a function symbol.
Fixes the linux-amd64-racecompile builder, which was broken by CL
147158.
Updates #27539.
Change-Id: I8ddfce6e66a08ce53998c5bfa6f5a423c1ffc1eb
Reviewed-on: https://go-review.googlesource.com/c/149158
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
We create the "init" symbol and mark it as a function before compiling
to SSA because SSA can initialize this symbol, but it turns out we do
it slightly too late. peekitabs, at least, can also create the "init"
LSym. Move this initialization to just after type-checking.
Fixes the linux-amd64-ssacheck and the android-arm64-wiko-fever
builders.
Updates #27539.
Change-Id: If145952c79d39f75c93b24e35e67fe026dd08329
Reviewed-on: https://go-review.googlesource.com/c/149137
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This fixes the linux-amd64-longtest builder, which was broken by CL
147160.
Updates #27539.
Change-Id: If6e69581ef503bba2449ec9bacaa31f34f59beb1
Reviewed-on: https://go-review.googlesource.com/c/149157
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This implements compiler and linker support for separating the
function calling ABI into two ABIs: a stable and an internal ABI. At
the moment, the two ABIs are identical, but we'll be able to evolve
the internal ABI without breaking existing assembly code that depends
on the stable ABI for calling to and from Go.
The Go compiler generates internal ABI symbols for all Go functions.
It uses the symabis information produced by the assembler to create
ABI wrappers whenever it encounters a body-less Go function that's
defined in assembly or a Go function that's referenced from assembly.
Since the two ABIs are currently identical, for the moment this is
implemented using "ABI alias" symbols, which are just forwarding
references to the native ABI symbol for a function. This way there's
no actual code involved in the ABI wrapper, which is good because
we're not deriving any benefit from it right now. Once the ABIs
diverge, we can eliminate ABI aliases.
The linker represents these different ABIs internally as different
versions of the same symbol. This way, the linker keeps us honest,
since every symbol definition and reference also specifies its
version. The linker is responsible for resolving ABI aliases.
Fixes#27539.
Change-Id: I197c52ec9f8fc435db8f7a4259029b20f6d65e95
Reviewed-on: https://go-review.googlesource.com/c/147160
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently, if a symbol is only defined under one ABI and referenced
under another ABI, you simply get a "relocation target X not defined".
This is confusing because it seems like the symbol is defined.
This CL enhances the error message in this case to be "relocation
target X not defined for <ABI> (but is defined for <ABI>)".
For #27539.
Change-Id: If857a1882c3fe9af5346797d5295ca1fe50ae565
Reviewed-on: https://go-review.googlesource.com/c/147159
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
In order to mark the obj.LSyms produced by the compiler with the
correct ABI, we need to know which types.Syms refer to function
symbols. This CL adds a flag to types.Syms to mark symbols for
functions, and sets this flag everywhere we create a PFUNC-class node,
and in the one place where we directly create function symbols without
always wrapping them in a PFUNC node (methodSym).
We'll use this information to construct obj.LSyms with correct ABI
information.
For #27539.
Change-Id: Ie3ac8bf3da013e449e78f6ca85546a055f275463
Reviewed-on: https://go-review.googlesource.com/c/147158
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This repurposes the "version" field of a symbol reference in the Go
object file format to be an ABI field. Currently, this is just 0 or 1
depending on whether the symbol is static (the linker turns it into a
different internal version number), so it's already only tenuously a
symbol version. We change this to be -1 for static symbols and
otherwise by the ABI number.
This also adds a separate list of ABI alias symbols to be recorded in
the object file. The ABI aliases must be a separate list and not just
part of the symbol definitions because it's possible to have a symbol
defined in one package and the alias "defined" in a different package.
For example, this can happen if a symbol is defined in assembly in one
package and stubbed in a different package. The stub triggers the
generation of the ABI alias, but in a different package from the
definition.
For #27539.
Change-Id: I015c9fe54690c027de6ef77e22b5585976a01587
Reviewed-on: https://go-review.googlesource.com/c/147157
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This extends cmd/go's symabis support to collect known cross-package
uses of runtime symbols from other "basically runtime" packages in
std. This avoids having to declare a large number of ABI0 symbols in
the runtime for a small number of known cross-package references.
For cmd/dist, we use a simpler but less efficient approach and tell
the compiler to generate ABI wrappers for everything.
Change-Id: Ifaed94efdcff42e7345ab11b4d2fb880fb1a24e8
Reviewed-on: https://go-review.googlesource.com/c/147257
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This doesn't yet do anything with this information.
For #27539.
Change-Id: Ia12c905812aa1ed425eedd6ab2f55ec75d81c0ce
Reviewed-on: https://go-review.googlesource.com/c/147099
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This adds a -symabis flag that runs the assembler in a special mode
that outputs symbol definition and reference ABIs rather than
assembling the code. This uses a fast and somewhat lax parser because
the go_asm.h definitions may not be available.
For #27539.
Change-Id: I248ba0ebab7cc75dcb2a90e82a82eb445da7e88e
Reviewed-on: https://go-review.googlesource.com/c/147098
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently cmd/asm's Parser.line both consumes a line of assembly from
the lexer and assembles it. This CL separates these two steps so that
the line parser can be reused for purposes other than generating a
Prog stream.
For #27539.
Updates #17544.
Change-Id: I452c9a2112fbcc1c94bf909efc0d1fcc71014812
Reviewed-on: https://go-review.googlesource.com/c/147097
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We're going to use the linker's symbol versions to track ABIs.
Currently, version 0 is used for global symbols and version > 0 is
used for file-local symbols. This CL reserves versions 0 to 9 for
global symbols with ABIs and uses version 10 and up for file-local
symbols. To make this clean, it also introduces a method on Symbol for
querying whether it's file-local.
For #27539.
Change-Id: Id3bc7369268f35128b14318a62e86335181a80e5
Reviewed-on: https://go-review.googlesource.com/c/146859
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The compiler passes a lot of DWARF metadata about functions to the
linker via symbols whose names are derived from the function's own
symbol name. We look up these symbols in several places. This is about
to get slightly more complex as we introduce ABIs as symbol versions,
so abstract this lookup pattern into a helper function.
For #27539.
Change-Id: Ic71f6b5dc6608a5a5f5f515808981e6d6f5d728e
Reviewed-on: https://go-review.googlesource.com/c/146858
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>