Skip to content

cmd/link: unexpected R_386_GOT32 relocation #71293

Open

Description

@dbenoit17

Go version

go version go1.23.4 linux/386

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='386'
GOBIN=''
GOCACHE='/builddir/.cache/go-build'
GOENV='/builddir/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='386'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/builddir/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/builddir/go'
GOPRIVATE=''
GOPROXY='direct'
GOROOT='/usr/lib/golang'
GOSUMDB='off'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_386'
GOVCS=''
GOVERSION='go1.23.4'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/builddir/.config/go/telemetry'
GCCGO='gccgo'
GO386='sse2'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m32 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3544270386=/tmp/go-build -gno-record-gcc-switches'

What did you do?

Compile the following program using GCC 15.0.1.

sh-5.2# gcc --version
gcc (GCC) 15.0.1 20250114 (Red Hat 15.0.1-0)

sh-5.2# cat test.go
package main

/*
extern void crosscall2 (void (*fn) (void *, int), void *, int);
extern void _cgo_panic (void *, int);
extern void _cgo_allocate (void *, int);

void
callPanic (void)
{
	  struct { const char *p; } a;
	  a.p = "panic from C";
	  crosscall2 (_cgo_panic, &a, sizeof a);
	  *(int*) 1 = 1;
}
*/
import "C"

func main() {
	C.callPanic()
}

sh-5.2# CGO_CFLAGS="-O2 -m32 -fpic" go build -ldflags "-linkmode internal" test.go 

This issue is also present when running go tool dist test -run=^cmd/cgo/internal/test:internal$ using GCC 15.0.1.

What did you see happen?

The Go linker encounters an unexpected relocation in GCC emitted object code.

sh-5.2# CGO_CFLAGS="-O2 -m32 -fpic" go build -ldflags "-linkmode internal" test.go 
# command-line-arguments
main(.text): unexpected GOT reloc for non-dynamic symbol _cgo_panic
main(.text): unsupported dynamic relocation for symbol _cgo_panic (type=259 (R_386_GOT32) stype=1 (STEXT))

The linker is expecting to find the instruction pushl _cgo_panic@GOT(%ebx), but instead encounters pushl _cgo_panic@GOT(%eax). According to gcc devs, this is valid (though sub optimal) code that the Go linker should handle.

What did you expect to see?

The example program should build and link correctly.

Activity

  1. mknyszek commented on Jan 16, 2025

    @mknyszek
    Contributor

    CC @golang/compiler

  2. added
    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
    on Jan 16, 2025
  3. added this to the Backlog milestone on Jan 16, 2025
  4. mknyszek commented on Jan 22, 2025

    @mknyszek
    Contributor

    This looks like something we'll need to handle soon. GCC 15 isn't released yet, but will be coming soon.

    CC @cherrymui

  5. self-assigned this
    on Jan 23, 2025
  6. alexsaezm commented on Jan 30, 2025

    @alexsaezm
    Contributor

    Just for the record, we located this issue around two weeks ago in Fedora during the mass rebuild for the next release, which will include GCC 15. We have a workaround patch, but I guess I need to revisit this now that there is a fix on the GCC side.

  7. cherrymui commented on Jan 30, 2025

    @cherrymui
    Member

    The patch looks good. Thanks. Even if GCC fixes it and continue to generate PUSH with BX, the patch doesn't hurt. Would you like to send a CL?

    In general, internal linking mode with cgo is not the default, and we don't intend it to work with all C code, so we don't need to handle the more general cases. But this specific case is fine, especially if it helps compatible with GCC.

    Thanks.

  8. gopherbot commented on Feb 6, 2025

    @gopherbot
    Contributor

    Change https://go.dev/cl/647135 mentions this issue: cmd/link: handle unexpected R_386_GOT32 relocation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.

Type

No type

Projects

Relationships

None yet

Development

No branches or pull requests

Issue actions