2020-09-10 11:07:48 -04:00
// Copyright 2016 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
2016-04-06 07:11:24 -04:00
package main
2017-11-21 11:27:20 -08:00
import (
2019-10-10 12:11:06 -04:00
"bufio"
"bytes"
cmd/link: report error if builtin referenced but not defined
When the compiler refers to a runtime builtin, it emits an indexed
symbol reference in the object file via predetermined/preassigned ID
within the PkgIdxBuiltin pseudo-package. At link time when the loader
encounters these references, it redirects them to the corresponding
defined symbol in the runtime package. This redirection process
currently assumes that if a runtime builtin is referenced, we'll
always have a definition for it. This assumption holds in most cases,
however for the builtins "runtime.racefuncenter" and
"runtime.racefuncexit", we'll only see definitions if the runtime
package we're linking against was built with "-race".
In the bug in question, build passes "-gcflags=-race" during
compilation of the main package, but doesn't pass "-race" directly to
'go build', and as a result the final link combines a
race-instrumented main with a non-race runtime; this results in R_CALL
relocations with zero-valued target symbols, resulting in a panic
during stack checking.
This patch changes the loader's resolve method to detect situations
where we're asking for builtin "runtime.X", but the runtime package
read in doesn't contain a definition for X.
Fixes #42396.
Change-Id: Iafd38bd3b0f7f462868d120ccd4d7d1b88b27436
Reviewed-on: https://go-review.googlesource.com/c/go/+/267881
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
2020-11-05 14:19:47 -05:00
"cmd/internal/sys"
2019-05-08 09:36:07 +02:00
"debug/macho"
2017-11-21 11:27:20 -08:00
"internal/testenv"
"io/ioutil"
"os"
"os/exec"
"path/filepath"
cmd/link: fix confusing error on unresolved symbol
Currently, if an assembly file includes a static reference to an
undefined symbol, and another package also has an undefined reference
to that symbol, the linker can report an error like:
x: relocation target zero not defined for ABI0 (but is defined for ABI0)
Since the symbol is referenced in another package, the code in
ErrorUnresolved that looks for alternative ABI symbols finds that
symbol in the symbol table, but doesn't check that it's actually
defined, which is where the "but is defined for ABI0" comes from. The
"not defined for ABI0" is because ErrorUnresolved failed to turn the
static symbol's version back into an ABI, and it happened to print the
zero value for an ABI.
This CL fixes both of these problems. It explicitly maps the
relocation version back to an ABI and detects if it can't be mapped
back (e.g., because it's a static reference). Then, if it finds a
symbol with a different ABI in the symbol table, it checks to make
sure it's a definition, and not simply an unresolved reference.
Fixes #29852.
Change-Id: Ice45cc41c1907919ce5750f74588e8047eaa888c
Reviewed-on: https://go-review.googlesource.com/c/159518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-01-27 21:03:32 -05:00
"regexp"
2019-03-21 13:42:53 +01:00
"runtime"
2018-10-31 13:18:17 -04:00
"strings"
2017-11-21 11:27:20 -08:00
"testing"
)
2016-04-06 07:11:24 -04:00
var AuthorPaidByTheColumnInch struct {
2019-05-08 18:55:33 -04:00
fog int ` text:"London. Michaelmas term lately over, and the Lord Chancellor sitting in Lincoln’ s Inn Hall. Implacable November weather. As much mud in the streets as if the waters had but newly retired from the face of the earth, and it would not be wonderful to meet a Megalosaurus, forty feet long or so, waddling like an elephantine lizard up Holborn Hill. Smoke lowering down from chimney-pots, making a soft black drizzle, with flakes of soot in it as big as full-grown snowflakes—gone into mourning, one might imagine, for the death of the sun. Dogs, undistinguishable in mire. Horses, scarcely better; splashed to their very blinkers. Foot passengers, jostling one another’ s umbrellas in a general infection of ill temper, and losing their foot-hold at street-corners, where tens of thousands of other foot passengers have been slipping and sliding since the day broke (if this day ever broke), adding new deposits to the crust upon crust of mud, sticking at those points tenaciously to the pavement, and accumulating at compound interest. Fog everywhere. Fog up the river, where it flows among green aits and meadows; fog down the river, where it rolls defiled among the tiers of shipping and the waterside pollutions of a great (and dirty) city. Fog on the Essex marshes, fog on the Kentish heights. Fog creeping into the cabooses of collier-brigs; fog lying out on the yards and hovering in the rigging of great ships; fog drooping on the gunwales of barges and small boats. Fog in the eyes and throats of ancient Greenwich pensioners, wheezing by the firesides of their wards; fog in the stem and bowl of the afternoon pipe of the wrathful skipper, down in his close cabin; fog cruelly pinching the toes and fingers of his shivering little ‘ prentice boy on deck. Chance people on the bridges peeping over the parapets into a nether sky of fog, with fog all round them, as if they were up in a balloon and hanging in the misty clouds. Gas looming through the fog in divers places in the streets, much as the sun may, from the spongey fields, be seen to loom by husbandman and ploughboy. Most of the shops lighted two hours before their time—as the gas seems to know, for it has a haggard and unwilling look. The raw afternoon is rawest, and the dense fog is densest, and the muddy streets are muddiest near that leaden-headed old obstruction, appropriate ornament for the threshold of a leaden-headed old corporation, Temple Bar. And hard by Temple Bar, in Lincoln’ s Inn Hall, at the very heart of the fog, sits the Lord High Chancellor in his High Court of Chancery." `
2016-04-06 07:11:24 -04:00
2019-05-08 18:55:33 -04:00
wind int ` text:"It was grand to see how the wind awoke, and bent the trees, and drove the rain before it like a cloud of smoke; and to hear the solemn thunder, and to see the lightning; and while thinking with awe of the tremendous powers by which our little lives are encompassed, to consider how beneficent they are, and how upon the smallest flower and leaf there was already a freshness poured from all this seeming rage, which seemed to make creation new again." `
2016-04-06 07:11:24 -04:00
2019-05-08 18:55:33 -04:00
jarndyce int ` text:"Jarndyce and Jarndyce drones on. This scarecrow of a suit has, over the course of time, become so complicated, that no man alive knows what it means. The parties to it understand it least; but it has been observed that no two Chancery lawyers can talk about it for five minutes, without coming to a total disagreement as to all the premises. Innumerable children have been born into the cause; innumerable young people have married into it; innumerable old people have died out of it. Scores of persons have deliriously found themselves made parties in Jarndyce and Jarndyce, without knowing how or why; whole families have inherited legendary hatreds with the suit. The little plaintiff or defendant, who was promised a new rocking-horse when Jarndyce and Jarndyce should be settled, has grown up, possessed himself of a real horse, and trotted away into the other world. Fair wards of court have faded into mothers and grandmothers; a long procession of Chancellors has come in and gone out; the legion of bills in the suit have been transformed into mere bills of mortality; there are not three Jarndyces left upon the earth perhaps, since old Tom Jarndyce in despair blew his brains out at a coffee-house in Chancery Lane; but Jarndyce and Jarndyce still drags its dreary length before the Court, perennially hopeless." `
2016-04-06 07:11:24 -04:00
2019-05-08 18:55:33 -04:00
principle int ` text:"The one great principle of the English law is, to make business for itself. There is no other principle distinctly, certainly, and consistently maintained through all its narrow turnings. Viewed by this light it becomes a coherent scheme, and not the monstrous maze the laity are apt to think it. Let them but once clearly perceive that its grand principle is to make business for itself at their expense, and surely they will cease to grumble." `
2016-04-06 07:11:24 -04:00
}
func TestLargeSymName ( t * testing . T ) {
// The compiler generates a symbol name using the string form of the
// type. This tests that the linker can read symbol names larger than
// the bufio buffer. Issue #15104.
_ = AuthorPaidByTheColumnInch
}
2017-11-21 11:27:20 -08:00
func TestIssue21703 ( t * testing . T ) {
2018-12-07 15:00:49 -08:00
t . Parallel ( )
2017-11-21 11:27:20 -08:00
testenv . MustHaveGoBuild ( t )
const source = `
package main
const X = "\n!\n"
func main ( ) { }
`
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2017-11-21 11:27:20 -08:00
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( filepath . Join ( tmpdir , "main.go" ) , [ ] byte ( source ) , 0666 )
2017-11-21 11:27:20 -08:00
if err != nil {
t . Fatalf ( "failed to write main.go: %v\n" , err )
}
cmd/compile: require -p flag
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>
2022-03-08 18:16:35 -05:00
cmd := exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-p=main" , "main.go" )
2017-11-21 11:27:20 -08:00
cmd . Dir = tmpdir
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "failed to compile main.go: %v, output: %s\n" , err , out )
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "link" , "main.o" )
cmd . Dir = tmpdir
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "failed to link main.o: %v, output: %s\n" , err , out )
}
}
2018-10-31 13:18:17 -04:00
// TestIssue28429 ensures that the linker does not attempt to link
// sections not named *.o. Such sections may be used by a build system
// to, for example, save facts produced by a modular static analysis
// such as golang.org/x/tools/go/analysis.
func TestIssue28429 ( t * testing . T ) {
2018-12-07 15:00:49 -08:00
t . Parallel ( )
2018-10-31 13:18:17 -04:00
testenv . MustHaveGoBuild ( t )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2018-10-31 13:18:17 -04:00
write := func ( name , content string ) {
err := ioutil . WriteFile ( filepath . Join ( tmpdir , name ) , [ ] byte ( content ) , 0666 )
if err != nil {
t . Fatal ( err )
}
}
runGo := func ( args ... string ) {
cmd := exec . Command ( testenv . GoToolPath ( t ) , args ... )
cmd . Dir = tmpdir
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "'go %s' failed: %v, output: %s" ,
strings . Join ( args , " " ) , err , out )
}
}
// Compile a main package.
write ( "main.go" , "package main; func main() {}" )
cmd/compile: require -p flag
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>
2022-03-08 18:16:35 -05:00
runGo ( "tool" , "compile" , "-p=main" , "main.go" )
2018-10-31 13:18:17 -04:00
runGo ( "tool" , "pack" , "c" , "main.a" , "main.o" )
// Add an extra section with a short, non-.o name.
// This simulates an alternative build system.
write ( ".facts" , "this is not an object file" )
runGo ( "tool" , "pack" , "r" , "main.a" , ".facts" )
// Verify that the linker does not attempt
// to compile the extra section.
runGo ( "tool" , "link" , "main.a" )
}
cmd/link: fix confusing error on unresolved symbol
Currently, if an assembly file includes a static reference to an
undefined symbol, and another package also has an undefined reference
to that symbol, the linker can report an error like:
x: relocation target zero not defined for ABI0 (but is defined for ABI0)
Since the symbol is referenced in another package, the code in
ErrorUnresolved that looks for alternative ABI symbols finds that
symbol in the symbol table, but doesn't check that it's actually
defined, which is where the "but is defined for ABI0" comes from. The
"not defined for ABI0" is because ErrorUnresolved failed to turn the
static symbol's version back into an ABI, and it happened to print the
zero value for an ABI.
This CL fixes both of these problems. It explicitly maps the
relocation version back to an ABI and detects if it can't be mapped
back (e.g., because it's a static reference). Then, if it finds a
symbol with a different ABI in the symbol table, it checks to make
sure it's a definition, and not simply an unresolved reference.
Fixes #29852.
Change-Id: Ice45cc41c1907919ce5750f74588e8047eaa888c
Reviewed-on: https://go-review.googlesource.com/c/159518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-01-27 21:03:32 -05:00
func TestUnresolved ( t * testing . T ) {
testenv . MustHaveGoBuild ( t )
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
cmd/link: fix confusing error on unresolved symbol
Currently, if an assembly file includes a static reference to an
undefined symbol, and another package also has an undefined reference
to that symbol, the linker can report an error like:
x: relocation target zero not defined for ABI0 (but is defined for ABI0)
Since the symbol is referenced in another package, the code in
ErrorUnresolved that looks for alternative ABI symbols finds that
symbol in the symbol table, but doesn't check that it's actually
defined, which is where the "but is defined for ABI0" comes from. The
"not defined for ABI0" is because ErrorUnresolved failed to turn the
static symbol's version back into an ABI, and it happened to print the
zero value for an ABI.
This CL fixes both of these problems. It explicitly maps the
relocation version back to an ABI and detects if it can't be mapped
back (e.g., because it's a static reference). Then, if it finds a
symbol with a different ABI in the symbol table, it checks to make
sure it's a definition, and not simply an unresolved reference.
Fixes #29852.
Change-Id: Ice45cc41c1907919ce5750f74588e8047eaa888c
Reviewed-on: https://go-review.googlesource.com/c/159518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-01-27 21:03:32 -05:00
write := func ( name , content string ) {
err := ioutil . WriteFile ( filepath . Join ( tmpdir , name ) , [ ] byte ( content ) , 0666 )
if err != nil {
t . Fatal ( err )
}
}
// Test various undefined references. Because of issue #29852,
// this used to give confusing error messages because the
// linker would find an undefined reference to "zero" created
// by the runtime package.
2019-02-15 18:12:28 -05:00
write ( "go.mod" , "module testunresolved\n" )
cmd/link: fix confusing error on unresolved symbol
Currently, if an assembly file includes a static reference to an
undefined symbol, and another package also has an undefined reference
to that symbol, the linker can report an error like:
x: relocation target zero not defined for ABI0 (but is defined for ABI0)
Since the symbol is referenced in another package, the code in
ErrorUnresolved that looks for alternative ABI symbols finds that
symbol in the symbol table, but doesn't check that it's actually
defined, which is where the "but is defined for ABI0" comes from. The
"not defined for ABI0" is because ErrorUnresolved failed to turn the
static symbol's version back into an ABI, and it happened to print the
zero value for an ABI.
This CL fixes both of these problems. It explicitly maps the
relocation version back to an ABI and detects if it can't be mapped
back (e.g., because it's a static reference). Then, if it finds a
symbol with a different ABI in the symbol table, it checks to make
sure it's a definition, and not simply an unresolved reference.
Fixes #29852.
Change-Id: Ice45cc41c1907919ce5750f74588e8047eaa888c
Reviewed-on: https://go-review.googlesource.com/c/159518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-01-27 21:03:32 -05:00
write ( "main.go" , ` package main
func main ( ) {
x ( )
}
func x ( )
` )
write ( "main.s" , `
TEXT · x ( SB ) , 0 , $ 0
MOVD zero < > ( SB ) , AX
MOVD zero ( SB ) , AX
MOVD · zero ( SB ) , AX
RET
` )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" )
cmd . Dir = tmpdir
2019-03-12 14:43:22 -04:00
cmd . Env = append ( os . Environ ( ) ,
"GOARCH=amd64" , "GOOS=linux" , "GOPATH=" + filepath . Join ( tmpdir , "_gopath" ) )
cmd/link: fix confusing error on unresolved symbol
Currently, if an assembly file includes a static reference to an
undefined symbol, and another package also has an undefined reference
to that symbol, the linker can report an error like:
x: relocation target zero not defined for ABI0 (but is defined for ABI0)
Since the symbol is referenced in another package, the code in
ErrorUnresolved that looks for alternative ABI symbols finds that
symbol in the symbol table, but doesn't check that it's actually
defined, which is where the "but is defined for ABI0" comes from. The
"not defined for ABI0" is because ErrorUnresolved failed to turn the
static symbol's version back into an ABI, and it happened to print the
zero value for an ABI.
This CL fixes both of these problems. It explicitly maps the
relocation version back to an ABI and detects if it can't be mapped
back (e.g., because it's a static reference). Then, if it finds a
symbol with a different ABI in the symbol table, it checks to make
sure it's a definition, and not simply an unresolved reference.
Fixes #29852.
Change-Id: Ice45cc41c1907919ce5750f74588e8047eaa888c
Reviewed-on: https://go-review.googlesource.com/c/159518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-01-27 21:03:32 -05:00
out , err := cmd . CombinedOutput ( )
if err == nil {
t . Fatalf ( "expected build to fail, but it succeeded" )
}
out = regexp . MustCompile ( "(?m)^#.*\n" ) . ReplaceAll ( out , nil )
got := string ( out )
want := ` main . x : relocation target zero not defined
main . x : relocation target zero not defined
main . x : relocation target main . zero not defined
`
if want != got {
t . Fatalf ( "want:\n%sgot:\n%s" , want , got )
}
}
2019-03-21 13:42:53 +01:00
2020-02-26 02:48:24 +11:00
func TestIssue33979 ( t * testing . T ) {
testenv . MustHaveGoBuild ( t )
testenv . MustHaveCGO ( t )
2020-10-07 18:29:51 -04:00
testenv . MustInternalLink ( t )
2020-02-26 02:48:24 +11:00
// Skip test on platforms that do not support cgo internal linking.
switch runtime . GOARCH {
case "mips" , "mipsle" , "mips64" , "mips64le" :
t . Skipf ( "Skipping on %s/%s" , runtime . GOOS , runtime . GOARCH )
}
2021-04-20 15:43:17 -04:00
if runtime . GOOS == "aix" ||
runtime . GOOS == "windows" && runtime . GOARCH == "arm64" {
2020-02-26 02:48:24 +11:00
t . Skipf ( "Skipping on %s/%s" , runtime . GOOS , runtime . GOARCH )
}
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2020-02-26 02:48:24 +11:00
write := func ( name , content string ) {
err := ioutil . WriteFile ( filepath . Join ( tmpdir , name ) , [ ] byte ( content ) , 0666 )
if err != nil {
t . Fatal ( err )
}
}
run := func ( name string , args ... string ) string {
cmd := exec . Command ( name , args ... )
cmd . Dir = tmpdir
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "'go %s' failed: %v, output: %s" , strings . Join ( args , " " ) , err , out )
}
return string ( out )
}
runGo := func ( args ... string ) string {
return run ( testenv . GoToolPath ( t ) , args ... )
}
// Test object with undefined reference that was not generated
// by Go, resulting in an SXREF symbol being loaded during linking.
// Because of issue #33979, the SXREF symbol would be found during
// error reporting, resulting in confusing error messages.
write ( "main.go" , ` package main
func main ( ) {
x ( )
}
func x ( )
` )
// The following assembly must work on all architectures.
write ( "x.s" , `
TEXT · x ( SB ) , 0 , $ 0
CALL foo ( SB )
RET
` )
write ( "x.c" , `
void undefined ( ) ;
void foo ( ) {
undefined ( ) ;
}
` )
cc := strings . TrimSpace ( runGo ( "env" , "CC" ) )
cflags := strings . Fields ( runGo ( "env" , "GOGCCFLAGS" ) )
// Compile, assemble and pack the Go and C code.
2022-05-05 17:45:27 -04:00
runGo ( "tool" , "asm" , "-p=main" , "-gensymabis" , "-o" , "symabis" , "x.s" )
cmd/compile: require -p flag
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>
2022-03-08 18:16:35 -05:00
runGo ( "tool" , "compile" , "-symabis" , "symabis" , "-p=main" , "-o" , "x1.o" , "main.go" )
2022-05-05 17:45:27 -04:00
runGo ( "tool" , "asm" , "-p=main" , "-o" , "x2.o" , "x.s" )
2020-02-26 02:48:24 +11:00
run ( cc , append ( cflags , "-c" , "-o" , "x3.o" , "x.c" ) ... )
runGo ( "tool" , "pack" , "c" , "x.a" , "x1.o" , "x2.o" , "x3.o" )
// Now attempt to link using the internal linker.
cmd := exec . Command ( testenv . GoToolPath ( t ) , "tool" , "link" , "-linkmode=internal" , "x.a" )
cmd . Dir = tmpdir
out , err := cmd . CombinedOutput ( )
if err == nil {
t . Fatalf ( "expected link to fail, but it succeeded" )
}
re := regexp . MustCompile ( ` (?m)^main\(.*text\): relocation target undefined not defined$ ` )
if ! re . Match ( out ) {
t . Fatalf ( "got:\n%q\nwant:\n%s" , out , re )
}
}
2019-05-15 20:49:39 -04:00
func TestBuildForTvOS ( t * testing . T ) {
2019-03-21 13:42:53 +01:00
testenv . MustHaveCGO ( t )
testenv . MustHaveGoBuild ( t )
// Only run this on darwin/amd64, where we can cross build for tvOS.
if runtime . GOARCH != "amd64" || runtime . GOOS != "darwin" {
t . Skip ( "skipping on non-darwin/amd64 platform" )
}
2019-05-15 20:49:39 -04:00
if testing . Short ( ) && os . Getenv ( "GO_BUILDER_NAME" ) == "" {
t . Skip ( "skipping in -short mode with $GO_BUILDER_NAME empty" )
}
2019-03-21 13:42:53 +01:00
if err := exec . Command ( "xcrun" , "--help" ) . Run ( ) ; err != nil {
t . Skipf ( "error running xcrun, required for iOS cross build: %v" , err )
}
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2019-03-21 13:42:53 +01:00
sdkPath , err := exec . Command ( "xcrun" , "--sdk" , "appletvos" , "--show-sdk-path" ) . Output ( )
if err != nil {
t . Skip ( "failed to locate appletvos SDK, skipping" )
}
CC := [ ] string {
"clang" ,
"-arch" ,
"arm64" ,
"-isysroot" , strings . TrimSpace ( string ( sdkPath ) ) ,
"-mtvos-version-min=12.0" ,
"-fembed-bitcode" ,
}
cmd: support space and quotes in CC and CXX
The CC and CXX environment variables now support spaces and quotes
(both double and single). This fixes two issues: first, if CC is a
single path that contains spaces (like 'c:\Program
Files\gcc\bin\gcc.exe'), that should now work if the space is quoted
or escaped (#41400). Second, if CC or CXX has multiple arguments (like
'gcc -O2'), they are now split correctly, and the arguments are passed
before other arguments when invoking the C compiler. Previously,
strings.Fields was used to split arguments, and the arguments were
placed later in the command line. (#43078).
Fixes golang/go#41400
Fixes golang/go#43078
NOTE: This change also includes a fix (CL 341929) for a test that was
broken by the original CL. Commit message for the fix is below.
[dev.cmdgo] cmd/link: fix TestBuildForTvOS
This test was broken in CL 334732 on darwin.
The test invokes 'go build' with a CC containing the arguments
-framework CoreFoundation. Previously, the go command split CC on
whitespace, and inserted the arguments after the command line when
running CC directly. Those arguments weren't passed to cgo though,
so cgo ran CC without -framework CoreFoundation (or any of the other
flags).
In CL 334732, we pass CC through to cgo, and cgo splits arguments
using str.SplitQuotedFields. So -framework CoreFoundation actually
gets passed to the C compiler. It appears that -framework flags are
only meant to be used in linking operations, so when cgo invokes clang
with -E (run preprocessor only), clang emits an error that -framework
is unused.
This change fixes the test by moving -framework CoreFoundation out of
CC and into CGO_LDFLAGS.
Change-Id: I2d5d89ddb19c94adef65982a8137b01f037d5c11
Reviewed-on: https://go-review.googlesource.com/c/go/+/334732
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/341936
Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-07-14 16:57:24 -07:00
CGO_LDFLAGS := [ ] string { "-framework" , "CoreFoundation" }
2020-04-22 23:25:41 -04:00
lib := filepath . Join ( "testdata" , "testBuildFortvOS" , "lib.go" )
2021-03-07 20:52:39 -08:00
tmpDir := t . TempDir ( )
2019-03-21 13:42:53 +01:00
ar := filepath . Join ( tmpDir , "lib.a" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-buildmode=c-archive" , "-o" , ar , lib )
cmd . Env = append ( os . Environ ( ) ,
"CGO_ENABLED=1" ,
2020-10-16 20:25:54 -04:00
"GOOS=ios" ,
2019-03-21 13:42:53 +01:00
"GOARCH=arm64" ,
"CC=" + strings . Join ( CC , " " ) ,
2020-01-22 15:30:52 -05:00
"CGO_CFLAGS=" , // ensure CGO_CFLAGS does not contain any flags. Issue #35459
cmd: support space and quotes in CC and CXX
The CC and CXX environment variables now support spaces and quotes
(both double and single). This fixes two issues: first, if CC is a
single path that contains spaces (like 'c:\Program
Files\gcc\bin\gcc.exe'), that should now work if the space is quoted
or escaped (#41400). Second, if CC or CXX has multiple arguments (like
'gcc -O2'), they are now split correctly, and the arguments are passed
before other arguments when invoking the C compiler. Previously,
strings.Fields was used to split arguments, and the arguments were
placed later in the command line. (#43078).
Fixes golang/go#41400
Fixes golang/go#43078
NOTE: This change also includes a fix (CL 341929) for a test that was
broken by the original CL. Commit message for the fix is below.
[dev.cmdgo] cmd/link: fix TestBuildForTvOS
This test was broken in CL 334732 on darwin.
The test invokes 'go build' with a CC containing the arguments
-framework CoreFoundation. Previously, the go command split CC on
whitespace, and inserted the arguments after the command line when
running CC directly. Those arguments weren't passed to cgo though,
so cgo ran CC without -framework CoreFoundation (or any of the other
flags).
In CL 334732, we pass CC through to cgo, and cgo splits arguments
using str.SplitQuotedFields. So -framework CoreFoundation actually
gets passed to the C compiler. It appears that -framework flags are
only meant to be used in linking operations, so when cgo invokes clang
with -E (run preprocessor only), clang emits an error that -framework
is unused.
This change fixes the test by moving -framework CoreFoundation out of
CC and into CGO_LDFLAGS.
Change-Id: I2d5d89ddb19c94adef65982a8137b01f037d5c11
Reviewed-on: https://go-review.googlesource.com/c/go/+/334732
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/341936
Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-07-14 16:57:24 -07:00
"CGO_LDFLAGS=" + strings . Join ( CGO_LDFLAGS , " " ) ,
2019-03-21 13:42:53 +01:00
)
if out , err := cmd . CombinedOutput ( ) ; err != nil {
t . Fatalf ( "%v: %v:\n%s" , cmd . Args , err , out )
}
link := exec . Command ( CC [ 0 ] , CC [ 1 : ] ... )
cmd: support space and quotes in CC and CXX
The CC and CXX environment variables now support spaces and quotes
(both double and single). This fixes two issues: first, if CC is a
single path that contains spaces (like 'c:\Program
Files\gcc\bin\gcc.exe'), that should now work if the space is quoted
or escaped (#41400). Second, if CC or CXX has multiple arguments (like
'gcc -O2'), they are now split correctly, and the arguments are passed
before other arguments when invoking the C compiler. Previously,
strings.Fields was used to split arguments, and the arguments were
placed later in the command line. (#43078).
Fixes golang/go#41400
Fixes golang/go#43078
NOTE: This change also includes a fix (CL 341929) for a test that was
broken by the original CL. Commit message for the fix is below.
[dev.cmdgo] cmd/link: fix TestBuildForTvOS
This test was broken in CL 334732 on darwin.
The test invokes 'go build' with a CC containing the arguments
-framework CoreFoundation. Previously, the go command split CC on
whitespace, and inserted the arguments after the command line when
running CC directly. Those arguments weren't passed to cgo though,
so cgo ran CC without -framework CoreFoundation (or any of the other
flags).
In CL 334732, we pass CC through to cgo, and cgo splits arguments
using str.SplitQuotedFields. So -framework CoreFoundation actually
gets passed to the C compiler. It appears that -framework flags are
only meant to be used in linking operations, so when cgo invokes clang
with -E (run preprocessor only), clang emits an error that -framework
is unused.
This change fixes the test by moving -framework CoreFoundation out of
CC and into CGO_LDFLAGS.
Change-Id: I2d5d89ddb19c94adef65982a8137b01f037d5c11
Reviewed-on: https://go-review.googlesource.com/c/go/+/334732
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/341936
Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-07-14 16:57:24 -07:00
link . Args = append ( link . Args , CGO_LDFLAGS ... )
2021-01-15 13:19:31 -05:00
link . Args = append ( link . Args , "-o" , filepath . Join ( tmpDir , "a.out" ) ) // Avoid writing to package directory.
2020-04-22 23:25:41 -04:00
link . Args = append ( link . Args , ar , filepath . Join ( "testdata" , "testBuildFortvOS" , "main.m" ) )
2019-03-21 13:42:53 +01:00
if out , err := link . CombinedOutput ( ) ; err != nil {
t . Fatalf ( "%v: %v:\n%s" , link . Args , err , out )
}
}
2019-04-25 12:09:42 -04:00
var testXFlagSrc = `
package main
var X = "hello"
var Z = [ 99999 ] int { 99998 : 12345 } // make it large enough to be mmaped
func main ( ) { println ( X ) }
`
func TestXFlag ( t * testing . T ) {
testenv . MustHaveGoBuild ( t )
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2019-04-25 12:09:42 -04:00
src := filepath . Join ( tmpdir , "main.go" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( testXFlagSrc ) , 0666 )
2019-04-25 12:09:42 -04:00
if err != nil {
t . Fatal ( err )
}
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-ldflags=-X=main.X=meow" , "-o" , filepath . Join ( tmpdir , "main" ) , src )
if out , err := cmd . CombinedOutput ( ) ; err != nil {
t . Errorf ( "%v: %v:\n%s" , cmd . Args , err , out )
}
}
2019-05-08 09:36:07 +02:00
2021-04-21 19:12:38 -04:00
var testMachOBuildVersionSrc = `
2019-05-08 09:36:07 +02:00
package main
func main ( ) { }
`
2021-04-21 19:12:38 -04:00
func TestMachOBuildVersion ( t * testing . T ) {
2019-05-08 09:36:07 +02:00
testenv . MustHaveGoBuild ( t )
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2019-05-08 09:36:07 +02:00
src := filepath . Join ( tmpdir , "main.go" )
2021-04-21 19:12:38 -04:00
err := ioutil . WriteFile ( src , [ ] byte ( testMachOBuildVersionSrc ) , 0666 )
2019-05-08 09:36:07 +02:00
if err != nil {
t . Fatal ( err )
}
exe := filepath . Join ( tmpdir , "main" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-ldflags=-linkmode=internal" , "-o" , exe , src )
cmd . Env = append ( os . Environ ( ) ,
"CGO_ENABLED=0" ,
"GOOS=darwin" ,
"GOARCH=amd64" ,
)
if out , err := cmd . CombinedOutput ( ) ; err != nil {
t . Fatalf ( "%v: %v:\n%s" , cmd . Args , err , out )
}
exef , err := os . Open ( exe )
if err != nil {
t . Fatal ( err )
}
2021-03-07 20:52:39 -08:00
defer exef . Close ( )
2019-05-08 09:36:07 +02:00
exem , err := macho . NewFile ( exef )
if err != nil {
t . Fatal ( err )
}
found := false
2021-04-21 19:12:38 -04:00
const LC_BUILD_VERSION = 0x32
2019-05-08 09:36:07 +02:00
checkMin := func ( ver uint32 ) {
major , minor := ( ver >> 16 ) & 0xff , ( ver >> 8 ) & 0xff
if major != 10 || minor < 9 {
2021-04-21 19:12:38 -04:00
t . Errorf ( "LC_BUILD_VERSION version %d.%d < 10.9" , major , minor )
2019-05-08 09:36:07 +02:00
}
}
for _ , cmd := range exem . Loads {
raw := cmd . Raw ( )
type_ := exem . ByteOrder . Uint32 ( raw )
2021-04-21 19:12:38 -04:00
if type_ != LC_BUILD_VERSION {
2019-05-08 09:36:07 +02:00
continue
}
2021-04-21 19:12:38 -04:00
osVer := exem . ByteOrder . Uint32 ( raw [ 12 : ] )
2019-05-08 09:36:07 +02:00
checkMin ( osVer )
2021-04-21 19:12:38 -04:00
sdkVer := exem . ByteOrder . Uint32 ( raw [ 16 : ] )
2019-05-08 09:36:07 +02:00
checkMin ( sdkVer )
found = true
break
}
if ! found {
2021-04-21 19:12:38 -04:00
t . Errorf ( "no LC_BUILD_VERSION load command found" )
2019-05-08 09:36:07 +02:00
}
}
2019-10-10 12:11:06 -04:00
const Issue34788src = `
package blah
func Blah ( i int ) int {
a := [ ... ] int { 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 }
return a [ i & 7 ]
}
`
func TestIssue34788Android386TLSSequence ( t * testing . T ) {
testenv . MustHaveGoBuild ( t )
// This is a cross-compilation test, so it doesn't make
// sense to run it on every GOOS/GOARCH combination. Limit
// the test to amd64 + darwin/linux.
if runtime . GOARCH != "amd64" ||
( runtime . GOOS != "darwin" && runtime . GOOS != "linux" ) {
t . Skip ( "skipping on non-{linux,darwin}/amd64 platform" )
}
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2019-10-10 12:11:06 -04:00
src := filepath . Join ( tmpdir , "blah.go" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( Issue34788src ) , 0666 )
2019-10-10 12:11:06 -04:00
if err != nil {
t . Fatal ( err )
}
obj := filepath . Join ( tmpdir , "blah.o" )
cmd/compile: require -p flag
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>
2022-03-08 18:16:35 -05:00
cmd := exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-p=blah" , "-o" , obj , src )
2019-10-10 12:11:06 -04:00
cmd . Env = append ( os . Environ ( ) , "GOARCH=386" , "GOOS=android" )
if out , err := cmd . CombinedOutput ( ) ; err != nil {
2020-08-25 15:19:50 +02:00
t . Fatalf ( "failed to compile blah.go: %v, output: %s\n" , err , out )
2019-10-10 12:11:06 -04:00
}
// Run objdump on the resulting object.
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "objdump" , obj )
out , oerr := cmd . CombinedOutput ( )
if oerr != nil {
t . Fatalf ( "failed to objdump blah.o: %v, output: %s\n" , oerr , out )
}
// Sift through the output; we should not be seeing any R_TLS_LE relocs.
scanner := bufio . NewScanner ( bytes . NewReader ( out ) )
for scanner . Scan ( ) {
line := scanner . Text ( )
if strings . Contains ( line , "R_TLS_LE" ) {
t . Errorf ( "objdump output contains unexpected R_TLS_LE reloc: %s" , line )
}
}
}
2019-11-02 00:38:21 -04:00
const testStrictDupGoSrc = `
package main
func f ( )
func main ( ) { f ( ) }
`
const testStrictDupAsmSrc1 = `
# include "textflag.h"
TEXT · f ( SB ) , NOSPLIT | DUPOK , $ 0 - 0
RET
`
const testStrictDupAsmSrc2 = `
# include "textflag.h"
TEXT · f ( SB ) , NOSPLIT | DUPOK , $ 0 - 0
JMP 0 ( PC )
`
2021-06-08 19:45:41 -04:00
const testStrictDupAsmSrc3 = `
# include "textflag.h"
GLOBL · rcon ( SB ) , RODATA | DUPOK , $ 64
`
const testStrictDupAsmSrc4 = `
# include "textflag.h"
GLOBL · rcon ( SB ) , RODATA | DUPOK , $ 32
`
2019-11-02 00:38:21 -04:00
func TestStrictDup ( t * testing . T ) {
// Check that -strictdups flag works.
testenv . MustHaveGoBuild ( t )
2021-06-08 19:45:41 -04:00
asmfiles := [ ] struct {
fname string
payload string
} {
{ "a" , testStrictDupAsmSrc1 } ,
{ "b" , testStrictDupAsmSrc2 } ,
{ "c" , testStrictDupAsmSrc3 } ,
{ "d" , testStrictDupAsmSrc4 } ,
}
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2019-11-02 00:38:21 -04:00
src := filepath . Join ( tmpdir , "x.go" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( testStrictDupGoSrc ) , 0666 )
2019-11-02 00:38:21 -04:00
if err != nil {
t . Fatal ( err )
}
2021-06-08 19:45:41 -04:00
for _ , af := range asmfiles {
src = filepath . Join ( tmpdir , af . fname + ".s" )
err = ioutil . WriteFile ( src , [ ] byte ( af . payload ) , 0666 )
if err != nil {
t . Fatal ( err )
}
2019-11-02 00:38:21 -04:00
}
2019-11-23 00:31:39 -05:00
src = filepath . Join ( tmpdir , "go.mod" )
err = ioutil . WriteFile ( src , [ ] byte ( "module teststrictdup\n" ) , 0666 )
if err != nil {
t . Fatal ( err )
}
2019-11-02 00:38:21 -04:00
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-ldflags=-strictdups=1" )
cmd . Dir = tmpdir
out , err := cmd . CombinedOutput ( )
if err != nil {
2021-06-08 19:45:41 -04:00
t . Errorf ( "linking with -strictdups=1 failed: %v\n%s" , err , string ( out ) )
2019-11-02 00:38:21 -04:00
}
if ! bytes . Contains ( out , [ ] byte ( "mismatched payload" ) ) {
t . Errorf ( "unexpected output:\n%s" , out )
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "build" , "-ldflags=-strictdups=2" )
cmd . Dir = tmpdir
out , err = cmd . CombinedOutput ( )
if err == nil {
t . Errorf ( "linking with -strictdups=2 did not fail" )
}
2021-06-08 19:45:41 -04:00
// NB: on amd64 we get the 'new length' error, on arm64 the 'different
// contents' error.
if ! ( bytes . Contains ( out , [ ] byte ( "mismatched payload: new length" ) ) ||
bytes . Contains ( out , [ ] byte ( "mismatched payload: same length but different contents" ) ) ) ||
! bytes . Contains ( out , [ ] byte ( "mismatched payload: different sizes" ) ) {
2019-11-02 00:38:21 -04:00
t . Errorf ( "unexpected output:\n%s" , out )
}
}
2020-03-20 17:02:47 -04:00
2020-04-02 12:48:13 -04:00
const testFuncAlignSrc = `
package main
import (
"fmt"
)
func alignPc ( )
2021-06-01 19:16:33 -04:00
var alignPcFnAddr uintptr
2020-04-02 12:48:13 -04:00
func main ( ) {
2021-06-01 19:16:33 -04:00
if alignPcFnAddr % 512 != 0 {
fmt . Printf ( "expected 512 bytes alignment, got %v\n" , alignPcFnAddr )
2020-04-02 12:48:13 -04:00
} else {
fmt . Printf ( "PASS" )
}
}
`
const testFuncAlignAsmSrc = `
# include "textflag.h"
TEXT · alignPc ( SB ) , NOSPLIT , $ 0 - 0
MOVD $ 2 , R0
PCALIGN $ 512
MOVD $ 3 , R1
RET
2021-06-01 19:16:33 -04:00
GLOBL · alignPcFnAddr ( SB ) , RODATA , $ 8
DATA · alignPcFnAddr ( SB ) / 8 , $ · alignPc ( SB )
2020-04-02 12:48:13 -04:00
`
// TestFuncAlign verifies that the address of a function can be aligned
2021-02-13 02:45:51 +00:00
// with a specific value on arm64.
2020-04-02 12:48:13 -04:00
func TestFuncAlign ( t * testing . T ) {
if runtime . GOARCH != "arm64" || runtime . GOOS != "linux" {
t . Skip ( "skipping on non-linux/arm64 platform" )
}
testenv . MustHaveGoBuild ( t )
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2020-04-02 12:48:13 -04:00
2020-09-21 12:10:16 -04:00
src := filepath . Join ( tmpdir , "go.mod" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( "module cmd/link/TestFuncAlign/falign" ) , 0666 )
2020-09-21 12:10:16 -04:00
if err != nil {
t . Fatal ( err )
}
src = filepath . Join ( tmpdir , "falign.go" )
2020-04-02 12:48:13 -04:00
err = ioutil . WriteFile ( src , [ ] byte ( testFuncAlignSrc ) , 0666 )
if err != nil {
t . Fatal ( err )
}
src = filepath . Join ( tmpdir , "falign.s" )
err = ioutil . WriteFile ( src , [ ] byte ( testFuncAlignAsmSrc ) , 0666 )
if err != nil {
t . Fatal ( err )
}
// Build and run with old object file format.
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-o" , "falign" )
cmd . Dir = tmpdir
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "build failed: %v" , err )
}
cmd = exec . Command ( tmpdir + "/falign" )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "failed to run with err %v, output: %s" , err , out )
}
if string ( out ) != "PASS" {
t . Errorf ( "unexpected output: %s\n" , out )
}
}
2020-04-10 14:58:54 -04:00
2020-05-14 19:22:59 -04:00
const testTrampSrc = `
2020-04-10 14:58:54 -04:00
package main
import "fmt"
2020-05-14 19:22:59 -04:00
func main ( ) {
fmt . Println ( "hello" )
defer func ( ) {
if e := recover ( ) ; e == nil {
panic ( "did not panic" )
}
} ( )
f1 ( )
}
// Test deferreturn trampolines. See issue #39049.
func f1 ( ) { defer f2 ( ) }
func f2 ( ) { panic ( "XXX" ) }
2020-04-10 14:58:54 -04:00
`
func TestTrampoline ( t * testing . T ) {
// Test that trampoline insertion works as expected.
// For stress test, we set -debugtramp=2 flag, which sets a very low
// threshold for trampoline generation, and essentially all cross-package
// calls will use trampolines.
2021-05-03 11:00:54 -05:00
buildmodes := [ ] string { "default" }
2020-04-10 14:58:54 -04:00
switch runtime . GOARCH {
2021-05-03 11:00:54 -05:00
case "arm" , "arm64" , "ppc64" :
case "ppc64le" :
// Trampolines are generated differently when internal linking PIE, test them too.
buildmodes = append ( buildmodes , "pie" )
2020-04-10 14:58:54 -04:00
default :
t . Skipf ( "trampoline insertion is not implemented on %s" , runtime . GOARCH )
}
testenv . MustHaveGoBuild ( t )
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2020-04-10 14:58:54 -04:00
src := filepath . Join ( tmpdir , "hello.go" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( testTrampSrc ) , 0666 )
2020-04-10 14:58:54 -04:00
if err != nil {
t . Fatal ( err )
}
exe := filepath . Join ( tmpdir , "hello.exe" )
2021-05-03 11:00:54 -05:00
for _ , mode := range buildmodes {
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-buildmode=" + mode , "-ldflags=-debugtramp=2" , "-o" , exe , src )
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "build (%s) failed: %v\n%s" , mode , err , out )
}
cmd = exec . Command ( exe )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "executable failed to run (%s): %v\n%s" , mode , err , out )
}
if string ( out ) != "hello\n" {
t . Errorf ( "unexpected output (%s):\n%s" , mode , out )
}
2021-04-27 14:57:11 -04:00
}
}
const testTrampCgoSrc = `
package main
// #include <stdio.h>
// void CHello() { printf("hello\n"); fflush(stdout); }
import "C"
func main ( ) {
C . CHello ( )
}
`
func TestTrampolineCgo ( t * testing . T ) {
// Test that trampoline insertion works for cgo code.
// For stress test, we set -debugtramp=2 flag, which sets a very low
// threshold for trampoline generation, and essentially all cross-package
// calls will use trampolines.
2021-05-03 11:00:54 -05:00
buildmodes := [ ] string { "default" }
2021-04-27 14:57:11 -04:00
switch runtime . GOARCH {
2021-05-03 11:00:54 -05:00
case "arm" , "arm64" , "ppc64" :
case "ppc64le" :
// Trampolines are generated differently when internal linking PIE, test them too.
buildmodes = append ( buildmodes , "pie" )
2021-04-27 14:57:11 -04:00
default :
t . Skipf ( "trampoline insertion is not implemented on %s" , runtime . GOARCH )
}
testenv . MustHaveGoBuild ( t )
testenv . MustHaveCGO ( t )
t . Parallel ( )
tmpdir := t . TempDir ( )
src := filepath . Join ( tmpdir , "hello.go" )
err := ioutil . WriteFile ( src , [ ] byte ( testTrampCgoSrc ) , 0666 )
if err != nil {
t . Fatal ( err )
}
exe := filepath . Join ( tmpdir , "hello.exe" )
2021-05-03 11:00:54 -05:00
for _ , mode := range buildmodes {
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-buildmode=" + mode , "-ldflags=-debugtramp=2" , "-o" , exe , src )
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "build (%s) failed: %v\n%s" , mode , err , out )
}
cmd = exec . Command ( exe )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "executable failed to run (%s): %v\n%s" , mode , err , out )
}
if string ( out ) != "hello\n" && string ( out ) != "hello\r\n" {
t . Errorf ( "unexpected output (%s):\n%s" , mode , out )
}
2021-04-27 14:57:11 -04:00
2021-05-03 11:00:54 -05:00
// Test internal linking mode.
2021-04-27 14:57:11 -04:00
2021-05-03 11:00:54 -05:00
if runtime . GOARCH == "ppc64" || ( runtime . GOARCH == "arm64" && runtime . GOOS == "windows" ) || ! testenv . CanInternalLink ( ) {
return // internal linking cgo is not supported
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "build" , "-buildmode=" + mode , "-ldflags=-debugtramp=2 -linkmode=internal" , "-o" , exe , src )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "build (%s) failed: %v\n%s" , mode , err , out )
}
cmd = exec . Command ( exe )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "executable failed to run (%s): %v\n%s" , mode , err , out )
}
if string ( out ) != "hello\n" && string ( out ) != "hello\r\n" {
t . Errorf ( "unexpected output (%s):\n%s" , mode , out )
}
2020-04-10 14:58:54 -04:00
}
}
2020-04-22 22:20:44 -04:00
func TestIndexMismatch ( t * testing . T ) {
// Test that index mismatch will cause a link-time error (not run-time error).
// This shouldn't happen with "go build". We invoke the compiler and the linker
// manually, and try to "trick" the linker with an inconsistent object file.
testenv . MustHaveGoBuild ( t )
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2020-04-22 22:20:44 -04:00
aSrc := filepath . Join ( "testdata" , "testIndexMismatch" , "a.go" )
bSrc := filepath . Join ( "testdata" , "testIndexMismatch" , "b.go" )
mSrc := filepath . Join ( "testdata" , "testIndexMismatch" , "main.go" )
aObj := filepath . Join ( tmpdir , "a.o" )
mObj := filepath . Join ( tmpdir , "main.o" )
exe := filepath . Join ( tmpdir , "main.exe" )
// Build a program with main package importing package a.
cmd/compile: require -p flag
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>
2022-03-08 18:16:35 -05:00
cmd := exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-p=a" , "-o" , aObj , aSrc )
2020-04-22 22:20:44 -04:00
t . Log ( cmd )
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "compiling a.go failed: %v\n%s" , err , out )
}
cmd/compile: require -p flag
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>
2022-03-08 18:16:35 -05:00
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-p=main" , "-I" , tmpdir , "-o" , mObj , mSrc )
2020-04-22 22:20:44 -04:00
t . Log ( cmd )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "compiling main.go failed: %v\n%s" , err , out )
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "link" , "-L" , tmpdir , "-o" , exe , mObj )
t . Log ( cmd )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "linking failed: %v\n%s" , err , out )
}
// Now, overwrite a.o with the object of b.go. This should
// result in an index mismatch.
cmd/compile: require -p flag
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>
2022-03-08 18:16:35 -05:00
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-p=a" , "-o" , aObj , bSrc )
2020-04-22 22:20:44 -04:00
t . Log ( cmd )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "compiling a.go failed: %v\n%s" , err , out )
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "link" , "-L" , tmpdir , "-o" , exe , mObj )
t . Log ( cmd )
out , err = cmd . CombinedOutput ( )
if err == nil {
t . Fatalf ( "linking didn't fail" )
}
if ! bytes . Contains ( out , [ ] byte ( "fingerprint mismatch" ) ) {
t . Errorf ( "did not see expected error message. out:\n%s" , out )
}
}
2020-06-18 18:05:10 -04:00
2021-02-04 00:11:12 +01:00
func TestPErsrcBinutils ( t * testing . T ) {
2020-06-18 18:05:10 -04:00
// Test that PE rsrc section is handled correctly (issue 39658).
testenv . MustHaveGoBuild ( t )
2021-02-04 00:11:12 +01:00
if ( runtime . GOARCH != "386" && runtime . GOARCH != "amd64" ) || runtime . GOOS != "windows" {
// This test is limited to amd64 and 386, because binutils is limited as such
t . Skipf ( "this is only for windows/amd64 and windows/386" )
2020-06-18 18:05:10 -04:00
}
2020-07-06 17:49:24 -04:00
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2020-06-18 18:05:10 -04:00
2021-02-04 00:11:12 +01:00
pkgdir := filepath . Join ( "testdata" , "pe-binutils" )
2020-06-18 18:05:10 -04:00
exe := filepath . Join ( tmpdir , "a.exe" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-o" , exe )
cmd . Dir = pkgdir
// cmd.Env = append(os.Environ(), "GOOS=windows", "GOARCH=amd64") // uncomment if debugging in a cross-compiling environment
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "building failed: %v, output:\n%s" , err , out )
}
// Check that the binary contains the rsrc data
b , err := ioutil . ReadFile ( exe )
if err != nil {
t . Fatalf ( "reading output failed: %v" , err )
}
if ! bytes . Contains ( b , [ ] byte ( "Hello Gophers!" ) ) {
t . Fatalf ( "binary does not contain expected content" )
}
2021-02-04 00:11:12 +01:00
}
func TestPErsrcLLVM ( t * testing . T ) {
// Test that PE rsrc section is handled correctly (issue 39658).
testenv . MustHaveGoBuild ( t )
if runtime . GOOS != "windows" {
t . Skipf ( "this is a windows-only test" )
}
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
cmd/link: handle grouped resource sections
The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.
However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.
So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.
We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.
Fixes #42866.
Fixes #43182.
Change-Id: I059450021405cdf2ef1c195ddbab3960764ad711
Reviewed-on: https://go-review.googlesource.com/c/go/+/268337
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
2020-11-08 11:57:42 +01:00
2021-02-04 00:11:12 +01:00
pkgdir := filepath . Join ( "testdata" , "pe-llvm" )
exe := filepath . Join ( tmpdir , "a.exe" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-o" , exe )
cmd/link: handle grouped resource sections
The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.
However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.
So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.
We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.
Fixes #42866.
Fixes #43182.
Change-Id: I059450021405cdf2ef1c195ddbab3960764ad711
Reviewed-on: https://go-review.googlesource.com/c/go/+/268337
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
2020-11-08 11:57:42 +01:00
cmd . Dir = pkgdir
// cmd.Env = append(os.Environ(), "GOOS=windows", "GOARCH=amd64") // uncomment if debugging in a cross-compiling environment
2021-02-04 00:11:12 +01:00
out , err := cmd . CombinedOutput ( )
cmd/link: handle grouped resource sections
The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.
However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.
So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.
We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.
Fixes #42866.
Fixes #43182.
Change-Id: I059450021405cdf2ef1c195ddbab3960764ad711
Reviewed-on: https://go-review.googlesource.com/c/go/+/268337
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
2020-11-08 11:57:42 +01:00
if err != nil {
t . Fatalf ( "building failed: %v, output:\n%s" , err , out )
}
// Check that the binary contains the rsrc data
2021-02-04 00:11:12 +01:00
b , err := ioutil . ReadFile ( exe )
cmd/link: handle grouped resource sections
The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.
However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.
So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.
We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.
Fixes #42866.
Fixes #43182.
Change-Id: I059450021405cdf2ef1c195ddbab3960764ad711
Reviewed-on: https://go-review.googlesource.com/c/go/+/268337
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
2020-11-08 11:57:42 +01:00
if err != nil {
t . Fatalf ( "reading output failed: %v" , err )
}
if ! bytes . Contains ( b , [ ] byte ( "resname RCDATA a.rc" ) ) {
t . Fatalf ( "binary does not contain expected content" )
}
2020-06-18 18:05:10 -04:00
}
2020-07-20 18:07:00 -04:00
func TestContentAddressableSymbols ( t * testing . T ) {
// Test that the linker handles content-addressable symbols correctly.
testenv . MustHaveGoBuild ( t )
t . Parallel ( )
src := filepath . Join ( "testdata" , "testHashedSyms" , "p.go" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "run" , src )
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "command %s failed: %v\n%s" , cmd , err , out )
}
}
2020-09-10 11:14:27 -04:00
func TestReadOnly ( t * testing . T ) {
// Test that read-only data is indeed read-only.
testenv . MustHaveGoBuild ( t )
t . Parallel ( )
src := filepath . Join ( "testdata" , "testRO" , "x.go" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "run" , src )
out , err := cmd . CombinedOutput ( )
if err == nil {
t . Errorf ( "running test program did not fail. output:\n%s" , out )
}
}
2020-10-22 10:05:44 -04:00
const testIssue38554Src = `
package main
type T [ 10 << 20 ] byte
//go:noinline
func f ( ) T {
return T { } // compiler will make a large stmp symbol, but not used.
}
func main ( ) {
x := f ( )
println ( x [ 1 ] )
}
`
func TestIssue38554 ( t * testing . T ) {
testenv . MustHaveGoBuild ( t )
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2020-10-22 10:05:44 -04:00
src := filepath . Join ( tmpdir , "x.go" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( testIssue38554Src ) , 0666 )
2020-10-22 10:05:44 -04:00
if err != nil {
t . Fatalf ( "failed to write source file: %v" , err )
}
exe := filepath . Join ( tmpdir , "x.exe" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-o" , exe , src )
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "build failed: %v\n%s" , err , out )
}
fi , err := os . Stat ( exe )
if err != nil {
t . Fatalf ( "failed to stat output file: %v" , err )
}
// The test program is not much different from a helloworld, which is
// typically a little over 1 MB. We allow 5 MB. If the bad stmp is live,
// it will be over 10 MB.
const want = 5 << 20
if got := fi . Size ( ) ; got > want {
t . Errorf ( "binary too big: got %d, want < %d" , got , want )
}
}
cmd/link: report error if builtin referenced but not defined
When the compiler refers to a runtime builtin, it emits an indexed
symbol reference in the object file via predetermined/preassigned ID
within the PkgIdxBuiltin pseudo-package. At link time when the loader
encounters these references, it redirects them to the corresponding
defined symbol in the runtime package. This redirection process
currently assumes that if a runtime builtin is referenced, we'll
always have a definition for it. This assumption holds in most cases,
however for the builtins "runtime.racefuncenter" and
"runtime.racefuncexit", we'll only see definitions if the runtime
package we're linking against was built with "-race".
In the bug in question, build passes "-gcflags=-race" during
compilation of the main package, but doesn't pass "-race" directly to
'go build', and as a result the final link combines a
race-instrumented main with a non-race runtime; this results in R_CALL
relocations with zero-valued target symbols, resulting in a panic
during stack checking.
This patch changes the loader's resolve method to detect situations
where we're asking for builtin "runtime.X", but the runtime package
read in doesn't contain a definition for X.
Fixes #42396.
Change-Id: Iafd38bd3b0f7f462868d120ccd4d7d1b88b27436
Reviewed-on: https://go-review.googlesource.com/c/go/+/267881
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
2020-11-05 14:19:47 -05:00
const testIssue42396src = `
package main
//go:noinline
//go:nosplit
func callee ( x int ) {
}
func main ( ) {
callee ( 9 )
}
`
func TestIssue42396 ( t * testing . T ) {
testenv . MustHaveGoBuild ( t )
if ! sys . RaceDetectorSupported ( runtime . GOOS , runtime . GOARCH ) {
t . Skip ( "no race detector support" )
}
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
cmd/link: report error if builtin referenced but not defined
When the compiler refers to a runtime builtin, it emits an indexed
symbol reference in the object file via predetermined/preassigned ID
within the PkgIdxBuiltin pseudo-package. At link time when the loader
encounters these references, it redirects them to the corresponding
defined symbol in the runtime package. This redirection process
currently assumes that if a runtime builtin is referenced, we'll
always have a definition for it. This assumption holds in most cases,
however for the builtins "runtime.racefuncenter" and
"runtime.racefuncexit", we'll only see definitions if the runtime
package we're linking against was built with "-race".
In the bug in question, build passes "-gcflags=-race" during
compilation of the main package, but doesn't pass "-race" directly to
'go build', and as a result the final link combines a
race-instrumented main with a non-race runtime; this results in R_CALL
relocations with zero-valued target symbols, resulting in a panic
during stack checking.
This patch changes the loader's resolve method to detect situations
where we're asking for builtin "runtime.X", but the runtime package
read in doesn't contain a definition for X.
Fixes #42396.
Change-Id: Iafd38bd3b0f7f462868d120ccd4d7d1b88b27436
Reviewed-on: https://go-review.googlesource.com/c/go/+/267881
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
2020-11-05 14:19:47 -05:00
src := filepath . Join ( tmpdir , "main.go" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( testIssue42396src ) , 0666 )
cmd/link: report error if builtin referenced but not defined
When the compiler refers to a runtime builtin, it emits an indexed
symbol reference in the object file via predetermined/preassigned ID
within the PkgIdxBuiltin pseudo-package. At link time when the loader
encounters these references, it redirects them to the corresponding
defined symbol in the runtime package. This redirection process
currently assumes that if a runtime builtin is referenced, we'll
always have a definition for it. This assumption holds in most cases,
however for the builtins "runtime.racefuncenter" and
"runtime.racefuncexit", we'll only see definitions if the runtime
package we're linking against was built with "-race".
In the bug in question, build passes "-gcflags=-race" during
compilation of the main package, but doesn't pass "-race" directly to
'go build', and as a result the final link combines a
race-instrumented main with a non-race runtime; this results in R_CALL
relocations with zero-valued target symbols, resulting in a panic
during stack checking.
This patch changes the loader's resolve method to detect situations
where we're asking for builtin "runtime.X", but the runtime package
read in doesn't contain a definition for X.
Fixes #42396.
Change-Id: Iafd38bd3b0f7f462868d120ccd4d7d1b88b27436
Reviewed-on: https://go-review.googlesource.com/c/go/+/267881
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
2020-11-05 14:19:47 -05:00
if err != nil {
t . Fatalf ( "failed to write source file: %v" , err )
}
exe := filepath . Join ( tmpdir , "main.exe" )
cmd := exec . Command ( testenv . GoToolPath ( t ) , "build" , "-gcflags=-race" , "-o" , exe , src )
out , err := cmd . CombinedOutput ( )
if err == nil {
t . Fatalf ( "build unexpectedly succeeded" )
}
// Check to make sure that we see a reasonable error message
// and not a panic.
if strings . Contains ( string ( out ) , "panic:" ) {
t . Fatalf ( "build should not fail with panic:\n%s" , out )
}
const want = "reference to undefined builtin"
if ! strings . Contains ( string ( out ) , want ) {
t . Fatalf ( "error message incorrect: expected it to contain %q but instead got:\n%s\n" , want , out )
}
}
2020-12-14 18:52:13 -05:00
const testLargeRelocSrc = `
package main
var x = [ 1 << 25 ] byte { 1 << 23 : 23 , 1 << 24 : 24 }
cmd/link: don't use label symbol for absolute address relocations on ARM64 PE
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes #47557.
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
2021-11-02 18:30:08 -04:00
var addr = [ ... ] * byte {
& x [ 1 << 23 - 1 ] ,
& x [ 1 << 23 ] ,
& x [ 1 << 23 + 1 ] ,
& x [ 1 << 24 - 1 ] ,
& x [ 1 << 24 ] ,
& x [ 1 << 24 + 1 ] ,
}
2020-12-14 18:52:13 -05:00
func main ( ) {
cmd/link: don't use label symbol for absolute address relocations on ARM64 PE
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes #47557.
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
2021-11-02 18:30:08 -04:00
// check relocations in instructions
2020-12-14 18:52:13 -05:00
check ( x [ 1 << 23 - 1 ] , 0 )
check ( x [ 1 << 23 ] , 23 )
check ( x [ 1 << 23 + 1 ] , 0 )
check ( x [ 1 << 24 - 1 ] , 0 )
check ( x [ 1 << 24 ] , 24 )
check ( x [ 1 << 24 + 1 ] , 0 )
cmd/link: don't use label symbol for absolute address relocations on ARM64 PE
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes #47557.
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
2021-11-02 18:30:08 -04:00
// check absolute address relocations in data
check ( * addr [ 0 ] , 0 )
check ( * addr [ 1 ] , 23 )
check ( * addr [ 2 ] , 0 )
check ( * addr [ 3 ] , 0 )
check ( * addr [ 4 ] , 24 )
check ( * addr [ 5 ] , 0 )
2020-12-14 18:52:13 -05:00
}
func check ( x , y byte ) {
if x != y {
panic ( "FAIL" )
}
}
`
func TestLargeReloc ( t * testing . T ) {
// Test that large relocation addend is handled correctly.
// In particular, on darwin/arm64 when external linking,
// Mach-O relocation has only 24-bit addend. See issue #42738.
testenv . MustHaveGoBuild ( t )
t . Parallel ( )
2021-03-07 20:52:39 -08:00
tmpdir := t . TempDir ( )
2020-12-14 18:52:13 -05:00
src := filepath . Join ( tmpdir , "x.go" )
2021-03-07 20:52:39 -08:00
err := ioutil . WriteFile ( src , [ ] byte ( testLargeRelocSrc ) , 0666 )
2020-12-14 18:52:13 -05:00
if err != nil {
t . Fatalf ( "failed to write source file: %v" , err )
}
cmd := exec . Command ( testenv . GoToolPath ( t ) , "run" , src )
out , err := cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "build failed: %v. output:\n%s" , err , out )
}
if testenv . HasCGO ( ) { // currently all targets that support cgo can external link
cmd = exec . Command ( testenv . GoToolPath ( t ) , "run" , "-ldflags=-linkmode=external" , src )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "build failed: %v. output:\n%s" , err , out )
}
}
}
2022-03-21 13:45:50 -04:00
func TestUnlinkableObj ( t * testing . T ) {
// Test that the linker emits an error with unlinkable object.
testenv . MustHaveGoBuild ( t )
t . Parallel ( )
tmpdir := t . TempDir ( )
2022-03-22 17:08:56 -04:00
xSrc := filepath . Join ( tmpdir , "x.go" )
pSrc := filepath . Join ( tmpdir , "p.go" )
xObj := filepath . Join ( tmpdir , "x.o" )
pObj := filepath . Join ( tmpdir , "p.o" )
2022-03-22 16:38:13 -04:00
exe := filepath . Join ( tmpdir , "x.exe" )
2022-03-22 17:08:56 -04:00
err := ioutil . WriteFile ( xSrc , [ ] byte ( "package main\nimport _ \"p\"\nfunc main() {}\n" ) , 0666 )
2022-03-21 13:45:50 -04:00
if err != nil {
t . Fatalf ( "failed to write source file: %v" , err )
}
2022-03-22 17:08:56 -04:00
err = ioutil . WriteFile ( pSrc , [ ] byte ( "package p\n" ) , 0666 )
if err != nil {
t . Fatalf ( "failed to write source file: %v" , err )
}
cmd := exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-o" , pObj , pSrc ) // without -p
2022-03-21 13:45:50 -04:00
out , err := cmd . CombinedOutput ( )
if err != nil {
2022-03-22 17:08:56 -04:00
t . Fatalf ( "compile p.go failed: %v. output:\n%s" , err , out )
2022-03-21 13:45:50 -04:00
}
2022-03-22 17:08:56 -04:00
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-I" , tmpdir , "-p=main" , "-o" , xObj , xSrc )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "compile x.go failed: %v. output:\n%s" , err , out )
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "link" , "-L" , tmpdir , "-o" , exe , xObj )
2022-03-21 13:45:50 -04:00
out , err = cmd . CombinedOutput ( )
if err == nil {
t . Fatalf ( "link did not fail" )
}
if ! bytes . Contains ( out , [ ] byte ( "unlinkable object" ) ) {
t . Errorf ( "did not see expected error message. out:\n%s" , out )
}
2022-03-22 17:08:56 -04:00
// It is okay to omit -p for (only) main package.
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-p=p" , "-o" , pObj , pSrc )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "compile p.go failed: %v. output:\n%s" , err , out )
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "compile" , "-I" , tmpdir , "-o" , xObj , xSrc ) // without -p
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Fatalf ( "compile failed: %v. output:\n%s" , err , out )
}
cmd = exec . Command ( testenv . GoToolPath ( t ) , "tool" , "link" , "-L" , tmpdir , "-o" , exe , xObj )
out , err = cmd . CombinedOutput ( )
if err != nil {
t . Errorf ( "link failed: %v. output:\n%s" , err , out )
}
2022-03-21 13:45:50 -04:00
}