cmd/link: -X on a constant, type, or func doesn't report an error

[colin-sitehost]

What version of Go are you using (go version)?

$ go version
go version go1.16.5 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GOOS="linux"
GOPATH="/home/user/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/path/to/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1151947343=/tmp/go-build -gno-record-gcc-switches"

What did you do?

package main

import "fmt"

const Const = "one"

func Func() string { return "two" }

type Type struct{}

func main() {
	fmt.Println(Const, Func(), Type{})
}

go run -ldflags "-X=main.Const=three -X=main.Func=four -X=main.Type=five" .

What did you expect to see?

main.Const: cannot set with -X: const not supported
main.Func: cannot set with -X: func not supported
main.Type: cannot set with -X: type not supported

What did you see instead?

one two {}

[mknyszek]

I don't think it's possible to override a constant at link time (ldflags is passing additional flags to the linker), because by that point the compiler has already propagated the constant. It doesn't exist anymore at that point. This is not only a technical limitation, but a language limitation, too. Note that constants are only compile-time, not link-time.

Variables on the other hand, do have a specific location that the linker can populate, hence how -X works.

[mknyszek]

Oh, and I should also mention that types are also only compile-time, hence that restriction. And finally, top-level functions are immutable.

[zikaeroh]

Unless I'm mistaken, the original issue was saying that these cases silently failed, not that they should work, hence the expected behavior being error messages, but the actual behavior being a runnable binary.

[zikaeroh]

And indeed:

$ cat main.go
package main

import "fmt"

const Const = "one"

func Func() string { return "two" }

type Type struct{}

func main() {
	fmt.Println(Const, Func(), Type{})
}

$ go run -ldflags "-X=main.Const=three -X=main.Func=four -X=main.Type=five" .
one two {}

To show that the -X flag names are valid, a regular var works:

$ cat main.go
package main

import "fmt"

var Var string

const Const = "one"

func Func() string { return "two" }

type Type struct{}

func main() {
	fmt.Println(Var, Const, Func(), Type{})
}

$ go run -ldflags "-X=main.Var=var -X=main.Const=three -X=main.Func=four -X=main.Type=five" .
var one two {}

[mknyszek]

@zikaeroh Got it. Thanks.

I'm not sure it's actually possible for the linker to know what Const, Func, or Type are, but it could at least say something like that relocation doesn't exist.

CC @cherrymui @thanm

[thanm]

This would be a relatively straightforward change to make, but I would be a little concerned that there is a lot of code that already relies on the current behavior (which is to say, if the "-X" symbol is not present or not a variable, the option is silently ignored).

In the current implementation, -X is silently ignored if:

• the named symbol is not found
• the symbol is not a variable
• the symbol is dead

It would seem weird to add a new error for "symbol not a variable" and not have errors for the other cases.

[colin-sitehost]

if we are concerned with compatibility, just pix the fix to a version in go.mod; but it reads as undefined behaviour today, so I think we could convince ourselves that this is fine? clearly the current behaviour is different, but "try your best to set pkg.sym" seems like a bad interface, esp since some things can fail. (e.g. var is not string/[]byte)

I support returning errors for "not found" and "not var", not sure what "dead" means in this context?

[thanm]

I support returning errors for "not found" and "not var", not sure what "dead" means in this context?

By "dead" I mean unreachable/unreferenced (transitively) from main.main. The linker's "dead code" pass will remove such variables.