go/build and cmd/go will stop returing Targets for stdlib .a files, and
stop producing the .a files is pkg/GOOS_GOARCH. update tests to
anticipate that and to pass in importcfgs instead of expecting the
compiler can find .a files in their old locations.
Adds code to determine locations of .a files to internal/goroot. Also
adds internal/goroot to dist's bootstrap directories and changes
internal/goroot to build with a bootstrap version of Go.
Change-Id: Ie81e51105bddb3f0e374cbf47e81c23edfb67fa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/442303
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Separate out the functions from cmd/internal/sys/support.go and
migrate them to a new package internal/platform, so that functions such as
"RaceDetectorSupported" can be called from tests in std as well as in
cmd. This isn't a complete move of everything in cmd/internal/sys;
there are still many functions left.
The original version of this CL (patch set 1) called the new package
"internal/sys", but for packages that needed both "internal/sys" and
"cmd/internal/sys" the import of the former had to be done with a
different name, which was confusing and also required a hack in
cmd/dist.
Updates #56006.
Change-Id: I866d62e75adbf3a640a06e2c7386a6e9e2a18d91
Reviewed-on: https://go-review.googlesource.com/c/go/+/438475
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
For PIE binaries, the .gopclntab section doesn't have the usual
name, but .data.rel.ro.gopclntab. Try the relro version as well.
If both failed (e.g. for externally linked PIE binaries), try
runtime.pclntab symbol.
This should make cmd/objdump able to print the file/line
information for PIE binaries.
I attempted to do this a few years ago, but that wasn't enough,
because the pclntab itself contains dynamic relocations which are
not applied by the tool. As of Go 1.18 the pclntab is mostly
position independent and does not contain dynamic relocations, so
this should be possible now.
Fixes#17883.
Updates #46639.
Change-Id: I85dc3d50ffcc1a4b187a349479a6a162de1ab2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/227483
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Contributors to the loong64 port are:
Weining Lu <luweining@loongson.cn>
Lei Wang <wanglei@loongson.cn>
Lingqin Gong <gonglingqin@loongson.cn>
Xiaolin Zhao <zhaoxiaolin@loongson.cn>
Meidan Li <limeidan@loongson.cn>
Xiaojuan Zhai <zhaixiaojuan@loongson.cn>
Qiyuan Pu <puqiyuan@loongson.cn>
Guoqi Chen <chenguoqi@loongson.cn>
This port has been updated to Go 1.15.6:
https://github.com/loongson/go
Updates #46229
Change-Id: Ic96e4f0c46d9a6b8cd020e899f32c40681daf9c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/342323
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
When we add GOEXPERIMENT=boringcrypto, the bootstrap process
will not converge if the compiler itself depends on the boringcrypto
cgo-based implementations of sha1 and sha256.
Using notsha256 avoids boringcrypto and makes bootstrap converge.
Removing md5 is not strictly necessary but it seemed worthwhile to
be consistent.
For #51940.
Change-Id: Iba649507e0964d1a49a1d16e463dd23c4e348f14
Reviewed-on: https://go-review.googlesource.com/c/go/+/402595
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The -p flag specifies the import path of the package being compiled.
This CL makes it required when invoking the compiler and
adjusts tests that invoke the compiler directly to conform to this
new requirement. The go command already passes the flag, so it
is unmodified in this CL. It is expected that any other Go build systems
also already pass -p, or else they will need to arrange to do so before
updating to Go 1.19. Of particular note, Bazel already does for rules
with an importpath= attribute, which includes all Gazelle-generated rules.
There is more cleanup possible now in cmd/compile, cmd/link,
and other consumers of Go object files, but that is left to future CLs.
Additional historical background follows but can be ignored.
Long ago, before the go command, or modules, or any kind of
versioning, symbols in Go archive files were named using just the
package name, so that for example func F in math/rand and func F in
crypto/rand would both be the object file symbol 'rand.F'. This led to
collisions even in small source trees, which made certain packages
unusable in the presence of other packages and generally was a problem
for Go's goal of scaling to very large source trees.
Fixing this problem required changing from package names to import
paths in symbol names, which was mostly straightforward. One wrinkle,
though, is that the compiler did not know the import path of the
package being compiled; it only knew the package name. At the time,
there was no go command, just Makefiles that people had invoking 6g
(now “go tool compile”) and then copying the resulting object file to
an importable location. That is, everyone had a custom build setup for
Go, because there was no standard one. So it was not particularly
attractive to change how the compiler was invoked, since that would
break approximately every Go user at the time. Instead, we arranged
for the compiler to emit, and other tools reading object files to
recognize, a special import path (the empty string, it turned out)
denoting “the import path of this object file”. This worked well
enough at the time and maintained complete command-line compatibility
with existing Go usage.
The changes implementing this transition can be found by searching
the Git history for “package global name space”, which is what they
eliminated. In particular, CL 190076 (a6736fa4), CL 186263 (758f2bc5),
CL 193080 (1cecac81), CL 194053 (19126320), and CL 194071 (531e6b77)
did the bulk of this transformation in January 2010.
Later, in September 2011, we added the -p flag to the compiler for
diagnostic purposes. The problem was that it was easy to create import
cycles, especially in tests, and these could not be diagnosed until
link time. You'd really want the compiler to diagnose these, for
example if the compilation of package sort noticed it was importing a
package that itself imported "sort". But the compilation of package
sort didn't know its own import path, and so it could not tell whether
it had found itself as a transitive dependency. Adding the -p flag
solved this problem, and its use was optional, since the linker would
still diagnose the import cycle in builds that had not updated to
start passing -p. This was CL 4972057 (1e480cd1).
There was still no go command at this point, but when we introduced
the go command we made it pass -p, which it has for many years at this
point.
Over time, parts of the compiler began to depend on the presence of
the -p flag for various reasonable purposes. For example:
In CL 6497074 (041fc8bf; Oct 2012), the race detector used -p to
detect packages that should not have race annotations, such as
runtime/race and sync/atomic.
In CL 13367052 (7276c02b; Sep 2013), a bug fix used -p to detect the
compilation of package reflect.
In CL 30539 (8aadcc55; Oct 2016), the compiler started using -p to
identify package math, to be able to intrinsify calls to Sqrt inside
that package.
In CL 61019 (9daee931; Sep 2017), CL 71430 (2c1d2e06; Oct 2017), and
later related CLs, the compiler started using the -p value when
creating various DWARF debugging information.
In CL 174657 (cc5eaf93; May 2019), the compiler started writing
symbols without the magic empty string whenever -p was used, to reduce
the amount of work required in the linker.
In CL 179861 (dde7c770; Jun 2019), the compiler made the second
argument to //go:linkname optional when -p is used, because in that
case the compiler can derive an appropriate default.
There are more examples. Today it is impossible to compile the Go
standard library without using -p, and DWARF debug information is
incomplete without using -p.
All known Go build systems pass -p. In particular, the go command
does, which is what nearly all Go developers invoke to build Go code.
And Bazel does, for go_library rules that set the importpath
attribute, which is all rules generated by Gazelle.
Gccgo has an equivalent of -p and has required its use in order to
disambiguate packages with the same name but different import paths
since 2010.
On top of all this, various parts of code generation for generics
are made more complicated by needing to cope with the case where -p
is not specified, even though it's essentially always specified.
In summary, the current state is:
- Use of the -p flag with cmd/compile is required for building
the standard library, and for complete DWARF information,
and to enable certain linker speedups.
- The go command and Bazel, which we expect account for just
about 100% of Go builds, both invoke cmd/compile with -p.
- The code in cmd/compile to support builds without -p is
complex and has become more complex with generics, but it is
almost always dead code and therefore not worth maintaining.
- Gccgo already requires its equivalent of -p in any build
where two packages have the same name.
All this supports the change in this CL, which makes -p required
and adjusts tests that invoke cmd/compile to add -p appropriately.
Future CLs will be able to remove all the code dealing with the
possibility of -p not having been specified.
Change-Id: I6b95b9d4cffe59c7bac82eb273ef6c4a67bb0e43
Reviewed-on: https://go-review.googlesource.com/c/go/+/391014
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The Go object file format can change from version to version.
Tools like cmd/objdump and cmd/nm only onderstand the current
version of the object file. Currently, when it encounters an
object built with a different version of the toolchain, it emits
a generic error "unrecognized object file", which is not very
helpful for users. This CL makes it emit a clearer error. Now it
emits
objdump: open go116.o: go object of a different version: go116ld
Change-Id: I063c6078ed1da78f97cea65796779ae093a1a8cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/315609
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>
With register ABI, the disassembly of the function may not
contain a "movq" instruction (which used to be e.g. storing
arguments to stack). Look for "jmp" instruction instead. This is
also in consistent with the test for Go assembly syntax.
Change-Id: Ifc9e48bbc4f85c4e4aace5981b3a0f8ae925f6d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/308652
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For some reason (that I didn't look into), externally linked
AIX binaries don't have runtime.symtab symbol. Since recent Go
releases (Go 1.3 maybe?), that symbol is empty and not necessary
anyway. Don't require it.
Fixes#40972.
Change-Id: I73a1f0142195ea6debdba8a4f6e12cadc3980dc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/279995
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Apparently I never actually understood the new file table in Go
object files. The PC value stream actually encodes the file index
in the per-CU table. I thought it was indexing into a per-function
table, which then contains index to the per-CU table. Remove the
extra indirection.
Change-Id: I0aea5629f7b3888ebe3a04fea437aa15ce89519e
Reviewed-on: https://go-review.googlesource.com/c/go/+/262779
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>
Current peFile.goarch looks for symbols like "_rt0_386_windows" to
determine GOARCH. But "_rt0_386_windows" is not present in executables
built with cgo.
Use pe.FileHeader.Machine instead. This should work with any Windows
executable, not just with Go built executable.
Fixes#39682
Change-Id: Ie0ffce664f4b8b8fed69b2ecc482425b042a38d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/240957
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Also do not unset it by default in the tests for cmd/go.
GOROOT_FINAL affects the GOROOT value embedded in binaries,
such as 'cmd/cgo'. If its value changes and a build command
is performed that depends on one of those binaries, the binary
would be spuriously rebuilt.
Instead, only unset it in the specific tests that make assumptions
about the GOROOT paths embedded in specific compiled binaries.
That may cause those tests to do a little extra rebuilding when
GOROOT_FINAL is set, but that little bit of extra rebuilding
seems preferable to spuriously-stale binaries.
Fixes#39385
Change-Id: I7c87b1519bb5bcff64babf1505fd1033ffa4f4fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/236819
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This reverts CL 229246.
For new indexed object files, in CL 229246 we added symbol index
to tools (nm, objdump) output. This affects external tools that
parse those outputs. And the added index doesn't look very nice.
In this release we take it out. For future releases we may
introduce a flag to tools (nm, objdump) and optionally dump the
symbol index.
For refererenced (not defined) indexed symbols, currently the
symbol is still referenced only by index, not by name. The next
CL will make the object file self-contained, so tools can dump
the symbol names properly (as before).
For #38875.
Change-Id: I07375e85a8e826e15c82fa452d11f0eaf8535a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/236167
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
With old object files, when objdump an object file which, for
example, contains a call of fmt.Fprintf, it shows a symbol
reference like
R_CALL:fmt.Fprintf
With new object files, as the symbol reference is indexed, the
reference becomes
R_CALL:fmt.#33
The object file does not contain information of what symbol #33
in the fmt package is.
To make this more useful, print the index when dumping the symbol
definitions. This way, when dumping the fmt package, e.g.
"go tool nm fmt.a", it will print
6c705 T fmt.Fprintf#33
So we can find out what symbol #33 actually is.
Change-Id: I320776597d28615ce18dd0617c352d2b8180db49
Reviewed-on: https://go-review.googlesource.com/c/go/+/229246
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We support disassembly on both ARM and ARM64. Tests are only
enabled on one or the other. This CL enables both.
Change-Id: If89d78b975c241c2b14f72b714dcdc771b4b382c
Reviewed-on: https://go-review.googlesource.com/c/go/+/226459
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This adds support for the -gnu option on Go objdump. When
this option is used, then output will include gnu
assembly in comments alongside the Go assembly.
The objdump test was updated to test this new option.
This option is supported for the arches found in
golang.org/x that provide the GNUsyntax function.
Updates #34372
Change-Id: I9e60e1691526607dda3c857c4564dcef408b8391
Reviewed-on: https://go-review.googlesource.com/c/go/+/225459
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
//line bogo.go:9999999 will cause 'go tool objdump' to crash
unless bogo.go has that many lines. Guard the array index
and return innocuous values (nil, nil) from the file cache.
Fixes#36683
Change-Id: I4a9f8444dc611654d270cc876e8848dfd2f84770
Reviewed-on: https://go-review.googlesource.com/c/go/+/223081
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The previous value was "too bogus" and caused objdump to crash.
Updated infinite loop test results (only run if -args -f) in ssa/debug_test.go
Probably also fixes#36621 but that bug needs more info to tell for certain.
Fixes#36570
Change-Id: I51144641d25d559308a98d726d87806bd340cc5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/215297
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Issue #12559 was closed and split into #19158 for mips{,le} and #19156
for mips64{,le}. Instead of referencing the individual GOARCH-specific
issues in the skip test messages of TestDisasmCode use the tracking bug
Change-Id: I6929d25f4ec5aef4f069b7692c4e29106088ce65
Reviewed-on: https://go-review.googlesource.com/c/go/+/209817
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts CL 184457.
Reason for revert: introduced failures in the regression test for #18153.
Fixes#34791
Updates #29062
Change-Id: I4040965163f809083c023be055e69b1149d6214e
Reviewed-on: https://go-review.googlesource.com/c/go/+/200106
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
For example, if a test calls os.Exit(0), that could trick a 'go test'
run into not running some of the other tests, and thinking that they all
succeeded. This can easily go unnoticed and cause developers headaches.
Add a simple sanity check as part of 'go test': if the test binary
succeeds and doesn't print anything, we should error, as something
clearly went very wrong.
This is done by inspecting each of the stdout writes from the spawned
process, since we don't want to read the entirety of the output into a
buffer. We need to introduce a "buffered" bool var, as there's now an
io.Writer layer between cmd.Stdout and &buf.
A few TestMain funcs in the standard library needed fixing, as they
returned without printing anything as a means to skip testing the entire
package. For that purpose add testenv.MainMust, which prints a warning
and prints SKIP, similar to when -run matches no tests.
Finally, add tests for both os.Exit(0) and os.Exit(1), both as part of
TestMain and as part of a single test, and test that the various stdout
modes still do the right thing.
Fixes#29062.
Change-Id: Ic6f8ef3387dfc64e4cd3e8f903d7ca5f5f38d397
Reviewed-on: https://go-review.googlesource.com/c/go/+/184457
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Speeds up
go test -short -count=1 cmd/objdump
on my machine from 1.7s to 1.3s.
Not much, but as the backpacking saying goes,
take care of the ounces and the pounds will take care of themselves.
Updates #26473
Change-Id: I59fe9a179e48537c7d82cbba72cde9f92b42a029
Reviewed-on: https://go-review.googlesource.com/c/go/+/176901
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Go on openbsd/arm has supported external linking for a while now, so
re-enable the external linking related tests that were previously
disabled.
Fixes#10619
Change-Id: I304eeabf3b462d53b7feda17ae390bbe2fa22069
Reviewed-on: https://go-review.googlesource.com/c/go/+/173597
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It turns out not to be necessary. Russ expressed a preference for
avoiding module fetches over making 'go mod tidy' work within std and
cmd right away, so for now we will make the loader use the vendor
directory for the standard library even if '-mod=vendor' is not set
explicitly.
Updates #30228
Change-Id: Idf7208e63da8cb7bfe281b93ec21b61d40334947
Reviewed-on: https://go-review.googlesource.com/c/go/+/166357
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Remove the os.Exit(0) to honor the deferred closing of the file.
Change-Id: Iaa9304d8203c8fec0ec728af669a94eadd36905c
Reviewed-on: https://go-review.googlesource.com/118915
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The counter part, writeInt in cmd/internal/obj, writes int64s.
So the reader side should also read int64s. This may cause a
larger range of values being accepted, some of which should
not be that large. This is probably ok: for example, for
size/index/length, the very large value (due to corruption)
may be well past the end and causes other errors. And we did
not do much bound check anyway.
One exmaple where this matters is ARM32's object file. For one
type of relocation it encodes the instruction into Reloc.Add
field (which itself may be problematic and worth fix) and the
instruction encoding overflows int32, causing ARM32 object
file being rejected by goobj (and so objdump and nm) before.
Unskip ARM32 object file tests in goobj, nm, and objdump.
Updates #19811.
Change-Id: Ia46c2b68df5f1c5204d6509ceab6416ad6372315
Reviewed-on: https://go-review.googlesource.com/69010
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Previous CL (cmd/internal/objabi: shrink SymType down to a uint8) shrinks
SymType down to a uint8 but forgot making according change in goobj.
Fixes#20296
Also add a test to catch such Goobj format inconsistency bug
Change-Id: Ib43dd7122cfcacf611a643814e95f8c5a924941f
Reviewed-on: https://go-review.googlesource.com/42971
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The last mention of those types in this package are in:
commit 6bd0d0542e
Author: Russ Cox <rsc@golang.org>
Date: Thu Nov 6 19:56:55 2014 -0500
cmd/objdump, cmd/pprof: factor disassembly into cmd/internal/objfile
Found with honnef.co/go/tools/cmd/unused.
Change-Id: Iacc2902f7d0784ac0efdd92da239f3e97491469a
Reviewed-on: https://go-review.googlesource.com/41472
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Updates #12559.
Change-Id: I5e8f4cf7071d0d71618527a6b6096e771d5eeb28
Reviewed-on: https://go-review.googlesource.com/34317
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
These don't use any flags in TestMain itself, so the call is redundant
as M.Run will do it.
Change-Id: I00f2ac7f846dc2c3ad3535eb8177616b2d900149
Reviewed-on: https://go-review.googlesource.com/33275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Rebuild cmd/objdump once instead of twice.
Speeds up standalone 'go test cmd/objdump' on my
machine from ~1.4s to ~1s.
Updates #17751
Change-Id: I15fd79cf18c310f892bc28a9e9ca47ee010c989a
Reviewed-on: https://go-review.googlesource.com/32673
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Update the ppc64x disassembly code for use by objdump
from golang.org/x/arch/ppc64/ppc64asm commit fcea5ea.
Enable the objdump testcase for external linking on ppc64le
make a minor fix to the expected output.
Fixes#17447
Change-Id: I769cc7f8bfade594690a476dfe77ab33677ac03b
Reviewed-on: https://go-review.googlesource.com/32015
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change makes sure that tests are run with the correct
version of the go tool. The correct version is the one that
we invoked with "go test", not the one that is first in our path.
Fixes#16577
Change-Id: If22c8f8c3ec9e7c35d094362873819f2fbb8559b
Reviewed-on: https://go-review.googlesource.com/28089
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Michael Matloob
Than McIntosh
Cherry Mui
John Bampton
Xiaodong Liu
Russ Cox
Josh Bleecher Snyder
Alex Brainman
Bryan C. Mills
Lynn Boger
David Chase
Joel Sing
Tobias Klauser
Daniel Martí
Muhammad Falak R Wani
Hiroshi Ioka
Alberto Donizetti
Wei Xiao
Damien Lespiau
Lorenzo Masini
David Lazar
Vladimir Stefanovic
Shenghou Ma
Keith Randall