[cfe-dev] GCC and Clang produce undefined references to functions with vague linkage

[John McCall]

On Jun 29, 2012, at 11:40 AM, Rafael Espíndola wrote:
>> But that's pervasively true in C++ — the linker has to eliminate duplicates
>> all the time.  Idiomatic C++ code ends up plunking down hundreds, if
>> not thousands, of inline functions in every single translation unit.  This is
>> already a massive burden for linking C++ programs, particularly in debug
>> builds.  Adding a few extra symbols when the optimizer determines that
>> it can devirtualize, but declines to inline, is essentially irrelevant.
>> 
>> In fact, it is particularly unimportant because it's very likely that this duplicate
>> will be in the same DSO as the vtable.  That means that the first solution
>> imposes some extra work on the static linker alone (but again, only when
>> devirtualizing a call to a function we don't want to inline!) while preserving
>> our ability to reduce work for the dynamic linker (since calls do not rely
>> on address equality of the function across translation units).  The second
>> solution is an irrevocable guarantee that every symbol mentioned in
>> a strong vtable *must* be exported to the whole world.
>> 
>> Also recall that these symbols can already be emitted in arbitrary
>> other translation units — we cannot change the ABI to say that these
>> symbols are *only* emitted in the file defining the v-table.
> 
> I would just like to point out that the ABI could says that they only
> *need* to be emitted in the file with the vtable, but yes, for a long
> time it would have to support the symbols showing up in other
> translation units produce by older compilers.

There's no "for a long time" here.  The ABI does not allow us to emit these
symbols with non-coalescing linkage.  We're not going to break ABI
just because people didn't consider a particular code pattern when they
hacked in devirtualization through external v-tables.

John.