One tricky aspect of the weak/linkonce resolution in the distributed
backend case occurs if the link involves --start-lib/--end-lib with some
of the object files. Because there are two separate links (the ThinLink
and then the final native link), depending on the intervening importing
and inlining we can get into a situation where the linkonce selected
as prevailing in the ThinLink is no longer linked in by the second link.
The linker will only pull symbols from an archive library, in this
case formed via --start-lib/--end-lib, if there is a strong reference
to a symbol in that library from a library/object listed earlier in the
link, which may no longer be the case after importing etc. Note that
the gold-plugin does not know whether the objects are in a library
formed by --start-lib/--end-lib.
To handle this, under thinlto_index_only (which indicates we will have separate
ThinLTO processes), a new flag to thinLTOResolveWeakForLinkerInIndex and
a change to the isPrevailing callback conservatively ensure that otherwise non-prevailing
linkonce/weak are kept and also converted to weak when exported.
The new thinlto_preserve_nonprevailodr.ll test case ensures this works.