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?

CC @thanm

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.

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

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