Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: fixedbugs/issue30908.go failing on Plan 9 #31503

Open
0intro opened this issue Apr 16, 2019 · 5 comments

Comments

@0intro
Copy link
Member

commented Apr 16, 2019

CL 168957 added fixedbugs/issue30908.go. This test is failing on Plan 9.

cpu% go run run.go -- fixedbugs/issue30908.go
# go run run.go -- fixedbugs/issue30908.go
exit status: 'go 527129: 1'
cmd/link: while reading object for 'a': duplicate symbol 'go.info.go.builtin.error.Error', previous def at 'runtime', with mismatched payload: new length 52 != old length 40
cmd/link: while reading object for 'bytes': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15
cmd/link: while reading object for 'path/filepath': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15
cmd/link: while reading object for 'strconv': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15
cmd/link: while reading object for 'strings': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15

FAIL	fixedbugs/issue30908.go	1.099s
exit status: 'run 527104: 1'

@0intro 0intro self-assigned this Apr 16, 2019

@0intro 0intro added the OS-Plan9 label Apr 16, 2019

@0intro 0intro changed the title test: test: fixedbugs/issue30908.go failing on Plan 9 Apr 16, 2019

@0intro 0intro added the help wanted label Apr 19, 2019

@0intro

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2019

cpu% cd /usr/go/test/fixedbugs/issue30908.dir
cpu% go tool compile -e -D . -I . -p a a.go
cpu% go tool compile -e -D . -I . -p b b.go
cpu% go tool compile -e -D . -I . -p main m.go
cpu% go tool link -w -o a.exe -L . -strictdups'='2 -w'='0 m.o
cmd/link: while reading object for 'a': duplicate symbol 'go.info.go.builtin.error.Error', previous def at 'runtime', with mismatched payload: new length 52 != old length 40
cmd/link: while reading object for 'bytes': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15
cmd/link: while reading object for 'path/filepath': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15
cmd/link: while reading object for 'strconv': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15
cmd/link: while reading object for 'strings': duplicate symbol 'go.isstmt.go.builtin.error.Error', previous def at 'a', with mismatched payload: new length 0 != old length 15

Does anyone know why -strictdups return these errors?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

CC @thanm

@thanm

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

The intent of -strictdups was to catch problems with generation of DWARF for inlined functions.

Suppose we have package "abc" that exports inlineable "abc.Foo". Let's say that this function is inlined into packages "c" and "d".

At link time, the linker will see multiple copies of certain DWARF sections for "abc.Foo", one from the original version in "abc", then two more from the copies of the function that were in used in "c" and "d". The linker will then simply discard all but the first copy. If the other copies are actually distinct from the first copy, however this can result in corrupted DWARF (as in the bug #30908).

The -strictdups option was intended to be a way to programmatically check for cases where we have different DWARF being generated for the same function depending on the context in which it was compiled.

Unfortunately -strictdups has problems with wrapper functions and with builtins (like builtin.error.Error) which seem to sometimes be given source positions based on where they are used (as opposed some other canonical pos).

Probably the right thing to do is to adjust the whitelist -- I will send a CL.

@0intro

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2019

Thanks for the detailed answer. I'm looking forward to your CL.

@gopherbot

This comment has been minimized.

Copy link

commented Apr 19, 2019

Change https://golang.org/cl/172986 mentions this issue: cmd/link: adjust whitelist for -strictdups checking for plan9

gopherbot pushed a commit that referenced this issue Apr 19, 2019
cmd/link: adjust whitelist for -strictdups checking for plan9
Add a couple of additional entries to the white list used to screen
out errors for builtin functions; these correspond to cases
that appear to come up only on the plan9 builder.

Updates #31503.

Change-Id: I48ab942ab2894240efe651ec7b7eace7aa5cb45e
Reviewed-on: https://go-review.googlesource.com/c/go/+/172986
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.