[LLVMdev] Global constructors "get lost" when transforming bitcode files

[Reid Kleckner]

On Thu, Jul 10, 2014 at 8:43 AM, Jonas Wagner <jonas.wagner at epfl.ch> wrote:

> Hi,
>
> Are you setting DYLD_LIBRARY_PATH when running on OS X? The linker on
>> OS X uses that to find libLTO.dylib.
>>
>
> This indeed solves the problem! Thanks for the hint. Although I had used
> custom versions of Clang for a while, this is the first time I encountered
> incompatibilities with the system linker, and so I wasn't aware of the need
> to set DYLD_LIBRARY_PATH.
>
> The llvm-dis/llvm-as operation should be a no-op, yet the global_ctors get
>>> lost in the process. This happens also with other operations that affect
>>> global_ctors, e.g., with "opt -insert-gcov-profiling".
>>>
>>
>
>> This isn't strictly true.  Deserializing old bitcode will auto-upgrade
>> it.  In this case, it will be auto-upgraded to the 3-field form of
>> llvm.global_ctors.
>
>
> I see. I wonder if this is what's happening. Clang and llvm-as are built
> against the same version of LLVM, so Clang should not emit old bitcode. On
> the other hand, the fact that the system linker understands Clang-generated
> bitcode probably means it used the old format.
>

I think I see what's going on: Clang will emit the new, 3-field form for
C++, but you're compiling C.  That means there are no ctors until LLVM
runs, at which point it creates a 2-field form ctor array.  It's likely
that C++ LTO with TOT clang and the system linker doesn't work right now,
but that's OK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140710/1c79f263/attachment.html>