cmd/link: load of "ld -r" host object fails in -newobj mode #35779
Comments
|
@cherrymui , @jeremyfaller just as FYI |
|
Change https://golang.org/cl/208478 mentions this issue: |
|
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>
|
The new testcase broke the MIPS builders -- reopening while I work on that. |
|
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?
|
|
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>
|
Change https://golang.org/cl/208778 mentions this issue: |
|
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>
|
Change https://golang.org/cl/209658 mentions this issue: |
Bring in Than's fix of #35779. The only merge conflict is cmd/link/internal/loadelf/ldelf.go, with a modification-deletion conflict. Change-Id: Id2fcfd2094a31120966a6ea9c462b4ec76646b10
|
@thanm Anything else to do here for 1.14? |
|
No. I think we can close this. It was reopened because the test failed on MIPS. I think that is due to a different problem. |
The relocation of MIPS64 family ELF is different with other architecure according to the document from Linux-MIPS https://www.linux-mips.org/pub/linux/mips/doc/ABI/elf64-2.4.pdf In "2.9 Relocation" it shows relocation section contains five parts: 1. r_sym Elf64_Word Symbol index 2. r_ssym Elf64_Byte Special symbol 3. r_type3 Elf64_Byte Relocation type 4. r_type2 Elf64_Byte Relocation type 5. r_type Elf64_Byte Relocation type This CL makes loadelf aware the difference. Update #35779 Change-Id: Ib221665641972b1c2bfea5a496e3118e5dc0bc45 Reviewed-on: https://go-review.googlesource.com/c/go/+/209317 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
Change https://golang.org/cl/210578 mentions this issue: |
|
https://go-review.googlesource.com/c/go/+/209317 is causing some issues with the builders (missing import). I sent a fix. |
Fix an imports problem in this test (doesn't compile). Updates #35779 Change-Id: Icaeec0384bf2e75696e43d9410df7219f0245940 Reviewed-on: https://go-review.googlesource.com/c/go/+/210578 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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.
The text was updated successfully, but these errors were encountered: