Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/link: load of "ld -r" host object fails in -newobj mode #35779
Comments
This comment has been minimized.
This comment has been minimized.
|
@cherrymui , @jeremyfaller just as FYI |
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/208478 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/208479 mentions this issue: |
This adds a new test that builds a small Go program with linked against a *.syso file that is the result of an "ld -r" link. The sysobj in question has multiple static symbols in the same section with the same name, which triggered a bug in the loader in -newobj mode. Updates #35779. Change-Id: Ibe1a75662dc1d49c4347279e55646ee65a81508e Reviewed-on: https://go-review.googlesource.com/c/go/+/208478 Reviewed-by: Cherry Zhang <cherryyz@google.com>
This comment has been minimized.
This comment has been minimized.
|
The new testcase broke the MIPS builders -- reopening while I work on that. |
This comment has been minimized.
This comment has been minimized.
|
Representative failures: https://build.golang.org/log/98d47379c6065fd00edcd68aa384451c5deae722
elf_test.go:202: # elf_test
loadelf: $WORK/b001/_pkg_.a(ldr.syso): malformed elf file: invalid elf symbol index
https://build.golang.org/log/ad7532a8bd9457571fe394269d7a017b82abe21e
elf_test.go:202: # elf_test
/tmp/gobuilder-mips64/tmp/go-build246906970/b001/_pkg_.a(ldr.syso): unknown relocation type 333831; compiled without -fpic?
|
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/208557 mentions this issue: |
Skip TestMinusRSymsWithSameName testpoint on MIPS for the time being since it triggers failures on that arch. Will re-enable once the problems are fixed. Updates #35779. Change-Id: I3e6650158ab04a2be77e3db5a5194df3bbb0859e Reviewed-on: https://go-review.googlesource.com/c/go/+/208557 Reviewed-by: Cherry Zhang <cherryyz@google.com>
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/208778 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/209317 mentions this issue: |
The previous fix for this issue (CL 208479) was not general enough; this patch revises it to handle more cases. The problem with the original fix was that once a sym.Symbol is created for a given static symbol and given a bogus anonymous version of -1, we hit problems if some other non-anonymous symbol (created by host object loading) had relocations targeting the static symbol. In this patch instead of assigning a fixed anonymous version of -1 to such symbols, each time loader.Create is invoked we create a new (unique) anonymous version for the sym.Symbol, then enter the result into the loader's extStaticSyms map, permitting it to be found in lookups when processing relocation targets. NB: this code will hopefully get a lot simpler once we can move host object loading away from early sym.Symbol creation. Updates #35779. Change-Id: I450ff577e17549025565d355d6707a2d28a5a617 Reviewed-on: https://go-review.googlesource.com/c/go/+/208778 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/209658 mentions this issue: |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?linux/amd64
What did you do?
Build a small program that links in a *.syso object that contains multiple static symbols that have the same name and section.
This is a bit elaborate, but here is a repro recipe:
$ cat /tmp/c1.c static void blah() { } int c1() { return 42; } $ cat /tmp/c2.c static void blah() { } int c2() { return 42; } $ gcc -c -o c1.o /tmp/c1.c $ gcc -c -o c2.o /tmp/c2.c $ ld -r -o ldr.syso c1.o c2.o $ objdump -t ldr.syso | fgrep blah 0000000000000000 l F .text 0000000000000007 blah 0000000000000012 l F .text 0000000000000007 blah $ rm c1.o c2.o $ cat main.go package main func main() { } $ go build . $ go build -asmflags=all=-newobj -gcflags=all=-newobj -ldflags=-newobj . # ... loadelf: $WORK/b001/_pkg_.a(ldr.syso): duplicate symbol reference: blah in both main(.text) and main(.text) $What did you expect to see?
Clean build with -newobj.
What did you see instead?
loadelf error.