Bug 21215 - Gold linker segfaults linking symbols with different versions.
Summary: Gold linker segfaults linking symbols with different versions.
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.29
: P2 normal
Target Milestone: ---
Assignee: Cary Coutant
Depends on:
Reported: 2017-03-03 22:04 UTC by Han Shen
Modified: 2018-11-21 03:44 UTC (History)
2 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Han Shen 2017-03-03 22:04:09 UTC
Gold linker segfaults linking symbols with different versions.

The scenarios is explained below:
We have a symbol "_ZNKSs11_M_disjunctEPKc", defined in 3 different places:
a) - "_ZNKSs11_M_disjunctEPKc" in libstdc++.a(string-inst.pic.o)
b) - "_ZNKSs11_M_disjunctEPKc@GLIBCXX_3.4" in compatibility.pic.o
c) - "_ZNKSs11_M_disjunctEPKc@@GLIBCXX_3.4.5" in compatibility.pic.o

And we link with a version script file - 
  GLIBCXX_3.4 {

The problem we have is
1) - linker reads a), gets version "3.4" from version script file, thus it is treated as "default_version".
2) - linker reads c), get version "3.4.5", also regarded as default version, because of "@@".
3) - linker segfaults at Symbol::override_version.

We only circumvent this if linker processes symbols in the order of a) -> b) ->
c). However the order linker processes symbols is out of our control.

Is there an usage error - providing a default version in both version script file and object file?

But anyway, the link segfaul should be fixed.

(I think the explanation is clear to identify the problem, if not, I'll reduce what I have and provide a small test case)
Comment 1 Brooks Moses 2018-11-21 03:44:20 UTC
I ran into this one again just now.

It may be worth explicitly noting that the failing case in question is "linking GNU libstdc++ with Gold" -- which doesn't really seem that esoteric a thing to want to do....