Faster linking (-gsplit-dwarf, gold/lld, --gdb-index)

[Stephan Bergmann]

On 10/10/2018 12:57, Luboš Luňák wrote:
> On Thursday 04 of October 2018, Stephan Bergmann wrote:
>> On 04/07/2018 17:37, Luboš Luňák wrote:
>>>    I've changed --enable-gold to --enable-ld=<linker>, because I've found
>>> out that LLVM besides Clang provides also a linker called lld, and lld at
>>> least in version 6 actually performs even better than gold (4s vs gold's
>>> 6-7s). There are some caveats though:
>>> * lld6 crashes sometimes and needs [1] (openSUSE users,
>>> devel:tools:compiler/libLLVM6 has it)
>>> * Valgrind can't handle lld's debuginfo and needs [2] and [3], or
>>> passing --no-rosegment to lld, see
>>> https://bugs.kde.org/show_bug.cgi?id=384727 (openSUSE users,
>>> home:llunak:my/valgrind has them)
>>
>> and lld doesn't understand --dynamic-list-cpp-typeinfo, which we add for
>> sanitizer (ASan/UBSan) builds in solenv/gbuild/platform/unxgcc.mk
> 
> 
>   That's a very corner case and as far as I understand it that's in the
> workaround-for-workaround category (either we're doing something wrong, or
> the sanitizers shouldn't require options that make them work just as a
> side-effect). So I take it this problem is sufficiently solved either by
> ignoring it, or by adding a check to --enable-ld ?

The underlying issue is that the internals of Clang's UBSan use the 
Itanium ABI's notion of type equality (checking for RTTI pointer 
equivalence), not GCC's weaker notion (checking for RTTI string 
equivalence).  That requires some adjustments when building LO for 
UBSan, to make sure RTTI for types used across library boundaries gets 
exported from libraries.  I don't think we are doing anything inherently 
"right" or "wrong" here.

If you plan to make choice of --enable-ld=... implicit in configure.ac, 
then yes, please do so in a way that verifies that the implicitly chosen 
linker supports --dynamic-list-cpp-typeinfo if that will be needed by 
the build's solenv/gbuild/platform/unxgcc.mk.