[LLVMdev] [cfe-dev] weak_odr constant versus weak_odr global

[Rafael Espíndola]

> I see. Using two comdats would still cause the same problem for us,
> no? So the solution in the end is to emit:
>
> TU1:
> --------------------------------
> @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE
> @_ZGVN1UI1SE1kE = weak_odr global i64 1, comdat _ZN1UI1SE1kE
> --------------------------------
>
> TU2:
> -----------------------------------
> @_ZN1UI1SE1kE = weak_odr global i32 0, align 4, comdat _ZN1UI1SE1kE
> @_ZGVN1UI1SE1kE = weak_odr global i64 0, comdat _ZN1UI1SE1kE
> ...
> @llvm.global_ctors = ....
> define internal void @_GLOBAL__I_a() nounwind section ".text.startup" ....
> -----------------------------------

Restarting a really old thread now that we have comdat support in the IR.

While the above idea would work, there are two problems with it

* Existing compilers (clang and gcc) produce a comdat with just the
constant in TU1. Linking one of those with TU2 can still cause a crash
since the guard variable would be undefined.
* It requires always outputting the guard variable.

Since neither gcc nor clang implement this part of the ABI, I was
thinking if there was a better way to do it. One interesting option is
putting the .init_array of TU2 in the comdat. That is exactly what we
do for windows. In fact, just passing -Xclang -mllvm -Xclang
-enable-structor-comdat will avoids the crash in the above example.

Given that this has been broken since forever, waiting a bit more for
https://sourceware.org/bugzilla/show_bug.cgi?id=17350 to be fixed and
then flipping -enable-structor-comdat might be the best way to fix
this. With that done we can add the function and the guard variable in
TU2 to the comdat to remove a bit of bloat (see attached patch).

What is the discussion list for the itanium abi? Should I propose a patch?

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 1372 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140904/f457599a/attachment.bin>