[cfe-dev] [LLVMdev] weak_odr constant versus weak_odr global
Rafael Espíndola
rafael.espindola at gmail.com
Wed Nov 9 11:34:07 PST 2011
>> 1) [Requires ABI change] We emit dynamic initialization code for weak globals
>> (even in TUs where static initialization is required to be performed), unless
>> we can prove that every translation unit will use static initialization. We
>> emit the global plus its guard variable as a single object so the linker can't
>> separate them (this is the ABI change). If we can perform static
>> initialization in any translation unit, then that TU emits a constant weak
>> object (in .rodata if we want) containing the folded value and with the guard
>> variable set to 1 (per Eli's proposal).
>
> The ABI actually suggests doing exactly this, except using multiple
> symbols linked with a COMDAT group. Unfortunately, LLVM doesn't
> support that COMDAT feature yet, but it could certainly be taught to.
> This guarantees correctness as long as every translation unit emits the
> code the same way, which is exactly what we'd get from an ABI change,
> except without actually breaking ABI conformance.
I like this. We already have basic support for COMDATs, but yes, it
needs to be extended. So far we just create trivial COMDATs in codegen
for weak objects.
We also need the IL linker itself needs to work on COMDATs too
otherwise this bug would still exist when doing LTO.
In the "extended" example we would output
@_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE
for TU1 and
@_ZN1UI1SE1kE = weak_odr global i32 0, align 4, comdat _ZN1UI1SE1kE
...
define internal void @_GLOBAL__I_a() nounwind section ".text.startup"
comdat _ZN1UI1SE1kE {
....
}
for TU2.
> Mach-O doesn't support anything like COMDAT, but the Darwin linker
> apparently gives significantly stronger guarantees about which object
> files it will take symbols from, as long as all objects have all of the
> symbols.
>
> John.
Cheers,
Rafael
More information about the cfe-dev
mailing list